[buddypress-trac] [BuddyPress] #5084: Regression with 'bp_template_content' action

[buddypress-trac]

#5084: Regression with 'bp_template_content' action
-------------------------------------------+-----------------------
 Reporter:  DJPaul                         |       Owner:
     Type:  defect (bug)                   |      Status:  new
 Priority:  high                           |   Milestone:  1.8
Component:  Theme                          |     Version:  1.8-beta
 Severity:  blocker                        |  Resolution:
 Keywords:  reporter-feedback 2nd-opinion  |
-------------------------------------------+-----------------------

Comment (by boonebgorges):

 I've located the specific change that's causing the problem to surface in
 1.8. Related ticket: https://buddypress.trac.wordpress.org/ticket/5021

 In 1.7, BP ran `bp_remove_all_filters( 'the_content' )` just before
 running its own `the_content` manipulation:
 http://buddypress.trac.wordpress.org/browser/tags/1.7.2/bp-core/bp-core-
 theme-compatibility.php#L522 In the case of Achievements, that meant that
 BP was shutting off Achievements's version of theme compat
 (https://github.com/paulgibbs/achievements/blob/master/includes/core
 /theme-compatibility.php#L447). However, when BP 1.7.x runs its initial
 theme compat setup *before* Achievements, such as when BP is network-
 activated and Achievements is not, `bp_remove_all_filters( 'the_content'
 )` runs *before* Achievements has a chance to hook its theme compat layer
 to `'the_content'`, with the result that the filter is not removed and we
 get double content. This is a bug in Achievements that only surfaces under
 very specific circumstances.

 In r7131, BP stopped running `bp_remove_all_filters( 'the_content' )`
 before running theme compat. For discussion, see #5021. As a result, the
 Achievements bug that was only visible in edge cases in 1.7.x became
 visible in every circumstance in 1.8.

 My take on the situation is two-fold:

 a) It's a coincidence of load order (ie, the alphabet) that Achievements
 didn't exhibit this bug under BP 1.7.x. So it should be fixed there. How
 could it be fixed? Ideally, Achievements's theme compat layer would check
 to see if BP's is already running (or has already run) before running its
 own, and bail if so. That's tricky to do right now, because there's no
 reliable way to tell while inside of BP's output buffer that you are
 experiencing theme compat. BP could set a flag early - something like
 `buddypress()->theme_compat->started`. Then, Achievements would add a
 check to `dpa_do_theme_compat()`
 https://github.com/paulgibbs/achievements/blob/master/includes/core/theme-
 compatibility.php#L547 along the lines of `if (
 bp_is_theme_compat_started() ) return false;`. (Side note: we can't use
 `bp_is_theme_compat_active()` for this purpose because in BP we've set it
 to false by the time the buffering begins, to prevent recursive
 `the_content` swaps in certain scenarios.)

 b) Although I think that, at root, this is an Achievements bug, I also
 think that the changes introduced in r7131 are introducing enough of a
 change in behavior for plugins that we should revert at least part of the
 behavior. In particular, if we reinstate the `bp_remove_all_filters(
 'the_content' )` in `bp_template_include_theme_compat()`, Achievements
 goes back to the 1.7.x status quo. This means that #5021 will remain
 unsolved for now, but IMO that's not a huge deal for 1.8 - it was an
 enhancement anyway.

 Would like a sanity check before proceeding with either or both of these
 solutions. Thanks.

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