(if you look carefully you can see that there’s a reference to the actual path of the file on the server, not the URL)
I’ve traced the problem to the following line in the plugin:
$this->dir = plugins_url('',__FILE__);
It should be returning
Instead it’s returning
I’ve edited the plugin file so that it points to the proper path, but those changes will revert back every time the plugin is updated, so it’s not a long term solution.
I’ve seen some people complain that the
__FILE__ magic constant doesn’t work as expected with symlinks, but I certainly didn’t create any symlinks. Is this a limitation of using GoDaddy?
I’ve noticed that
__FILE__ returns something different on GoDaddy than on my local machine or on my other web server. One the two working machines it return the full path, from the root of the file system (ie,
/srv/www/sitename/public_html/file.php), while on GoDaddy the path it returns begins at the home directory (
Could that be the problem?
According to WordPress Codex
You can either specify the $path argument as a hardcoded path relative to the plugins directory, or conveniently pass __FILE__ as the second argument to make the $path relative to the parent directory of the current PHP script file.
plugins_url( basename( __DIR__ ) . '/path/to/plugin/asset.js' );
plugins_url( '/path/to/plugin/asset.js', __FILE__ );
is acceptable workaround for me. Maybe not so agile as specifying
You can try:
$this->dir = dirname(__FILE__);
If you’re running newer PHP versions, use
$this->dir = __DIR__;
I expect this has cropped up because of your server move.
Check your WordPress settings page to ensure that the WordPress URL reflects the new URL after the move.
If that is all correct, then something is overriding one of WordPress’ constants, either WP_PLUGIN_URL or one of the precursor constants that is used to set it. The place to look for that would be in the wp-config.php file.
This is likely to do with PHP now (it was not like that on older versions) always returns “physical” address of
__FILE__ ignoring any symlinks, etc. God knows (and PHP developers) why there is no setup on PHP to vary this behaviour but as WP compares that path to the URL on it has registered it changes it’s normal behaviour of returning the “rest” of the URL and returns the full path instead.
This basically means that WP and symlinks do not get on well as long as the Codex still recommends developers to use
__FILE__ to create the URL paths to load libraries while there are other methods that would not break any symlinks done at disk level.
This should solve your problem:
define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));