Untangle some load order and mutual dependency issues between component loaders
BuddyPress's components are dependent upon each other in numerous ways. All
components depend in one way or another on bp-core. Many components reference
bp-members functions and globals. References to bp-xprofile can be found in
a number of components. And so on. We have managed to make these dependencies
work on a case-by-case basis, though the system becomes less stable as it
becomes more complex. The fact that all components are loaded at
bp_setup_components introduces the possibliity of numerous race conditions that
may not cause problems on vanilla installations of BuddyPress, but can cause
fatal errors when trying to customize in various ways.
As part of an ongoing project to disentangle and regularize these dependencies
(see eg #5750), this changeset introduces a few enhancements that make the
dependencies between components more predictable, more serialized, and more
stable.
- In bp-members and bp-groups, move canonical_stack determination out of the
main setup_globals() method and into its own setup_canonical_stack() method.
This new method runs after all components have had a chance to run
setup_globals(). As a result, the components are able to reference each other
safely when determining default and fallback components for redirects (for
example, the members component has access to the activity component's slug
and other global data when determining whether
example.com/members/boone/activity/ should resolve to example.com/members/boone/)
- In bp-members, use only WP core data to set up the loggedin_user and
displayed_user global objects. Previously, these objects were configured by
referenced to xprofile, which required that xprofile be loaded before members.
Now, users' display names are first loaded from wp_users, and are overridden
by the xprofile component via filter, only after xprofile has fully
initialized.
- In bp-xprofile, move the Settings > Profile navigation setup routine out of
the main setup_nav() task. bp-xprofile loads early, before bp-settings has
had a chance to set up its top-level navigation. As a result, bp-xprofile
must wait until the bp_settings_setup_nav action to add its Profile subnav
item.
- Fine-tune the component load order. bp-core, which acts more like a library
of common functionality than like a traditional component, is moved from
bp_setup_components:10 to bp_loaded:0. This ensures that it is available to
all other components. bp-xprofile, which must load after bp-members but at
the same time is closely coupled to it, is moved to bp_setup_components:2,
just after bp-members.
These changes are enough to make it possible to move forward on dependent
tickets; see, for example, #5407. It's likely that significant entanglement
and load-order issues remain. We'll continue to fix them as they arise, by
making load order more explicit, and by breaking the component bootstrap
process into increasingly discrete chunks.
Fixes #5436
Props boonebgorges, r-a-y