WordPress › Support » Fatal error: Call to undefined function wp_get_current

David
Member
Posted 1 year ago #

Well, I've mucked this up pretty bad now. While messing around with WP-MS (after auto upgrading 3.0.2) I activated a plugin in my subdoman site which caused me to receive this error:

Fatal error: Call to undefined function wp_get_current_user() in /home/mysite/mysite.com/wp-includes/capabilities.php on line 1059

So I went ahead and deleted the site, and the admin user for that site, and recreated them. Still the same Error... any thoughts?

Also: I thought this was an error that occurred because of my activation of that plugin, but I tried to start a third site (to see if there were just residual files) that new site is also showing the above 'Fatal error' Is this a bug from the update?
Andrea_r
team pirate
Posted 1 year ago #

I'm thinking it could be, yes.
Ron Rennick
MultiSite Guru
Posted 1 year ago #

I was able to activate a plugin on a sub site in 3.0.2. Have you only tried the one plugin?
Michael Bishop
Forum Concierge
Posted 1 year ago #

I'd check other plugins installed. I've not experienced that issue after upgrading several multi-site installs.
Andrea_r
team pirate
Posted 1 year ago #

Oh phew - there was another user having the same issue. no mention of the same steps.

http://wordpress.org/support/topic/new-multi-sites-dont-appear?replies=10
dschmidt20
Member
Posted 1 year ago #

I'm totally lost. I just went to update my multisite install and recieved the error Call to undefined function wp_get_current_user(). I went into phpmyadmin and manually disabled all plugins (which is what I should have done beforehand, but hindsight's 20/20).

Now I can't access my root site or any of my sites in sub-directories. I'm having flashbacks to the white screen of death.

If anyone can help I would truly appreciate it.
dschmidt20
Member
Posted 1 year ago #

Ok all better. This is like multisite 101. When all else fails make sure to manually disable all plugins across your sites by going into MYSQL and running this query for each of your sites:

SELECT * FROM wp_options WHERE option_name = 'active_plugins';

Then reinstall WordPress and refresh the page. This is the quintessential step in updating anything multisite and the one I seldom remember. Live and learn I guess.
dschmidt20
Member
Posted 1 year ago #

My apologies blasting this thread, but something tells me this latest update bug is an issue with W3 Total Cache. I was in the process of reactivating my plugins and the error reoccurred when I attempted to activate W3TC.

With this otherwise incredible plugin, I have had quite a few problems with W3TC and multisite, particularly with writing .htaccess, and object cache bringing 404 errors on my subdirectories.

A fairwarning to all multisite newbies: If you are using W3TC make sure it is deactivated EVERYWHERE before updating.
Andrea_r
team pirate
Posted 1 year ago #

When all else fails make sure to manually disable all plugins across your sites by going into MYSQL and running this query for each of your sites:

SELECT * FROM wp_options WHERE option_name = 'active_plugins';

Or rename the plugins folder. :)
Ipstenu
Half-Elf Support Rogue & Mod
Posted 1 year ago #

W3 Total Cache is working fine for me on a 3.0.2 multisite with BuddyPress and a metric ton of plugins. And I didn't deactivate before upgrading cause I'm reckless ;)

That said, I also did a manual upgrade.
dschmidt20
Member
Posted 1 year ago #

You're right ipstenu... my bad. W3TC is cool. It was WP Link Directory... what is now becoming a fossil plugin. I'm going to see if there is any magic I can work to bring it up to speed with multisite or atleast see if the developer can point me in the right direction.
Andrew Nacin
WordPress Dev
Posted 1 year ago #

The issue here is as follows:

pluggable.php doesn't get loaded until after all plugins are loaded. This cripples a lot of functions that then rely on, directly or indirectly, wp_get_current_user(), among others.

We don't even load the current user until just before the init hook. Doing anything to the current user before the init hook will not work.

Now, here's where I think we're going to have a compatibility problem. While the plugins were certainly doing it wrong, I think we changed a bunch of $current_user references to wp_get_current_user() -- one doesn't fatal when it doesn't work, and the other obviously does.

I'm going to investigate some changes and get back to you.
Andrew Nacin
WordPress Dev
Posted 1 year ago #

The change I'm thinking of is http://core.trac.wordpress.org/changeset/15452. First thing that tipped me off to this not being a problem is that we backported that to 3.0.1, and I haven't heard too many complaints.

Second, I don't see any logic in capabilities.php there. In fact, that line is from current_user_can() itself (which cannot be called before init), which was given the wp_get_current_user() treatment about five years ago:

http://core.trac.wordpress.org/changeset/3566/trunk/wp-includes/capabilities.php.
David
Member
Posted 1 year ago #

Confession I am a codebaby/hobbiest, and must rely on my limited working knowledge of wordpress. I am going to suggest the following fix:

1. Backup blog
2. Delete WordPress (wipe all directory)
3. Install wordpress
4. Import blog

I'm guessing this should work, but If there is a more efficient way please advise.
BayouGirl
Member
Posted 1 year ago #

