Плагины в каталогах с символическими ссылками?

Когда я разрабатываю плагины, я тестирую их на нескольких версиях WordPress, вставляя ссылки на каталог моих плагинов в разные wp-contentкаталоги. Это замечательно, поскольку мне нужно редактировать файлы только один раз, но это нарушает важную конструкцию для генерации ссылок на ресурсы в моем плагине: __FILE__относится к физическому расположению плагина, а не к тому, в котором он находится wp-content. Как мне решить это?

Моя структура каталогов выглядит так:

• /path/to/wordpress/development/dir/
  • plugin-development/
    • monkeyman-rewrite-analyzer/
      • monkeyman-rewrite-analyzer.php
      • js/
        • monkeyman-rewrite-analyzer.js
  • versions/
    • 3.1/
      • wp-content/
        • plugins/
          • monkeyman-rewrite-analyzer как символическая ссылка на вышеуказанный плагин
    • 3.1-multi-dir/
      • wp-content/
        • plugins/
          • monkeyman-rewrite-analyzer как символическая ссылка на вышеуказанный плагин
    • 3.1-multi-domain/
      • wp-content/
        • plugins/
          • monkeyman-rewrite-analyzer как символическая ссылка на вышеуказанный плагин

Если я хочу епдиеий файл Javascript, я должен использовать plugins_url( 'monkeyman-rewrite-analyzer.js', [base file] ), но при использовании __FILE__здесь не буду работать, так как реальный путь к файлу будет /path/to/wordpress/development/dir/plugin-development/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, не /path/to/wordpress/development/dir/versions/*/wp-content/plugins/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.phpтак WordPress не может лишить первую часть и сгенерирует URL относительно установки WordPress.

Эта проблема может быть частично решена с помощью обязательного подключения плагина к plugins_urlфильтру.

Он не будет обрабатывать все другие случаи plugin_basename()использования, такие как register_activation_hook()и co.

Более подробная информация: http://core.trac.wordpress.org/ticket/16953

В настоящее время я использую трюк, чтобы получить местоположение файла, относящееся к WordPress: wp_get_active_and_valid_plugins()возвращает пути к файлам, wp_settings.phpперебирает их и включает в себя файлы . Таким образом, глобальная $pluginпеременная будет ссылаться на ваш текущий плагин (конечно, только когда плагин загружен, поэтому я сохраняю его в префиксной глобальной переменной):

$monkeyman_Rewrite_Analyzer_file = $plugin;

Поскольку плагины также могут быть загружены как обязательные или сетевые плагины, и эти циклы используют другие имена переменных , полный код выглядит следующим образом:

$monkeyman_Rewrite_Analyzer_file = __FILE__;
if ( isset( $mu_plugin ) ) {
    $monkeyman_Rewrite_Analyzer_file = $mu_plugin;
}
if ( isset( $network_plugin ) ) {
    $monkeyman_Rewrite_Analyzer_file = $network_plugin;
}
if ( isset( $plugin ) ) {
    $monkeyman_Rewrite_Analyzer_file = $plugin;
}

Откат остается прежним __FILE__, поэтому, если в будущем кто-то изменит имя переменной цикла, мой код все равно будет работать для 99% всех установок, произойдет сбой только моей настройки разработки, и я с легкостью смогу выпустить новую версию.

Комментарий в ошибке 46260 предлагает использовать $_SERVER["SCRIPT_FILENAME"]вместо __FILE__. Это работает?

$_SERVER["SCRIPT_FILENAME"]работает, если вы используете это правильно. Вам просто нужно использовать его, чтобы установить базовый путь, а затем включить ваши файлы, используя путь относительно этого базового пути.

Что-то вроде:

$plugin_dir = dirname($_SERVER["SCRIPT_FILENAME"]);
$myFile = $plugin_dir."/includes/js/myJavascriptFile.js";

Обратите внимание, это более полезно, когда у вас еще нет доступа к wp-blog-header.php (т.е. при обработке запроса формы на основе ajax)