Плагіни в посиланнях, що зв'язані між собою?

20

Коли я розробляю плагіни, я тестую їх на декількох версіях 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.

plugin-development customization

— Ян Фабрі
джерело

6

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

Він не буде обробляти всі інші випадки, коли plugin_basename()використовується, наприклад, register_activation_hook()та co.

Більше інформації: http://core.trac.wordpress.org/ticket/16953

— скрип
джерело

Я вважаю, що використання WP_PLUGIN_URLне рекомендується, оскільки адміністраторам слід дозволити змінити ім'я цього каталогу конкретного плагіна, але чи є ще одна причина, щоб цього уникати? І справді, ваш квиток був би простим рішенням.

— Ян Фабрі

Навпаки. WP_PLUGIN_URL містить лише URL-адресу, яка вказує безпосередньо на "плагіни". Дивіться оновлену відповідь.

— scribu

@scribu: Але що робити, якщо мої плагіни живуть, /external/folder/banana-plugin/але адміністратор посилається на цей каталог як /httpd-root/wp-content/plugins/apple-plugin/? Тоді вона спробує перейти /wp-content/plugins/banana-plugin/, ні? І я вважаю, адміністратору слід вільно вибирати окремі імена каталогів плагінів?

— Ян Фабрі

Я більше не буду з вами сперечатися з цим питанням, тому що знайшов рішення: фільтр 'plugins_url'. Ще раз оновлена відповідь.

— scribu

FWIW це рішення може бути схильним до помилок і залежить від розробки плагінів лише за допомогою plugins_url () після завантаження всіх плагінів, інакше ви не можете зареєструвати фільтр до виклику функції. плагін Akismet та багато інших мають цю проблему.

— jerclarke

3

В даний час я використовую хитрість, щоб отримати розташування файлів, що відносяться до 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% усіх установок, тільки моя настройка розробки не вдасться, і я можу легко випустити нову версію.

— Ян Фабрі
джерело

Чудове рішення @Jan. Я реалізував щось подібне, викликавши функції та циклічно, бо забув, що ці змінні були доступні як global. Завдяки вашій публікації тут, я зрозумів, що можу зробити це набагато простіше. BTW, я також перевіряю false === strpos( __FILE__, WP_CONTENT_DIR )перед тим, як запускати ваші оператори if, тому що я припускаю, що плагін у WP_CONTENT_DIRньому не пов'язаний; Я сподіваюся, що це правильна логіка.

— MikeSchinkel

0

Коментар у помилці 46260 пропонує використовувати $_SERVER["SCRIPT_FILENAME"]замість __FILE__. Це працює?

— фуксія
джерело

1

Ні, це не змінюється у включених файлах. Так що якщоindex.php включає в себе library.php, $_SERVER['SCRIPT_FILENAME']по - library.php, як і раніше буде index.php. Але дякую за посилання на помилку, я уважно стежу за нею!

— Ян Фабрі

0

$_SERVER["SCRIPT_FILENAME"]працює, якщо правильно використовувати. Ви просто повинні використовувати його для встановлення базового шляху, а потім включати файли, використовуючи шлях відносно цього базового шляху.

Щось на зразок:

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

Зауважте, це корисніше, коли у вас ще немає доступу до wp-blog-header.php (тобто при обробці запиту на основі формату ajax)

— Чад Фурман
джерело