[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
templates:
- @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
Avatars.
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
[https://buddypress.trac.wordpress.org/attachment/ticket/6348/6348.01.patch
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