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

[buddypress-trac]

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

Comment (by imath):

 In 6290.04.patch, i'm first applying DJPaul's recommandations :
 1. {{{! $class}}} instead of {{{! empty( $class )}}} in
 {{{bp_attachments_enqueue_scripts()}}}
 2. use {{{===}}} instead of {{{==}}}, get rid all @uses phpDoc tags.
 3. use 'profile photo' instead of 'avatar' in the camera strings
 4. use 'bp_avatar_' instead of 'bp_core_avatar_' in all added avatar
 functions
 5. remove the notice in {{{bp_avatar_template_check()}}}

 "Deuxio" i'm removing the wp-admin / Extended profile edit avatar feature,
 because i'm not comfortable with a workaround i've used. Loading templates
 in the Administration seems to be "forbidden" for now. In
 {{{bp_locate_template()}}} there's a check on this constant
 {{{WP_USE_THEMES}}}, and in Administration screens, this constant is not
 defined or set to true. So i was forcing it to be true. I'm not sure we
 should do that... Anyway, this feature can be implemented later, once we
 get the front part in, as it's very easy...
 i'm also removing {{{bp_is_my_admin_profile()}}}, because i removed the
 wp-admin / Extended profile edit avatar feature :) and i don't think we
 should use this kind of functions. I think we should introduce some
 capability check instead.

 That's what i've done in {{{bp_attachments_current_user_can()}}}. On a
 side note, it would be great if we could progress on #5121. But in the
 meantime, this function will help us to check an 'edit_avatar' capability
 on front-end and in back-end.

 "Tertio" DJPaul's Jetpack point made me realize we had a touchy part to
 deal with: at the top of {{{bp_core_avatar_handle_upload()}}} we're
 allowing a complete bypass of the function and we simply stop the upload
 process returning true if:
 {{{
 false === apply_filters( 'bp_core_pre_avatar_handle_upload', true, $file,
 $upload_dir_filter)
 }}}
 It appears Jetpack is using this filter to disable Photon for BuddyPress
 Avatars see https://github.com/Automattic/jetpack/blob/master/3rd-
 party/buddypress.php. So:
 1. we need to make sure this filter is also in the new
 {{{bp_avatar_ajax_upload()}}} function so that Photon won't play whith an
 ajax uploaded avatar.
 2. If false is returned to this filter, we need to send an error if the
 plugin is not giving the required infos about the uploaded avatar.

 Jetpack is using this filter to know if an avatar is uploaded, but is
 returning the bool unchanged. Do we know about plugins/themes playing
 there and returning false (/me is praying it's not the case!) ?

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