Changeset 8610 for trunk/src/bp-xprofile/bp-xprofile-loader.php

Timestamp:

07/12/2014 03:01:27 AM (11 years ago)

Author:

boonebgorges

Message:

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

File:

• trunk/src/bp-xprofile/bp-xprofile-loader.php (modified) (2 diffs)

trunk/src/bp-xprofile/bp-xprofile-loader.php

@@ -219 +219 @@
         }
 
-        // Privacy Settings
-        if ( bp_is_active( 'settings' ) ) {
-
-            // Get the settings slug
-            $settings_slug = bp_get_settings_slug();
-
-            // Add the sub-navigation
-            $sub_nav[] = array(
-                'name'            => __( 'Profile', 'buddypress' ),
-                'slug'            => 'profile',
-                'parent_url'      => trailingslashit( $user_domain . $settings_slug ),
-                'parent_slug'     => $settings_slug,
-                'screen_function' => 'bp_xprofile_screen_settings',
-                'position'        => 30,
-                'user_has_access' => bp_core_can_edit_settings()
-            );
-        }
+        // The Settings > Profile nav item can only be set up after
+        // the Settings component has run its own nav routine
+        add_action( 'bp_settings_setup_nav', array( $this, 'setup_settings_nav' ) );
 
         parent::setup_nav( $main_nav, $sub_nav );
+    }
+
+    /**
+     * Set up the Settings > Profile nav item.
+     *
+     * Loaded in a separate method because the Settings component may not
+     * be loaded in time for BP_XProfile_Component::setup_nav().
+     *
+     * @since BuddyPress (2.1.0)
+     */
+    public function setup_settings_nav() {
+        if ( ! bp_is_active( 'settings' ) ) {
+            return;
+        }
+
+        // Determine user to use
+        if ( bp_displayed_user_domain() ) {
+            $user_domain = bp_displayed_user_domain();
+        } elseif ( bp_loggedin_user_domain() ) {
+            $user_domain = bp_loggedin_user_domain();
+        } else {
+            return;
+        }
+
+        // Get the settings slug
+        $settings_slug = bp_get_settings_slug();
+
+        bp_core_new_subnav_item( array(
+            'name'            => __( 'Profile', 'buddypress' ),
+            'slug'            => 'profile',
+            'parent_url'      => trailingslashit( $user_domain . $settings_slug ),
+            'parent_slug'     => $settings_slug,
+            'screen_function' => 'bp_xprofile_screen_settings',
+            'position'        => 30,
+            'user_has_access' => bp_core_can_edit_settings()
+        ) );
     }
 
@@ -355 +377 @@
         $bp->profile = new BP_XProfile_Component();
 }
-add_action( 'bp_setup_components', 'bp_setup_xprofile', 6 );
+add_action( 'bp_setup_components', 'bp_setup_xprofile', 2 );