[buddypress-trac] [BuddyPress Trac] #6280: Custom BP Component dropped from BP Pages Association Settings in some cases with 2.2 changes
noreply at wordpress.org
Thu Mar 5 21:21:52 UTC 2015
#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
'''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
'''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
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
'''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?
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6280>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac