[buddypress-trac] [BuddyPress Trac] #5429: New component to manage BuddyPress "attachments"

[buddypress-trac]

#5429: New component to manage BuddyPress "attachments"
----------------------------+------------------
 Reporter:  imath           |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  2.0
Component:  All Components  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  2nd-opinion     |
----------------------------+------------------

Comment (by boonebgorges):

 Very, very cool!

 2. "Attachment" seems good to me too.
 3. What jjj said. Maybe set to false for now, but keep in consideration
 for future.

 I think that the UI around this seems really pretty great, and I love how
 you're integrating the WP tools. My big concerns surround the API (your
 question 5) and privacy.

 __API__

 I like jjj's suggestion that attachments could be associated with more
 than one item. This suggests using taxonomies to represent these
 connections. (Though this may introduce issues regarding storage
 location.)

 At a low level, perhaps we could wrap much of the functionality into a
 `BP_Attachment` class that represents specific attachment objects. It
 would have normal CRUD methods, in addition to specialized methods like:
 - associate_with_item( $item_id )
 - disassociate_with_item( $item_id )
 - handle_upload( $_FILES )
 - handle_crop( $args )
 - get_url()
 - get_path()

 Then, at a somewhat higher level, we'd have easy-to-use functions for
 plugin developers who want to implement various aspects of attachments
 into their plugins (we would also use them internally throughout the
 components):
 - template loop `bp_has_attachments( array( 'component' => $component,
 'user_id' => $user_id, etc ) )`
 - `bp_load_attachments_assets()` or something like that, which could be
 used to enqueue the necessary javascript and CSS requirements for the
 front-end
 - procedural wrappers for specific `BP_Attachment` actions

 Bottom line is: WP handles much of the very low-level stuff (like file
 handling), and much of the front-end stuff (through the wp.editor backbone
 framework). So we'll be building wrappers that provide the BP-specific
 middleware, like association with BP groups, users, etc. Ideally, it'll be
 easier to use than WP's core libraries as well, because we have the
 advantage of hindsight when building :)

 __Privacy__

 imath, you and I have dealt with this and talked about it before. Privacy
 is going to be the very first question we are asked about attachments. The
 basic situation is this: The only way we can protect files is if they are
 served through BuddyPress, and the webserver software is prevented from
 serving them directly. This means we need a combination of webserver rules
 (like .htaccess or nginx.conf rules) + a download handler script. However,
 doing this introduces lots of complications:

 - Serving through BP means that BP/WP has to load. In the case of an album
 with 20 thumbnails, this could mean that WP loads 21 times on a single
 pageload, which is unacceptable in most cases. So we may want to disable
 embedded items/thumbnails in cases where the webserver cannot serve the
 files directly.
 - We have to account for different webserver software. Apache is fairly
 straightforward. mod_rewrite is already required for BP, and Apache is
 nearly always configured to allow the correct overrides via directory-
 specific .htaccess. So, we can create an .htaccess in the top-level
 directory that blocks direct access. And if we are smart about the way we
 store files, we may be able to protect only those files that are
 associated with "private" items, allowing Apache to serve the others
 directly; this is how BuddyPress Docs does it
 https://github.com/boonebgorges/buddypress-
 docs/blob/1.6.x/includes/attachments.php#L199. nginx does not allow for
 per-directory drop-in rewrites; they all must be configured manually in
 nginx.conf or another global file. This means that either all uploads are
 protected, or all of them are unprotected. The dev version of BuddyPress
 Docs does some detection https://github.com/boonebgorges/buddypress-
 docs/blob/1.6.x/includes/attachments.php#L731 and makes some suggestions
 for these cases https://github.com/boonebgorges/buddypress-
 docs/blob/1.6.x/includes/attachments.php#L703. And then there's IIS :)
 - If attachments can be associated with two items, and one item is private
 while the other is public, how do you handle permissions for that item?
 - etc

 We could consider doing v1 of this feature with zero privacy controls.
 But: (1) we would have to document this very carefully, because people
 will expect that, by default, things like message attachments and private
 group attachments will be private; and (2) even if it's not going to be
 implemented in v1, we should think about what the eventual solution may
 look like, to make sure that our architecture allows for it.

 Any thoughts that people might have about this are welcome. I know that
 imath (BuddyDrive) and I (BuddyPress Docs) have thought about this issue
 extensively, but maybe other have too :)

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5429#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac