Today, I ran in to a most peculiar issue involving a plugin called Easy Nivo Slider running on a WordPress Multi-Site installation. Let me try to explain what happened.
Fatal error
After installing the plugin in question on the network and activating it on the main site, I could no longer access the Network Admin section. The server error log said:
Fatal error: Call to undefined function wp_get_current_user()
That’s a WP core function. And if an error like that occurs, it suggests that the function is called at a time when core functions is not available yet. Usually this is before the init action has been run. So, thinking the plugin might be calling core functions outside of the designated init hook, or any other hook for that matter, I started looking through the plugin files for irregularities like that.
Nothing I could find… Besides, how could a plugin running on a site be affecting the network admin like that? Time to Google.
Help me, Google
With the error as search term, I ran across an older thread on the WordPress forums that started with that same error. And subsequent notions about how to disable plugins and the irregular (or the lack of) use of WordPress hooks. But somewhere down the line, some user and plugin dev called spacetime suggested that this happened to his plugin too (Ad Inserter, not Easy Nivo Slider) and it was solved after he renamed the included file called settings.php. Nobody responded to his suggestion.
And what a bizarre notion. Why would the name of a plugin file be of any concern? As long as it does not have characters that are not allowed in file names, right? Curiously, I looked at the files of the plugin I had just installed and yes, it did indeed has a file called settings.php in it.
Worth testing…
And?
And, as you might have guessed by the title of this post, renaming the file and adapting the include statement in the main plugin file did indeed solve the issue. At least, as long as I did not rename it to options.php. When I did that, I no longer had access to the Site Admin section!
Do you believe that? I was shocked, I can tell you. I never ran in to this before. I have not tested further because this all happened on a live network but I really wonder if there are other names that should not be used for WordPress plugin files.
What does this mean?
Well… to be honest, I’m not sure. A plugin file name should not be able to cause complete blackout of the WordPress back-end, should it?
Does anyone know more about this? Google remains silent in this case.
Is this a WordPress bug and if so, has this been around for long? Does it only occur on Multi-Site installations? I tested on WPMS 3.1.4 and 3.2.4 but not on a regular WordPress installation. Obviously using settings.php would cause no issue as on regular WordPress becuase it has no Network Admin section, but using the name options.php might have the same effect.
If I find out more – and if it’s interesting enough – I’ll post about it later. Oh, and please do not hesitate to use the comments to share your knowledge on the matter. 🙂
