[buddypress-trac] [BuddyPress Trac] #6290: Avatars, an extensible UI

Thu Mar 19 15:00:16 UTC 2015

#6290: Avatars, an extensible UI
------------------------------------+------------------
 Reporter:  imath                   |       Owner:
     Type:  idea                    |      Status:  new
 Priority:  normal                  |   Milestone:  2.3
Component:  API - Avatars           |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------
Changes (by imath):

 * keywords:   => has-patch dev-feedback

Comment:

 6290.01.patch is my suggestion to provide a new UI for Avatar management.
 In the following lines, i'm trying to explain the different choices i've
 made.

 === The client side ===

 ==== Javascripts ====

 You will quickly see i'm using Plupload, but not `wp-plupload.js`. The
 problem with the WordPress Plupload JS code is that the models for the
 queued files or the uploaded files are based on WordPress Attachments
 model `wp.media.model.Attachment`. That's really too bad because i
 personally think a file shouldn't be that early typed as a WordPress
 attachment.
 - With the BP Attachments plugin i had the opportunity to see that it's
 forcing us to completely override wp.media
 - With #6004 we figured out using the Media Editor in front end wasn't
 that great (eg: imgAreaSelect is only enqueued in wp-admin)
 - Enqueueing wp-plupload.js enqueues all the media models and we don't
 need them all ! (It might have changed in WordPress 4.2 with the use of a
 `require()` function but i'm not familiar enougth with it to be sure see
 [https://core.trac.wordpress.org/ticket/28510 WP28510])

 So i came to the conclusion, we should build our own Plupload file : `bp-
 plupload.js`. It looks like `wp-plupload.js` but differs essentially when
 typing files. Files have a very generic model: they are just files (url,
 name, loaded..) not WordPress Attachments or even BuddyPress Attachments.
 It's also providing some minimal Backbone views so that any plugin can use
 it and get the Drag and drop UI, some views to show upload progress,
 errors or warnings. All these views can of course be easily overriden if
 they don't match the need.
 The other difference is i've added a specific check in it to be sure that
 if more than one file is dropped in the UI although the `multi_selection`
 Plupload parameter is set to `false` a warning will inform only one file
 can be added. Which in the case of Avatar is useful :)

 Then we have `avatar.js`. This script requires `bp-plupload.js` and
 `imgareaselect` (for the cropping part) and extends the file model
 received from the plupload script by adding some BuddyPress specific
 attributes (eg: object, item_id, nonces, cropping datas). It's in a way
 supercharging the existing UI. At the top of the file, you'll see i check
 for some selectors to eventually remove the legacy UI. This way if
 javascript is disabled or if for some reason there's a javascript error,
 the legacy UI will act as a fallback.
 This file is building the tabs, the cropping and delete views and is
 triggering a specific event when one of the nav is clicked. This way other
 scripts can listen to it and display there custom views.

 That's what is doing `webcam.js`. It listens to `bp.Avatar.nav.on( 'bp-
 avatar-view:changed' )` to set the device camera capture views. As this UI
 is new i've added a bunch of warnings to help users get familiar with it.

 [[Image(https://cldup.com/t4U2KfYsXb.png)]]

 For instance, as soon as it loads, the browser is displaying a prompt to
 authorize the use of the webcam, to be sure people will look at it i've
 included a specific warning.
 This script is using getUserMedia. Not all browsers are supporting it see
 [http://caniuse.com/#feat=stream this table]. In case the browser is not
 supporting it a warning message will inform the user of the missing
 support of his browser. In short, if you want to be sure to use the
 "camera" avatars, use the Chrome browser.

 ==== Css ====

 `avatar.css` requires `imgareaselect`. For this first patch, i've included
 in it all the rules i've needed for the UI. But i think :
 - css rules can be improved
 - some rules might be better in buddypress.css (eg: the ones concerning
 the uploader for instance)
 hnla's review of this part + the following one will be greatly appreciated
 :)

 ==== Javascript templates ====

 For the javascript templates of the Media Editor, WordPress is using a
 unique file `wp-includes/media-template.php`. This means every template
 are loaded, no matter if you are using it or not. For our javascript
 templates, i'm suggesting to take benefit of our template hierarchy and to
 use a more modular approach. A template file for the Uploader and a folder
 for avatars specific javascript templates (index/crop/camera).
 At first i thought let's put it in `bp-legacy` or another template pack.
 On the other hand, this would restrict the Uploader to the themes using
 the built in template pack. So i thought we should make the BuddyPress
 Attachments template parts available for all situations (BP Default,
 standalone BuddyPress themes). That's why i've created the `bp-
 attachments` subdirectory in `bp-templates`.
 Theme back compat is important, so i've built a small trick to :
 - maximize the inclusion of the javascript templates by hooking some
 existing actions in the legacy templates
 - display a doing it wrong in case the "avatar templates" are outdated and
 are not using the new template tag `bp_core_avatar_get_template_part()`

 === The server side ===

 Of course, i'm using the BP Attachments API Introduced in the #6278
 ticket. There are specific Plupload localization functions to include our
 BuddyPress parameters in the Plupload strings or settings.
 The most important function is `bp_attachments_enqueue_scripts()`. It
 requires the name of the class extending the `BP_Attachment` one and is in
 charge of setting the script data. For instance `BP_Attachment_Avatar`
 will populate these datas adding required parameters: the `action` and the
 `file_data_name`, specific attributes for avatars (object, item_id,
 nonces) and the required registered script or css. This function is acting
 a bit like `wp_enqueue_media()`.

 I've also added a bunch of Ajax functions to set, crop, delete the avatar.
 And included specific parts for the groups component (Yes: the new UI is
 working for groups avatar management :) ), leaving filters and actions for
 any other components requiring avatars (eg: blavatars).

 2 filters can be used to eventually :
 - disable the camera feature : `bp_attachment_avatar_use_webcam`
 - disable completely the new UI : `bp_core_avatar_is_front_edit_avatar`

 The name of the functions, selectors, code format can surely be improved.
 I think it would be great if we could include this UI in 2.3 now that we
 have the BP Attachments API in. 'Front' Uploading user files is from my
 point of view lacking in WordPress, BuddyPress could begin to bring a very
 interesting reply with this ticket.

 Finally, let's have some fun while you're testing the patch! Let's share
 our "selfie" avatars thanks to the "camera" part of the patch! Here's mine
 :)

 [[Image(https://cldup.com/dgrpmtZ1sf.png)]]

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