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

buddypress-trac noreply at wordpress.org
Fri Apr 3 14:47:30 UTC 2015

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

 I would like to thank all the core team members for their contributions,
 and also apologize (again) for the time i requested during the last two
 dev-chats. Thanks to your help, i'm now strongly convinced and very
 confident about the best approach about where to put the attachments
 - @johnjamesjacoby was right since the beginning! All BuddyPress templates
 are in `bp-legacy`. We must keep it this way, even if in the case of
 attachments these are Backbone templates, because Backbone templates are
 templates :)
 - @hnla is right. In `bp-legacy` we should put the templates in a new
 directory `assets`. Because one day or another, we'll need assets about
 other BuddyPress features.
 - @r-a-y is right. We should prefix the attachments directory with an
 underscore to visualy inform that Core wants to keep the control over this
 part and as a result, there's no need to try to override it from the theme
 or a custom template dir.

 So the best approach is `bp-legacy/buddypress/assets/_attachments/`

 Directly in `_attachments/` we have the shared templates between various
 BuddyPress features. For instance, `uploader.php` is used for the Avatars
 and need to also be available for any component (eg: messages).
 In `_attachments/avatars` we have all the templates relative to the

 For the introduction of the new Avatar UI, our need to keep a "core
 control" over the Backbone templates must be resolved in BuddyPress Theme
 Compat, but not by adding new template stacks. Adding these in `bp-core`
 for example will simply add three extra overridable locations. Meaning
 that in the case of a "not existing" template part: three extra locations
 will be checked, which is not the end of the world but clearly unuseful.

 I've opened this new ticket #6348 to suggest another strategy to keep
 temporarly this control over the needed features or permanently in the
 case of BuddyPress Administration screens.

 6290.07.patch is requiring
 6348.01.patch] and:
 - applies the described approach,
 - brings back the Avatar UI in wp-admin/extended profile
 - improve the UI navigation: there's no more the need to refresh the page
 to make the "Delete" nav item appear.

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

More information about the buddypress-trac mailing list