Fatal Error After Upgrading to BuddyPress 1.6

[steve7777]

I successfully upgraded to BuddyPress 1.6. However, I receive the following message whenever I try to do something: "Fatal error: Call to undefined function bp_displayed_user_id() in C:\Apache2.2\htdocs\wp-content\plugins\buddypress\bp-core\bp-core-template.php on line 1117." Function bp_displayed_user_id is defined in C:\Apache2.2\htdocs\wp-content\plugins\buddypress\bp-members\bp-members-template.php but it doesn't seem to be visible to bp-core-template.php. [NOTE: I am running WordPress 3.4.1 on my local Windows 7 PC]

[boonebgorges]

When you access wp-admin, do you see a "BuddyPress has been successfully updated! Please run the wizard" notice in yellow at the top? Have you run that wizard?

[steve7777]

WordPress said that BuddyPress was successfully updated when I upgraded to 1.6. When I go to ​http://127.0.0.1/wp-admin/, the fatal error is displayed on a white background with nothing else. There's no yellow and no wizard notice.

[steve7777]

I don't know if it's important, but the only place bp-members-template.php is referenced is in the buddypress.pot file.

[boonebgorges]

It's possible that you downloaded an incomplete copy of BuddyPress. Can you try downloading it again?

[austyfrosty]

I had the same issue. But mine was with bp-core-template.php:1117 bp_displayed_user_id() undefined function.

The file was there, so I removed bp_displayed_user_id() on line 1117, uploaded then activated bp-default and re-added the function back and uploaded. Seemed to to the trick..

[boonebgorges]

It'd be extremely helpful to see a debug_backtrace(), if anyone can make it happen.

I had a look at where bp_is_user() is called throughout BP. The only function that could possibly be called in a context where it'd cause this kind of error is in bp_core_new_subnav_item(). My guess is that the problem can be traced to ​http://buddypress.trac.wordpress.org/changeset/4600, where the bp_is_user() check was added.

This, in enough, isn't enough to cause fatal errors. It has to be combined with a plugin that is calling bp_core_new_subnav_item() in the right way - which is to say, too early. Again, this is a guess, but it's possible that you were both using plugins that do this thing that plugins used to do in the BP 1.1 era:

function foo() {
    bp_core_new_subnav_item( $args );
}
add_action( 'wp', 'foo', 2 );
add_action( 'admin_menu', 'foo', 2 );

The problem would be the admin_menu call, which might be early enough to load before the members component is loaded.

