fatal errors when enabling BP components

[DJPaul]

When trying to enable any non-default BP component, I get a fatal error. For example, when activating the Groups component:

[01-Apr-2014 19:03:40 UTC] PHP Fatal error: Call to undefined function bp_get_groups_slug() in /srv/www/wordpress-develop/src/wp-content/plugins/buddypress/bp-activity/bp-activity-loader.php on line 314

I have recreated this on a MAMP-powered site, as well as on a new VVV-powered site.

[DJPaul]

Did we change any component load order stuff in 2.0?

[boonebgorges]

Did we change any component load order stuff in 2.0?

I don't think so, though see #5436. Maybe you could use a bisect tool too track it down.

FWIW I tried this on a fresh installation on my dev machine and could not reproduce. Not to say it's not a problem, but it does appear to be dependent on environment in some way. DJPaul, can you say more about your setups? Could this be related to PHP version or something like that?

[DJPaul]

Replying to boonebgorges:

DJPaul, can you say more about your setups?

I have literally formatted my laptop and reinstalled OS X because I initially thought that this was initially a strange bug in my hacked-together old MAMP install. I'm now on a clean OS X install and am using VVV which I downloaded and set up a few hours ago. I'm using the default VVV install at ​http://src.wordpress-develop.dev/ (wordpress trunk from the develop repo). Let me go fetch version numbers.

[DJPaul]

Versions:

• github.com/Varying-Vagrant-Vagrants/VVV.git - rev 58fe8627df8d
• Vagrant 1.5.1
• VirtualBox 4.3
• WordPress develop trunk r27893
• PHP 5.5.10-1+deb.sury.org~precise+1
• MySQL 5.5.35-0ubuntu0.12.04.2

Quick, low-res video demonstrating bug: ​http://cl.ly/2z123x0y1Q2x

[DJPaul]

Oh, and I forgot to say that I tried git bisect'ing trunk back to around v1.9.2, and still had the same problem. The video/testing above was recorded using a fresh 1.9.2 download from wordpress.org, so whatever the problem is, it exists there, too.

[DJPaul]

I set up a version of VVV running PHP 5.4.26-1+deb.sury.org~precise+1 (tested on BP 1.9.2 again) (everything else is otherwise identical), and still get the same issue.

[boonebgorges]

Here's what's happening:

• We save the component options here: ​https://buddypress.trac.wordpress.org/browser/tags/1.9.2/bp-core/admin/bp-core-components.php#L233 During the POST request, the newly active components are not only saved to the DB as the new active_components variable, but they are also loaded into $bp->active_components to act as the active components for the current pageload
• At the end of the function, wp_redirect() is run, which sends a Location header to the browser. This works, and sends the user back to the Components settings page. But it does not stop script execution on the pageload (the one triggered by the POST request). The admin panel continues to load on the server.
• Recall that, in this "phantom" pageload, the new component is marked as "active" in the $bp global. Say you've activated Settings. As components load themselves, bp_is_active( 'settings' ) will return true. But the Settings component has not actually been loaded - the files have not been included, because by the time the component settings are saved, our includes() methods have all been run. So we get the fatal errors you've experienced.

This does not actually affect the proper functioning of BP. Component settings are still saved correctly, and they install themselves correctly. Everything loads as expected on the next (GET) pageload. It's just this phantom fatal error on an abandoned process.

There are two options for fixing this:

1. When saving the components, store them in a local variable $active_components, which would get passed to bp_core_install() etc. WP continues its phantom pageload, but BP does not attempt to load the uninitialized components.
2. Kill the process right after the redirect. This is the simplest, and probably best. See 5506.patch.

DJPaul, please test to verify that this solves the problem for you.

Side note: it's likely that something similar is happening throughout BP, whenever we use wp_redirect(). It's never occurred to me before, but as a best practice, we probably ought to use die after every redirect. At the very least, it'll prevent wasted CPU cycles.

[DJPaul]

This is fixing the problem for me. Excellent work tracking it down. Thanks Boone.

[boonebgorges]

In 8230:

Exit after saving component settings in Dashboard

Allowing the PHP process to continue after wp_redirect() resulted in
background fatal errors, as components attempted to initialize based on
active_components information that did not properly match the libraries that
had actually been loaded. Plus it wastes CPU cycles.

Fixes #5506