I'm so glad I found this post!!!1 Right when I was about to become a screaming banshee (well I did for a moment..)

I can't speak for anyone else...but DEFINITELY don't use the wp-link directory plugin.......got the exact same message when trying to activate plugins after upgrade....it's what made me post in another thread...

Removed it from my plugin folder..now everything works fine...

Hope that helps someone else because it's just maddening when you're not sure how to track down what's not working when you're a "codebaby"....

I appreciate what you guys are doing here.....

Peace
Ipstenu
Half-Elf Support Rogue & Mod
Posted 1 year ago #

Start reporting it broke here: http://wordpress.org/extend/plugins/wordpress-link-directory/

I've tagged the post so it'll show up there.
David
Member
Posted 1 year ago #

I was also able to (trial and error)narrow the error to a single plugin, which works on the main site but causes this error when set to 'network activated'
Andrea_r
team pirate
Posted 1 year ago #

Not all plugins are meant to be network activated.
pete_voce
Member
Posted 1 year ago #

Thanks Andrea_r,
I simply renamed plugins to plugins2, then went to the Network Admin page without issue, then renamed plugins2 back to plugins and it has cleared up my issue. I love a good quick fix.
spacetime
Member
Posted 10 months ago #

It seems I have found what causes problem but not why it is causing a problem.

On my plugin the problem was because there was a file called settings.php. After renaming it to something else the error disappeared!

I just don't know why settings.php causes error in network mode.
Dunhamzzz
Member
Posted 10 months ago #

The problem was correctly diagnosed by Andrew Nacin above.

Some plugins try to call various user functions as soon as they are loaded, so the user function they need is not available yet. These calls should be added to the 'init' action to make sure the WP environment is fully loaded and available to use.
RavanH
Member
Posted 8 months ago #

OMG, that's it... I ran into the same with Easy Nivo Slider plugin activated on the first site in my network blocking access to the Network Admin section. And indeed it has a file called settings.php. And a similar thing happens when there is a file called options.php: the Site Admin section is no longer accessible.

Disabling the plugin solved the issue. Then after renaming the file settings.php to(for example) settings-form.php and editing the include statement to keep funcitonality of the plugin itself, I could run both the plugin and access Network Admin at the same time.

To replicate the issue:
- Do a clean WP install and upgrade to Multi Site;
- install Easy Nivo Slider or any other plugin that has a file called settings.php or options.php in it;
- enable it on the main site;
- try to access the Network Admin section...

To solve:
- rename the plugins file settings.php or options.php to anything else
- adapt the include statement in the main plugin file to reflect the new name

Conclusion:
When a plugin file bears the name settings.php, Network Admin is blocked. When a plugin includes a plugin file called options.php, the Site Admin is blocked.

It looks to me like this is a WordPress bug. I've only tested this on a 3.2.1 multi-site install that has been recently upgraded from 3.0 so no idea if this behaviour always occurs but in theory, it should not matter how individual plugin files are named. Or am I mistaken?
Ipstenu
Half-Elf Support Rogue & Mod
Posted 8 months ago #

RavanH - I think that should go in trac. I'm not sure it's a bug, but it should be at least looked at. I can't find an extant ticket on that.
RavanH
Member
Posted 8 months ago #

Hi Ipstenu, I've never submitted to trac before... please allow me some time ;)

Can you replicate this maybe? Or is it caused by other plugins on the same install. In my case, the Easy Nivo Slider was the only plugin activated on the main site but there are others installed and running on other sites in the network...
Ipstenu
Half-Elf Support Rogue & Mod
Posted 8 months ago #

Was it network activated or per-site?
RavanH
Member
Posted 8 months ago #

per site, and only activated on the main site... activated on a sub site has no effect.
Ipstenu
Half-Elf Support Rogue & Mod
Posted 8 months ago #

Works fine for me on 3.3
RavanH
Member
Posted 8 months ago #

I see this happening on a 3.1.4 and 3.2.4 multi-site install. Both with the same other plugins installed but not running.

What happens if you rename the settings.php to options.php and adjust the include statement in the main plugin file accordingly?

When I get the time, i'll do some testing with a clean install...
Ipstenu
Half-Elf Support Rogue & Mod
Posted 8 months ago #

Still no problems.

I spun up my local install and it worked fine too, but that's also on 3.3. ... Wonder if they fixed it.
sparkweb
Member
Posted 7 months ago #

I just ran into this with my plugin (FoxyShop). I had actually discovered a while back that using the filename "tools.php" in my plugin caused major trouble in regular WordPress. I just discovered that setup.php and settings.php are what were causing my plugin to bork multisite (in 3.2.1 - haven't tested 3.3 with this yet). I renamed settings and setup (tools had already been renamed) and now the plugin works like a charm.

My conjecture is that the files (settings, setup, tools, options) are protected for some reason and when they are called they initialize current_user_can() or a subset of that.

Come to think of it, shortcode.php and widget.php also broke my plugin.