[buddypress-trac] [BuddyPress] #2086: Some slugs need to be changeable, add language strings.

[buddypress-trac at lists.automattic.com]

#2086: Some slugs need to be changeable, add language strings.
-------------------------------------------------+-------------------------
 Reporter:  sulley                               |       Owner:
     Type:  enhancement                          |  boonebgorges
 Priority:  major                                |      Status:  assigned
Component:  Core                                 |   Milestone:  1.6
 Severity:  normal                               |     Version:
 Keywords:  dev-feedback has-patch needs-        |  Resolution:
  testing                                        |
-------------------------------------------------+-------------------------
Changes (by boonebgorges):

 * keywords:  dev-feedback => dev-feedback has-patch needs-testing
 * owner:   => boonebgorges
 * status:  new => assigned


Comment:

 OK, I've got a patch that demonstrates the core functionality, along with
 an implementation for the Activity component. (Don't want to spend the
 time to do the rest of the components before getting the nod that this
 approach makes sense.) Here are the main pieces of the puzzle:

 - In BP_Activity_Component::setup_globals(), I define an array of slug
 defaults.
 - Then they're passed through bp_parse_component_slugs(). That function
 parses the default slugs from the component with those stored in the bp-
 slugs option. This will allow users to define their own slugs and save
 them to the db (interface not built yet)
 - Slugs are then passed back to setup_globals() and passed along to
 BP_Component::setup_globals() and added at $bp->activity->slugs. Along the
 way they're put through the bp_activity_slugs filter.
 - When setting up nav items, use $this->slugs[slug_name] rather than the
 current hardcoded slugs.
 - Then, when testing bp_is_current_action(), and when building URLs
 throughout the component, use the new template functions
 bp_get_activity_mentions_slug(), etc. Those in turn make a call to
 bp_get_slug(), which puts everything through a single filter, for maximum
 plugin flexibility (and minimum direct calls to the $bp global in template
 tags).

 So, this all works quite nicely. Should be totally backward compatible,
 because plugins that are currently providing hardcoded slugs are
 hardcoding their links/bp_is_current_action() checks anyway.

 Looking for general feedback, as well as some thoughts on a couple
 questions:
 - What to do about an admin interface? In an ideal world, I think that the
 current Pages and Components panels should be combined, and slug stuff
 added to that combined page, with slug settings appearing alongside the
 associated component. That would take a ton of work, of course. In theory,
 no admin interface is required for BP 1.6 - the values are all filterable,
 and if someone really wanted an admin UI, you could do it with a pretty
 simple plugin. (Paul, maybe I could write something and you could slip it
 into BP Labs for the 1.6 cycle.)
 - In order to maintain backpat - with our own code as well as with third-
 party components - I have left $bp->activity->root_slug and
 $bp->activity->slug in place throughout, instead of switching over to
 $bp->activity->slugs['root_slug'], etc. It's a bit redundant, but I think
 it's necessary for now.
 - Related, I currently pass the root_slugs along with the rest of the
 slugs to the filters. However, since root_slugs come from the associated
 WP pages, they shouldn't be changed in this method - it would break stuff,
 probably. It'd be possible to have post-filter enforcement of the
 root_slug == $bp->pages->{$component}->slug equivalency, but I'm not sure
 whether it's necessary right now. (In our eventual admin, I'd grey-out the
 root slugs and provide a link to the edit.php page for the associated WP
 page.)

 Feedback welcome. It'd be nice to get this basic infrastructure into the
 trunk in the next week or two so that it can be put through its paces. As
 I say above, the Admin UI could be punted.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/2086#comment:11>
BuddyPress <http://buddypress.org/>
BuddyPress