[buddypress-trac] [BuddyPress Trac] #6280: Custom BP Component dropped from BP Pages Association Settings in some cases with 2.2 changes

[buddypress-trac]

#6280: Custom BP Component dropped from BP Pages Association Settings in some
cases with 2.2 changes
----------------------------------+------------------------------
 Reporter:  dtc7240               |       Owner:
     Type:  regression            |      Status:  new
 Priority:  normal                |   Milestone:  Awaiting Review
Component:  Component - Skeleton  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:                        |
----------------------------------+------------------------------

Comment (by dtc7240):

 Absolutely related @boonebgorges, but the fix for #6244 was too far
 upstream to help in the three events I lined out above.

 @imath graciously took on fixing #6244 directly at the source for the
 specifically reported issue ( Clicking the "Save Settings" button on the
 BuddyPress->Settings->Components tab ) as follows:

  I've chosen to edit the
 bp_core_admin_get_active_components_from_submitted_settings() as the
 bp_is_active() check in the bp_core_get_directory_page_ids() was an
 improvement introduced in 2.2 and i think
 bp_core_admin_get_active_components_from_submitted_settings() should only
 take care of the BuddyPress built in components.

 However, I found that if any of the three events above are called WHILE
 THE CUSTOM COMPONENT IS TEMPORARILY DISABLED, they run into the same issue
 with the bp_is_active check in bp_core_get_directory_page_ids() causing
 the page association to be lost.  The easiest route to reproduce this is:
 1. Install custom component( try buddypress-skeleton-component)
 2. activate the plugin
 3. Visit Settings->BuddyPress->Pages and save the associated page for
 Example component
 4. Deactivate the plugin
 5. Now visit, Settings->BuddyPress->Pages  (You will not see the example
 component listed because it is not active at the moment ) and click Save
 settings.
 6. Reactivate the plugin
 7. Go back to Settings->BuddyPress->Pages and you'll see that the page
 association for the Example component is lost.

 Again, the three events (that I found) that will cause this problem (while
 the custom component is temporarily deactivated) are:
 1. delete_post action hook is fired (causing the also new
 bp_core_on_directory_page_delete() function to run)
 2. bp_core_add_page_mappings() is called (by something other than
 bp_core_admin_get_active_components_from_submitted_settings() now that
 imath has fixed that upstream)
 3. "Save Settings" button on the BuddyPress->Settings->Pages tab is
 clicked (running bp_core_admin_slug_handler())

 It's arguably not the most horrific problem in the world, but it could
 cause some frustration at some point (as it did me...technically it just
 exacerbated a mistake I'd already made between two of my own custom
 plugins...but I shan't tell on myself any more).

 I would suggest that any event (such as these three) that have the effect
 of re-populating the "bp-pages" entry in the wp_options table should skip
 the bp_is_active() check in the bp_core_get_directory_page_ids() function.
 The easiest way I can see to accomplish that is to add an optional
 parameter to bp_core_get_directory_page_ids() that if passed in as true
 will skip the bp_is_active() check.  Then add that parameter as true to at
 least the three events I found thus far that call
 bp_core_get_directory_page_ids() and that end up rewriting the "bp-pages"
 entry:
 1. bp_core_on_directory_page_delete()
 2. bp_core_add_page_mappings()
 3. bp_core_admin_slug_handler()

 I think (but could be quite wrong) that this would have also resolved
 #6244.

 Scott

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6280#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac