Сайт, который я создал, использует плагин Advanced Custom Fields, и все работает хорошо на localhost на моем собственном веб-хосте. К сожалению, когда я переместил сайт на хостинг, приобретенный клиентом (общий хостинг GoDaddy), файлы JavaScript и CSS для плагина Advanced Custom Fields загружаются неправильно. Проверка источника, проблема ясна – они указывают на следующий путь:
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
(если вы внимательно посмотрите, вы увидите, что есть ссылка на фактический путь файла на сервере, а не на URL)
Я проследил проблему до следующей строки в плагине:
$this->dir = plugins_url('',__FILE__); Он должен возвращать /wp-content/plugins/advanced-custom-fields
Вместо этого он возвращает /wp-content/plugins/home/content/06/10145906/html/wp-content/plugins/advanced-custom-fields
Я редактировал файл плагина таким образом, чтобы он указывал на правильный путь, но эти изменения будут возвращаться каждый раз, когда плагин обновляется, поэтому это не долгосрочное решение.
Я видел, как некоторые люди жалуются, что магия __FILE__ не работает __FILE__ образом с символическими ссылками, но я определенно не создавал никаких символических ссылок. Это ограничение использования GoDaddy?
Я заметил, что __FILE__ возвращает что-то другое в GoDaddy, чем на моем локальном компьютере или на другом веб-сервере. Одна из двух рабочих машин возвращает полный путь из корня файловой системы (т. /srv/www/sitename/public_html/file.php ), а на GoDaddy путь, который он возвращает, начинается в домашнем каталоге ( /home/content/06/10145906/html/file.php ).
Может ли это быть проблема?
Согласно 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__ );
является приемлемым обходным решением для меня. Возможно, это не так гибко, как указание на __FILE__ .
Можешь попробовать:
$this->dir = dirname(__FILE__);
Если вы используете более новые версии PHP, используйте
$this->dir = __DIR__;
Я ожидаю, что это произошло из-за перемещения вашего сервера.
Проверьте страницу настроек WordPress, чтобы URL-адрес WordPress отображал новый URL после перемещения.
Если это все правильно, то что-то переопределяет одну из констант WordPress: WP_PLUGIN_URL или одну из констант-предшественников, которая используется для ее установки. Место для поиска будет в файле wp-config.php.
Скорее всего, это связано с PHP (это было не так, как в старых версиях) всегда возвращает «физический» адрес __FILE__ игнорируя любые символические __FILE__ и т. Д. Бог знает (и разработчиков PHP), почему нет никакой установки на PHP для изменения этого поведения но по мере того, как WP сравнивает этот путь к URL-адресу, на котором он зарегистрировал его, он изменяет обычное поведение возврата «остального» URL-адреса и вместо этого возвращает полный путь.
Это в основном означает, что WP и символические ссылки не получают __FILE__ пока Codex по-прежнему рекомендует разработчикам использовать __FILE__ для создания путей URL для загрузки библиотек, тогда как существуют другие методы, которые не нарушали бы символические ссылки, выполненные на уровне диска.
Это должно решить вашу проблему:
define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));