[buddypress-trac] [BuddyPress] #4949: Revise enqueue style locations for theme compat

buddypress-trac noreply at wordpress.org
Mon Jun 10 02:44:40 UTC 2013

#4949: Revise enqueue style locations for theme compat
 Reporter:  hnla                                 |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  low                                  |   Milestone:  1.8
Component:  Theme                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion needs-testing  |
Changes (by boonebgorges):

 * cc: johnjamesjacoby (added)
 * keywords:  needs-patch => has-patch 2nd-opinion needs-testing
 * milestone:  1.9 => 1.8


 > could we not put in place an interim solution that achieves the outcome
 but that has the method improved at a second pass

 Yeah, this sounds reasonable to me. My biggest concern is that we don't
 want to put in any limited logic that might be used by a plugin or theme
 dev during the 1.8.x cycle, thus harming our ability to tear out the
 interim solution later on. But the architecture of theme compat means that
 I can just make it a private method, and we shouldn't have any problems.
 See 4949.02.patch.

 I did have to change your logic a little bit. Your `is_child_theme()`
 check means that the parent theme is not consulted if the child theme
 doesn't have the assets. This is not how theme compat works for templates
 - we first check the child, then check the parent, not one or the other.

 The only real limitation of 4949.02.patch, other than the fact that it
 duplicates some of the _template_stack() stuff elsewhere in BP and thus is
 a bit inelegant, is this. The template_stack() architecture allows third
 parties to register their own template locations. For example, I do this
 in CollabPress and BuddyPress Docs so that I can ship template with the
 plugins that can be overridden easily in a theme. Those custom locations
 will *not* carry over to CSS/JS assets - the checks in 4949.02.patch are
 hardcoded. This can't be worked around at the moment. That said, this is a
 real edge case that I doubt anyone would ever have noticed if I hadn't
 just written it down :)

 I'm going to ask johnjamesjacoby for feedback on this before committing
 it. I don't expect him to love it, but I think he'll agree that (a) the
 goal is a very good one, and (b) 4949.02.patch is a good-enough interim
 solution, which can easily be rethought in BP 1.9 or whenever. hnla, can I
 ask you to test the patch to make sure it's acting the way you'd expect?

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4949#comment:5>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list