[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):

 @DJPaul,

 Thanks a lot for your comment. I guess i may have overreacted a bit, must
 be a french thing :)

 I was very much into this ticket and i understood the first part as "we're
 doing it wrong". (Added 2 patches yesterday - the second one to correct an
 unjustified fear - was shopping with wifey when received the mail : this
 last element was very stressfull!)

 I'm not sure it's the right translation, but there were no bad feelings
 and is no hard feelings :)

 The JetPack workaround made me realized we can improve some filters by
 adding some contextual data like are we setting an avatar for a user or a
 group or something else..

 We will surely discuss about it during tonight's dev-chat, these are the
 parts i think we need to find the best approach on :
 - localization of the javascript templates : bp-legacy is ok as it acts as
 a fallback if no template were found in active theme and we are avoiding
 some hooks on theme compat to register new template stack(s).
 - Organization in bp-legacy (if definitive destination), in a discussion
 with @hnla he was wondering if having /assets/attachments would be an
 interesting one if in the future we need to do things for other areas. I
 think it's an important choice to make.
 - Templates : name of selectors/classes, available do_actions (and names
 of them...)
 - Styles : avatar.css is including all the needed rules for the UI, should
 we keep it this way? Keeping it this way is interesting considering next
 point, but it can also be interesting to split it to have uploader rules
 in a file and specific avatar ones (crop / camera) in another one.
 - Administration screens : 03.patch was bringing the UI into the wp-admin
 / extended profile. I've removed it because {{{bp_locate_template()}}} is
 doing a check on WP_USE_THEMES and i'm not sure defining this constant to
 true in Administration is the right move. Maybe include a new
 filter/constant in {{{bp_locate_template()}}} is better. A filter could be
 toggled on/off before and after our need to get template parts.
 - Displayed user in Administration screen and AJAX : the Displayed user Is
 dynamically get each time we need it so far (if wp-admin/profile.php or
 user-edit.php?user_id=ID) and in AJAX no current screen is set, reason why
 i'm using since 04.patch a minimal capability check {{{( 'edit_avatar',
 array( 'object' => '', 'item_id' => 0 ) )}}}. I think the capability check
 is better for the future as attachments will possibly be attached to post
 types or any object actually!
 - Other possible improvements : name of filters/actions/functions and
 things i might have missed :)

 Finally @boonebgorges, thanks a lot for your comment :)

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