PHP Fatal error: Call to undefined function wp_get_current_user() when upgrading to version 3.7

[ascom]

When I just upgraded the WordPress on my server, it brought me to /wp-admin/upgrade.php. It was blank. When I checked my server log:

[Thu Oct 24 20:43:04 2013] [error] [client 96.xxx.xxx.xxx] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: PHP message: PHP Fatal error:  Call to undefined function wp_get_current_user() in /var/www/wp-includes/user.php on line 215

I haven't tried to reproduce it. Thinking it was something with the updater, I downloaded and extracted the update manually (didn't fix it). I fixed it by adding require_once("pluggable.php"); to the top of
/wp-includes/capabilities.php. Then it upgraded my database successfully.

[dd32]

This is caused by a plugin, can you revert your changes, deactivate all your plugins, and reactivate them to find the culprit?

There's ​at least one plugin I've seen so far, Reed Write which calls get_posts() upon inclusion.

Leaving open to find the cause and decide if it's a regression is just a bad doing it wrong scenario

[ascom]

I do not have the plugin Reed Write. When reinstalling 3.7, it doesn't hit the error. I've noticed that for 3.6.1 -> 3.7. I think someone forgot to do the correct includes, because it looks like a mistake in the core (edit:)when updating the database.

[dd32]

I wasn't able to duplicate on a clean install + upgrade of 3.6.1.

[usermrpapa]

I had Next Gen Gallery cause the same issue on one upgrade.

[kpdesign]

Seeing this report from the forums for Plugin Organizer plugin: ​http://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37?replies=1 and a couple more posts in the plugin's support forum: ​http://wordpress.org/support/plugin/plugin-organizer

[dd32]

The particular error is pretty common from plugins who run code on inclusion, rather than on plugins_loaded or init.
Basically plugins that run code on inclusion are _diong_it_wrong() and WILL break on a future release.

These plugins appear to be running get_posts() upon inclusion, which is completely wrong to be doing (also, CPT's are not a great place to store options...) which in turn needs to figure out user details - of which, come from pluggable functions.. which are not included until after Plugins are loaded.

[georgestephanis]

Related commits: r25689 and the big one of r25669 that swapped out the $user_ID global to get_current_user_id()

As Dion said, this is revealing bad practices in plugins and themes. Still, it'd be nice for a safety net. I'll try to pitch a diff tomorrow.

[nacin]

We don't need to revert everything in [25669]. Let's figure out what is possible to call prior to pluggable being loaded.

Looks to me like wp_insert_attachment(), wp_insert_post(), get_posts_by_author_sql() (which is a helper), and WP_Query itself.

I think we should patch get_current_user_id() to simply return 0 when that function does not exist. I don't love the idea of slowing down that function, but I don't think we use it extensively (it's not like calling it in a loop is going to be desired, the value doesn't change). At worst we can convert it to using $current_user directly, though I think we should just add a function_exists() check and call it a day. What a mess.

[dd32]

25690.diff​ is also a thought that came to me while talking to georgestephanis, so +1 on that approach.

[georgestephanis]

I'm not quite sold on a ternary here, but figured I'd kick it in. I think I prefer the original patch more, though, as it's more understandable to read, and we'd have a spot to add a doing_it_wrong() call.

[nacin]

Replying to georgestephanis:

I'm not quite sold on a ternary here, but figured I'd kick it in. I think I prefer the original patch more, though, as it's more understandable to read, and we'd have a spot to add a doing_it_wrong() call.

Yeah, that's just more work than is necessary.

[nacin]

In 25929:

Have get_current_user_id() return 0 when pluggable.php is not yet included (which brings the ability to set or get the current user).

fixes #25690 for trunk.

[nacin]

In 25930:

Have get_current_user_id() return 0 when pluggable.php is not yet included (which brings the ability to set or get the current user).

Merges [25929] to the 3.7 branch.

fixes #25690.

[ascom]

Here are some plugins that I use that I am suspicious of:
WP SEO by Yoast - PHP Warnings on upgrading plugins
Plugin Organizer - from kpdesign's comment
YARPP (probably not)

Now I can't think of any more...

[johnbillion]

We should put a _doing_it_wrong() in here too, but I'm not sure how useful it would be in practice if developers aren't already spotting other warnings and notices generated by their plugins.

[jrf]

@ascom FYI on the warning on upgrading plugins (and themes and core) in WP SEO by Yoast

This is caused by the WP 3.7 change in the 'upgrader_process_complete' hook which was passing 3 variables in WP 3.6 and only two in WP 3.7.

The 'error' in the plugin is not blocking anything else from working so is totally not critical. [I created a fix](​https://github.com/Yoast/wordpress-seo/issues/328) for this last Thursday which has already been committed to the plugin core. Just waiting a few more days to see if any other issues surface before releasing the plugin update.

[markoheijnen]

Heard that today and seems like a wrong move to remove the 3rd argument.

[johnbillion]

Changed in r25806 by the looks of things.

[dd32]

Yeah, the 'upgrader_process_complete' hook was kind of unmarked internal use only, Didn't realise there were plugins using it yet, It was added in 3.6 for LP support but wasn't actually properly implemented, resulting in having to change it in 3.7.

[jrf]

@dd32 WP 3.6 had just come out when I was working on that bit of WPSEO - checking for meta description tag in the header file of the current theme - and I wanted to make it as lean as possible. The upgrader_process_complete hook with a check for theme and action=upgrade seemed the leanest way to do it when a theme would be upgraded. The alternative for pre-WP3.6 was abusing a filter which is something I'd rather not do.

Anyway, a new version of WP SEO has been released by now which includes a fix.