Can you guys give a list of the BP-dependent plugins you're running on your installations? Then we can look through and see whether any are doing what I suspect they're doing. If my theory is right, we can do a fix for 1.6.1 that will bail out of bp_core_new_subnav_item() when used too early (there's no need to run it in the admin anyway).

[steve7777]

The only plugin I have that references bp_core_new_subnav_item and admin_menu is BP Gallery in the bp-gallery.php file. The add_action line is add_action( is_multisite() ? 'network_admin_menu' : 'admin_menu', 'bp_gallery_add_admin_menu' ,20); I use multisite and have even commented the line but get the same error. The pages for the main site and the subsites appear to work properly but I get the fatal error whenever I try to access any dashboard. It still looks (to me) like bp-core-template.php doesn't have access to the bp_displayed_user_id function in bp-members-template.php.

[steve7777]

I added the two functions

function bpbp_displayed_user_id() {

static $id = 0;

if ( empty( $id ) ) {

global $bp;
$id = !empty( $bp->displayed_user->id ) ? $bp->displayed_user->id : 0;

}

return apply_filters( 'bpbp_displayed_user_id', $id );

}

function bpbp_loggedin_user_id() {

static $id = 0;

if ( empty( $id ) ) {

global $bp;
$id = !empty( $bp->loggedin_user->id ) ? $bp->loggedin_user->id : 0;

}

return apply_filters( 'bpbp_loggedin_user_id', $id );

}

to bp-core-template.php from bp-members-template.php, then changed all occurrences of bp_displayed_user_id and bp_loggedin_user_id to bpbp_displayed_user_id and bpbp_loggedin_user_id, resp. The name changes were done to avoid redeclaration errors when bp-members-template.php is loaded. Everything appears to be working properly now and I no longer seem to get the fatal error.

The problem is definitely in the bp-core-template.php file but I don't know if adding the two new filters causes any other problems.

[xsn0w]

Buddypress Scholarpress Courseware Triggers a fatal error for me on 1.6 - sure hope it gets updated soon. Does anyone know if I can easily change the functions in BP-SP-CW that are triggering the error?

[boonebgorges]

The problem is definitely in the bp-core-template.php file but I don't know if adding the two new filters causes any other problems.

Yes, no arguments about this. What I'm saying is that the call to bp_displayed_user_id() in that file happens in the template function bp_is_user(), which means that there's a place in your installation where bp_is_user() is being called prior to the members template files having been loaded. This should never happen on a BuddyPress installation, thus my suspicion that it's a plugin causing the problem. I'll keep investigating, and please, if you can post a debug_backtrace(), it will make it way way easier to get to the bottom of things.

[steve7777]

It looks like the BP Mag theme (not plugin) may be causing the problem (see debug trace). However, regardless of when the function bp_is_user() in bp-core-template.php is called, it should never cause a fatal error. Since my "fix" in comment 9 seems to have corrected the error, you should still change bp-core-template.php, especially since other plugins or themes may cause a fatal error. BTW, bp_displayed_user_id is called at lines 213, 1108 and 1117 in bp-core-template.php and any of these could now potentially cause a fatal error.

#0 bp_is_user() called at [C:\Apache2.2\htdocs\wp-content\themes\bp-mag\lib\ext\bp\core-ext.php:154] #1 bpmag_fix_bp_options_nav() called at [C:\Apache2.2\htdocs\wp-content\themes\bp-mag\lib\bp-hooks.php:2] #2 include_once(C:\Apache2.2\htdocs\wp-content\themes\bp-mag\lib\bp-hooks.php) called at [C:\Apache2.2\htdocs\wp-content\themes\bp-mag\functions.php:68] #3 include(C:\Apache2.2\htdocs\wp-content\themes\bp-mag\functions.php) called at [C:\Apache2.2\htdocs\wp-settings.php:287] #4 require_once(C:\Apache2.2\htdocs\wp-settings.php) called at [C:\Apache2.2\htdocs\wp-config.php:136] #5 require_once(C:\Apache2.2\htdocs\wp-config.php) called at [C:\Apache2.2\htdocs\wp-load.php:29] #6 require_once(C:\Apache2.2\htdocs\wp-load.php) called at [C:\Apache2.2\htdocs\wp-admin\admin.php:30] #7 require_once(C:\Apache2.2\htdocs\wp-admin\admin.php) called at [C:\Apache2.2\htdocs\wp-admin\edit.php:10] Fatal error: Call to undefined function bp_displayed_user_id() in C:\Apache2.2\htdocs\wp-content\plugins\buddypress\bp-core\bp-core-template.php on line 1118

NOTE: debug_print_backtrace() was inserted at line 1117 so the fatal error appears at line 1118 instead of 1117.

[boonebgorges]

Since my "fix" in comment 9 seems to have corrected the error, you should still change bp-core-template.php, especially since other plugins may result in a fatal error.

I agree that we should have a general fix, but simply having fallbacks for every single function in BuddyPress is not really feasible. The root of the issue is that bp-core-template.php is loaded before the Members component, and that a plugin is incorrectly taking advantage of the delay. We should either figure out why that gap has become obvious in BP 1.6 and take steps to correct it, or we should move functions like bp_displayed_user_id() into bp-core-template.php.

[steve7777]

I recently edited my last comment to say that the BP Mag theme (not plugin) may be the culprit. It's interesting that the pages of the sites and subsites seem to work properly but the fatal error only appears when I try to access any dashboard.

I certainly would prefer that the functions bp_displayed_user_id and bp_loggedin_user_id (and others?) be moved into bp-core-template.php

[boonebgorges]

OK, I have done a bit more investigation, and here's what I've found.

I can reproduce the problem with the following function:

function bp_4403_test() {
    if ( bp_is_user() ) {
        echo 'foo';
    }
}
add_action( 'bp_include', 'bp_4403_test', 7 );

The key here is that the function is loaded on 'bp_include', but at or before priority 8. If you load at 9 or above, then the components will have been loaded, and bp_displayed_user_id() will have been defined.

I took a look back through and found that changeset r5301 was responsible for making this happen. Prior to r5301, you could hook a function containing bp_is_user() nice and early and it will work fine. It looks like the reason is that we used to reference the global directly here.

On the one hand, it's likely that the plugins/themes that are causing this issue are doing something wrong, like using bp_core_new_subnav_item() way too early. On the other hand, this is a regression. Moreover, there's something wrong architecturally when functions in bp-core-template.php are dependent on functions that are loaded later on in the load order of BuddyPress. In the long run, we should probably work to fix this latter problem. In the short term, we have basically three options.

(1) Swap out the bp_displayed_user_id() call in bp_is_user() with a direct reference to $bp->displayed_user->id.
(2) Move bp_displayed_user_id(), and probably bp_loggedin_user_id(), into the Core component.
(3) Verify that my initial hunch is right, and this problem is caused by incorrect use of bp_core_new_subnav_item() (the only place I can see where bp_is_user() is used in the Core component). If I'm right, refactor that function so that it references the global directly instead.

In the short run, I would prefer (3), because it's the least intrusive. But I would first want verification from some of the folks reporting the problem that bp_core_new_subnav_item() is indeed the root cause of the problem - steve7777, in your case that would mean checking to see whether/how BP Mag uses bp_core_new_subnav_item(). (2) is acceptable but seems a bit hackish, in that it's a band-aid fix for the long-term problem that the functions are loaded in a funky order. (Likewise (1).)

Can I get some feedback from another dev?

[sbrajesh]

Hi Boone,
The option 2 seems best for compatibility reasons.

As of BP Mag, It does not use bp_core_new_subnav_item. I have been using the function bpmag_fix_bp_options_nav to fix the privacy issues concerning the options nav on user profile.

The problem is I am using the check, bp_is_user as soon as the functions.php is loaded(even before after_setup_theme). Even putting !is_admin() will fix that.

@steve7777 : which version of BP mag you used, I am testing 1.1.1 and It is not causing the error on multisite/standard wordpress with bp 1.6

[boonebgorges]

Hi sbrajesh. Thanks for jumping in here.

The problem is I am using the check, bp_is_user as soon as the functions.php is loaded(even before after_setup_theme).

Right. I figured you were probably doing something like this. The "correct" way, for what it's worth, is to hook your nav-modifying functions to 'bp_setup_nav'; if you use a priority like 100, you can be sure that BP has finished setting up all navigation.

I had a quick scan over the bp_is_* functions, and it looks at a glance like the only external functions used are bp_loggedin_user_id() and bp_displayed_user_id(). So I think we're safe to do (2) above. I'll take care of it for 1.6.1 unless one of the other devs has any objection.

[steve7777]

Boone/Brajesh,

I'm using BP Mag 1.1 (May 2012), the latest one posted at buddydev.com. As Brajesh stated, it does not use bp_core_new_subnav_item. Although I initially "hacked" bp-core-template.php so as not to worry about any possible problems with bp-members-template.php, I later moved functions bp_displayed_user_id and bp_loggedin_user_id to bp-core-template.php from bp-members-template.php, your 2nd option, and did not encounter any problems. I'll keep it this way until BP 1.6.1.

Thank you both.

BTW, What are the expected timeframes for BP 1.6.1 and BP Mag 1.1.1?

[xsn0w]

Buddypress Scholardpress Courseware triggers a fatal error in BP 1.6 - I am not sure if Stas plans to update for use with 1.6 so gaining some backwards compatibility with 1.6.1 would be awesome. Thank you, everyone

[boonebgorges]

xsn0w - I can't reproduce this issue - Courseware seems to be running fine for me. (At least it runs fine on activation.) If you want to open a separate ticket to explain how to reproduce the problem, please do; otherwise you should try to get in touch with Stas.

steve7777 - BP 1.6.1 will be probably be released in the next couple days.

[boonebgorges]

(In [6248]) Moves bp_displayed_user_id() and bp_loggedin_user_id() to Core component

The function bp_displayed_user_id() and bp_loggedin_user_id() are referenced
throughout BuddyPress's Core component when doing things like checking page
type. In certain circumstances, these checks might happen after the Core
component is loaded, but before the Members component is loaded. For this
reason, it's important that the functions live in Core rather than Members,
to avoid fatal errors.

Fixes #4403

Props steve7777

[boonebgorges]

(In [6249]) Moves bp_displayed_user_id() and bp_loggedin_user_id() to Core component

The function bp_displayed_user_id() and bp_loggedin_user_id() are referenced
throughout BuddyPress's Core component when doing things like checking page
type. In certain circumstances, these checks might happen after the Core
component is loaded, but before the Members component is loaded. For this
reason, it's important that the functions live in Core rather than Members,
to avoid fatal errors.

Fixes #4403

Props steve7777

[xsn0w]

Replying to boonebgorges:

xsn0w - I can't reproduce this issue - Courseware seems to be running fine for me. (At least it runs fine on activation.) If you want to open a separate ticket to explain how to reproduce the problem, please do; otherwise you should try to get in touch with Stas.

steve7777 - BP 1.6.1 will be probably be released in the next couple days.

Thank you for the reply, Boone!

I tried to ask Stas about it on the BP forums, but I was unable to leave a comment for him.

I also do not get an error code when activating, only a WP warning "Plugin could not be activated because it triggered a fatal error." Strange. I will continue to investigate and provide more information

[boonebgorges]

I will continue to investigate and provide more information

Thanks. Check your PHP error log, if you have access to it. Or, if you have a site that's not well-trafficked, try activating WP_DEBUG just before activating - you may get a more helpful error message.