url() function not working on shared hosting

2018-06-24 12:15:06

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

(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?

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.

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.

链接地址: http://www.djcxy.com/p/68662.html

上一篇: 最简单的方法来找到缺少的CSS类和ID

下一篇: url（）函数不能在共享主机上工作