WordPress’s plugins_url() function not working on shared hosting

2 Views

A site I’ve built uses the Advanced Custom Fields plugin, and everything works well on localhost on my own web host. Unfortunately, when I moved the site to the hosting that the client purchased (GoDaddy shared hosting), the JavaScript and CSS files for the Advanced Custom Fields plugin are not loading properly. Checking the source, the problem is clear – they are pointing to the following path:

http://www.clientsamazingwebsite.com/wp-content/plugins/home/content/06/10145906/html/wp-content/plugins/advanced-custom-fields/js/input-actions.js?ver=3.5.7.2

Read More

(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 /wp-content/plugins/advanced-custom-fields

Instead it’s returning /wp-content/plugins/home/content/06/10145906/html/wp-content/plugins/advanced-custom-fields

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?

Update

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 (/home/content/06/10145906/html/file.php).

Could that be the problem?

Post Views: 2

Related posts

Leave a Reply

5 comments

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

    So using

    plugins_url( basename( __DIR__ ) . '/path/to/plugin/asset.js' );

    instead of

    plugins_url( '/path/to/plugin/asset.js', __FILE__ );

    is acceptable workaround for me. Maybe not so agile as specifying __FILE__ though.

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

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