PHP fatal error
-
[27-Feb-2015 18:15:42] PHP Fatal error: Call to undefined function plugin_dir_path() in
/public_html/wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45
-
Hi njrfbzr,
plugin_dir_path() is a core WordPress function; it should never be missing within WordPress, but this might happen if one of the plugin files was accessed directly. If you’re concerned about this, consider securing your plugin directories via your webserver configuration, i.e., with .htaccess rules in apache.
Actually, it depends on when the function is called. It may not be available *yet* in certain circumstances…
That error is showing up in everyone’s error_log file. It’s all over the web if you search on the error string and all in one seo pack you will find a lot of them. I hope it’s just a minor issue…
jrf,
Provide an example, please? It’s in wp-includes/plugin.php which means that there’s never a case when a loaded plugin wouldn’t have access to it.
dtynan,
This is entirely harmless; also isn’t an issue within WordPress, it’s a server configuration issue, but nevertheless I’ll see if I can add some code to check for this case and work around it in the event that people have plugin directories that are getting accessed.
How would I secure my plugin directories in .htaccess while still allowing access by WordPress? Thanks!
Hi njrfbzr,
The easiest thing to do here is to add an .htaccess file in your plugins directory consisting of the directive:
deny from all
WordPress will still be able to access the php files etc. inside the plugins directory on the server; however, this can get complicated if a plugin intends the user to have access to (for example) a .css file inside the plugin directory. In that case you might want to make exceptions for individual plugins or files, either by adding more .htaccess rules, or adding another .htaccess file in the plugin subdirectory to more finely control access. Here are some more security tips and .htaccess rules.
Thanks for the link, I’ll have a look.
+1 for this issue.
We’ve found it in our debug.log a few times as well. We’ve got proper security and .htaccess configuration on all our sites. (Also, in general with .htaccess if you do deny from all, you need to add an exception for your site’s IP address, as it would block your own server during WordPress cron jobs and prevent them from completing.)
Instead of advising people to add .htaccess though (leaving security up to users is risky), I’d recommend you add a killswitch to the beginning of the plugin to prevent direct access. Something like this is getting more common in plugins these days:
`if ( !function_exists( ‘add_action’ ) ) {
die( ‘ERROR: This plugin requires WordPress and will not function if called directly.’ );
}`Use your own error message as you see fit.
This is a similar one from Akismet for example:
`// Make sure we don’t expose any info if called directly
if ( !function_exists( ‘add_action’ ) ) {
echo ‘Hi there! I\’m just a plugin, not much I can do when called directly.’;
exit;
}`Some points you may want to consider:
1. .htaccess and/or the snippet which @redsand provides are both only a valid solution if and only if, the error would be caused by the file being called directly – which most often would happen as a potential hack attempt.Without a backtrace of the error there is however no way to determine if that’s the cause of the notice showing up.
To get a backtrace, you can use this code – do follow the inline instructions carefully!2. All the code at the top of that file will be executed in the global namespace at file load. Better to run it at the
plugins_loaded
hook, i.e. you could add nearly all of that code to the start of theaioseop_init_class
function without any change in functionality (constants are always global even when defined from within a function).3. You may also want to wrap the
add_action()
call to plugins_loaded within a check for plugin installing as that sometimes gives issues too.
Like so:if ( ! defined( 'WP_INSTALLING' ) || WP_INSTALLING === false ) { add_action( 'plugins_loaded', 'aioseop_init_class' ); }
Hi Scott and jrf,
Thanks for the tips; we’ll have a fix for this in the next update (by checking for ABSPATH if you’re curious); I don’t plan on adding an error message for this, though.
Hi Peter,
Sounds good. That’s a good option as well. Thanks for taking care of it.
If this error is caused by someone trying to run a plugin script behind the back of WordPress, so to speak, how can I prevent any or all plugin from running outside of WordPress? I mean there must be an across the board solution, right?
Or, perhaps there is no risk and it is only the error message itself that is a problem?
[19-Mar-2015 01:46:44 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 [19-Mar-2015 01:57:36 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 [19-Mar-2015 02:00:15 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 [19-Mar-2015 02:03:01 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 ===================== [05-Mar-2015 20:22:37 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 [05-Mar-2015 20:26:05 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 [05-Mar-2015 20:26:48 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 45 [05-Mar-2015 20:27:29 PHP Fatal error: Call to undefined function plugin_dir_path() in /wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 4
@njrfbzr without a backtrace, that error message is next to useless. Please do a proper backtrace with the code I linked to in my one of my previous messages.
I would love to do a backtrace, but I am not a coder or programmer. I do not know php and I do not understand regular expressions. Unfortunately, I have not the required ability or knowledge to do a backtrace so I guess I am SOL.
I would love to do a backtrace, but I am not a coder or programmer. I do not know php and I do not understand regular expressions.
That’s why I gave you the link to the code. If you’ve edited the wp-config.php file manually ever, this really shouldn’t be a problem.
No programming knowledge needed, let alone regex knowledge. Just carefully read the instructions and follow the few *very* simple steps to get it working. It really is not hard.
- The topic ‘PHP fatal error’ is closed to new replies.