[buddypress-trac] [BuddyPress Trac] #5436: BP_Core shouldn't run on 'bp_setup_components'
noreply at wordpress.org
Sat May 10 13:51:45 UTC 2014
#5436: BP_Core shouldn't run on 'bp_setup_components'
Reporter: r-a-y | Owner:
Type: defect (bug) | Status: new
Priority: high | Milestone: 2.1
Component: Core | Version:
Severity: normal | Resolution:
Keywords: has-patch 2nd-opinion |
Changes (by boonebgorges):
* priority: normal => high
Circling back around to this, because I think that it's holding up a
number of other items (#5407 in particular).
The basic problem is that some components are interdependent. In some
cases, it makes sense to fix this by reconfiguring the load order of the
components themselves. In others, the problem is that there's too much
happening in a specific method, so that the interdependencies would be
cleared up if the separate events were split into different methods that
loaded on different actions.
In that spirit, 5436.04.patch builds on the previous patches, with some
additional enhancements to straighten out additional errors I was getting
in my testing. A summary:
- Introduce `BP_Core_Component::setup_canonical_stack()`, and move Groups
and Members canonical_stack calculation here. Why do this? Canonical stack
calculation requires the idea of a "default component". But default
components are determined, in part, by looking at component slugs and
`$bp->pages`. Both of these are set up during `setup_globals()` methods in
various components. So, instead of juggling the order of
Core/Activity/Members/Groups to make this sorta-kinda-work, we just do
canonical stack calculation on a later priority.
- Move `bp_setup_core()` to fire at `bp_loaded` with priority 0. (Makes
sense that core would need to run first.)
- Move xprofile overrides of loggedin_user and displayed_user display
names into the xprofile component, so that
`BP_Members_Component::setup_globals()` is no longer dependent on
- Move `bp_setup_xprofile()` to priority 2. This ensures that it loads
after core and members, but before everything else. I needed to do this to
ensure that other components had access to xprofile display name data.
It's not ideal, but it doesn't seem too arbitrary either - it makes sense
that other components would need access to profile data at loadtime (but
not necessarily the other way around).
In my light testing, this clears up all of the problematic dependencies.
r-a-y and others, would really like your thoughts so we can get something
into trunk early in this cycle.
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5436#comment:9>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac