[buddypress-trac] [BuddyPress Trac] #6290: Avatars, an extensible UI
noreply at wordpress.org
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
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
=== The client side ===
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
- 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
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
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.
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
unique file `wp-includes/media-template.php`. This means every template
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
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 :
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
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6290#comment:11>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac