WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] Fatal error: Call to undefined function wp_get_current_user() (30 posts)

  1. David
    Member
    Posted 3 years 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?

  2. I'm thinking it could be, yes.

  3. Ron Rennick
    MultiSite Guru
    Posted 3 years ago #

    I was able to activate a plugin on a sub site in 3.0.2. Have you only tried the one plugin?

  4. Michael Bishop

    Posted 3 years ago #

    I'd check other plugins installed. I've not experienced that issue after upgrading several multi-site installs.

  5. 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

  6. dschmidt20
    Member
    Posted 3 years 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.

  7. dschmidt20
    Member
    Posted 3 years 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.

  8. dschmidt20
    Member
    Posted 3 years 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.

  9. 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. :)

  10. 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.

  11. dschmidt20
    Member
    Posted 3 years 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.

  12. Andrew Nacin
    Lead Developer
    Posted 3 years 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.

  13. Andrew Nacin
    Lead Developer
    Posted 3 years 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.

  14. David
    Member
    Posted 3 years 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.

  15. BayouGirl
    Member
    Posted 3 years 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

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

    I've tagged the post so it'll show up there.

  17. David
    Member
    Posted 3 years 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'

  18. Not all plugins are meant to be network activated.

  19. pete_voce
    Member
    Posted 3 years 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.

  20. spacetime
    Member
    Posted 2 years 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.

  21. Dunhamzzz
    Member
    Posted 2 years 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.

  22. RavanH
    Member
    Posted 2 years 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?

  23. 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.

  24. RavanH
    Member
    Posted 2 years 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...

  25. Was it network activated or per-site?

  26. RavanH
    Member
    Posted 2 years ago #

    per site, and only activated on the main site... activated on a sub site has no effect.

  27. Works fine for me on 3.3

  28. RavanH
    Member
    Posted 2 years 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...

  29. 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.

  30. sparkweb
    Member
    Posted 2 years 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.

Topic Closed

This topic has been closed to new replies.

About this Topic