[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:  2.2.2
Component:  API         |     Version:
 Severity:  normal      |  Resolution:
 Keywords:              |
------------------------+--------------------
Changes (by boonebgorges):

 * component:  Component - Skeleton => API
 * milestone:  Awaiting Review => 2.2.2


Comment:

 Thanks so much for the additional info. On review, I think you're right.
 To put your point in another way. There are two different kinds of context
 in which `bp_core_get_directory_page_ids()` is called:

 1. In a read-only fashion. This happens mainly (a) when we're doing URL
 parsing, but also (b) when we're building settings markup (since inactive
 components don't need to be shown in the page mapping settings)
 2. When doing save validation. These are the cases that Scott lists in his
 most recent comment (`bp_core_on_directory_page_delete()`, etc).

 In cases like (2), we should take care not to be destructive of data - for
 third-party components or for BP's packaged components. The
 `bp_is_active()` filters should only apply in cases like (1), so that they
 don't have to apply in cases like (2).

 In [attachment:6280.diff], I've added a `$status` argument to
 `bp_core_get_directory_page_ids()`, and then changed up our use of the
 function to pass `status=all` when necessary. Scott and others, this could
 use a review, both to see if it fixes the current problem, and to see if
 this supercedes the fix from #6244 [9553].

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