[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                |   Keywords:
----------------------------------+-----------------------------
 I found a potential problem that could affect BuddyPress site admins in
 the future given recent changes in 2.2.0.  I found it while tracking down
 a problem that it turns out I had caused between two of my own plugins.  I
 thought I would note it here in case it becomes an actual problem for
 anyone else.  It COULD affect site admins in a manner similar to #6197 and
 #6226, but is not related to a multisite installation.

 '''Scope''':  This potentially affects any BuddyPress Component that has
 it's own directory (based on the Skeleton Component Plugin).

 '''Potential Issue''':  The WordPress page associated with the component
 in the BuddyPress->Settings "Pages" Association screen can become
 disassociated in certain circumstances, forcing the site admin to manually
 re-associate it.

 '''Circumstances''':  If one of the following events occur WHILE a plugin
 within this scope is temporarily deactivated, the issue will manifest when
 the plugin is reactivated:
 1) delete_post action hook is fired
 2) bp_core_add_page_mappings() is called
 3) "Save Settings" button on the BuddyPress->Settings->"Pages" tab is
 clicked

 '''Flow''':  Any of the three events listed above do the following:
 1)  They call bp_core_update_directory_page_ids() to return a list of
 pages from the "bp-pages" entry of the wp_options table.
 2)  They make whatever additions or subtractions to the list of pages they
 are supposed to.
 3)  They ultimately call bp_update_option( 'bp-pages', $page_ids ) to
 rewrite the values of the "bp-pages" entry in the table.

 '''Problem''':  In BuddyPress 2.2, an addition was made to
 bp_core_get_directory_page_ids() causing it to remove any inactive
 components from the list of pages it found in the "bp-pages" entry before
 passing the list of pages to whatever called it.  If any of the three
 events listed above occur while the plugin is inactive, the page
 associated with the plugin is removed from the "bp-pages" entry.
 Therefore, when the site admin reactivates the plugin, it no longer has
 it's appropriate WordPress page associated with it and it has to be
 manually reset.

 I believe the changes to bp_core_get_directory_page_ids() were good, as
 this function is called from a lot of different places, many of which are
 better off not having to process through inactive pages.  The changes,
 however, had the unintended side-effect noted in this ticket since
 bp_core_get_directory_page_ids() is also used by the three events noted
 above that ultimately rewrite the "bp-pages" entry in the wp_options
 table.

 '''Possible Soution''':  Maybe add an optional parameter to
 bp_core_get_directory_page_ids() that the three processes noted above use
 to have it not remove inactive components before returning its list?

 Thanks, Scott

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