Знаком с WordPress довольно долго и в целом плотно, а вот про, так называемые, плагины Must-use узнал сравнительно недавно, писать статью на эту тему не думал, но так получилось что пишу, столкнулся с рациональной необходимостью этого типа плагинов…

Плагины обязательного использования (Must-use plugins), известные также под названием mu-plugins — это плагины, которые устанавливаются в специальную директорию в каталоге контента и всегда активны для сайта и всех сайтов сети. Эти плагины не видно среди обычных плагинов в админ-панели — они отображаются в верхней информационной строке и их невозможно отключить, кроме как удалить файл плагина из каталога wp-content/mu-plugins.

Необходимые плагины

Каталог таких плагинов можно изменить, для этого нужно определить константы: WPMU_PLUGIN_DIR и WPMU_PLUGIN_URL в файле wp-config.php.

Достоинства «необходимых» плагинов
  • Всегда включены, нет нужды активировать их в админ-панели.Пользователи не могут их отключить, намеренно или случайно;
  • Их можно подключить и активировать добавив файл плагина в каталогwp-content/mu-plugins, без необходимости авторизироватся на сайте;
  • PHP файлы каталога загружаются в алфавитном порядке, до того, как загрузятся обычные плагины. Это значит, что мы может произвести преждевременные проверки, установить хуки заранее, если это необходимо.
Недостатки  ;»необходимых» плагинов

Чаще всего нет необходимости использовать эти плагины и обычные плагины удобнее. Рассмотрим недостатки MU плагинов :

  • Не проверяются на наличие обновлений, а значит при появлении новой версии плагина мы не увидим уведомление о необходимости обновить плагин.  Поэтому следить за появлением новой версии нужно самостоятельно;
  • Хуки активации/деактивации плагина не срабатывает, а ведь именно на них вешаются действия связанные с установкой плагина или его удалением. Поэтому при активации добавлять таблицы или опции в базу данных и делать другие действия, а при деактивации удалять все что связано с плагином из базы данных и файлов придется самостоятельно.
  • WordPress ищет php файлы в каталоге my-plugin и делает это не так как для обычных плагинов — не просматривает файлы внутри вложенных папок. Поэтому, возможно, нужно будет создать загрузочный файл в каталоге my-plugin, чтобы он подключал файлы из подкаталогов, вот так:
    // mu-plugins/load.php
    require WPMU_PLUGIN_DIR.'/my-plugin/my-plugin.php';

Возникает вопрос, — в каких случаях может пригодится использовать mu плагины? Вопрос интересный, ровно как и случаи бывают разные, поэтому — может пригодится! Я, например, недавно поместил свой код в виде этого плагина, чтобы установить редиректы со старых УРЛов, когда изменял ЧПУ на уже давно рабочем сайте. Это показалось мне наилучшим решением, ведь:

  • вставлять такой редирект в тему не правильно — вдруг тему изменят и все редиректы исчезнут, а там бэк-линки;
  • устанавливать как плагин можно, но опять же случайно отключит кто-нибудь и редиректов нет. Да и не нужен этот код среди плагинов совершенно.

История Must-Use  плагинов

Изначально каталог «mu-plugins» был создан для плагинов сети WPMU (Multi-User), чтобы дать возможность администраторам активировать плагины для всей сети сайтов или блогов. На тот момент эта функция была необходима, из-за специфики Мультисайтовой сборки: администраторы не могли активировать плагины для всей сети из админ-панели. С версии 2.8 это стало возможно.

Код отвечающий за multi-user-plugins (mu-plugins), был перенесен в основной код WordPress, а до этого база кода wpmu была объединена с основной сборкой WordPress и все сайты, независимо от сборки, получили возможность автоматически загружать плагины, независимо от того, был ли это простой WP или WP Multisite. Такая возможность более удобна для всех видов установок WordPress и для разных ситуаций связанных с созданием сайта.

В результате этого изменения название «mu plugins» перестало соответствовать действительности, потому что теперь mu plugins работали и для обычной сборки. Префикс «mu» больше не означал, что эта функция относится к многопользовательской сборке — WPMU. Несмотря на это название решили оставить, но интерпретировать его иначе: «Must-use plugins», т.е. это те плагины, который всегда должны использоваться —необходимые плагины. Они работают для всех сайтов и не зависят от плагинов в админ-панели.

Интересно, что когда-то аббревиатура PHP означала «Personal Home Page», но затем была пере-интерпретирована как «PHP Hypertext Preprocessor» и, в духе хакерский традиций, превратилась в рекурсивный акроним.

Рекурсивный акроним — аббревиатура (акроним), который ссылается на себя.
В среде компьютерных хакеров стало традиционным выбирать акронимы (аббревиатуры, которые произносятся не по буквам), которые косвенно или напрямую ссылаются на себя. Одним из самых ранних примеров является появившаяся в 1977 TINT: «TINT Is Not TECO» («TINT — это не TECO»).

Углубимся в теорию

MU плагины загружаются раньше обычных. Давайте посмотрим как это происходит. Тут упомяну интересную картинку (очень она мне понравилась):

Порядок загрузки ядра WordPress

Что касается кода, как конкретно подключаются файлы. Смотрите фрагмент кода отвечающий за MU плагины, из файла темы wp-settings.php:

  1. // Загружаем MU плагины.
  2. foreach ( wp_get_mu_plugins() as $mu_plugin ) {
  3.     include_once( $mu_plugin );
  4. unset( $mu_plugin );

Код функции wp_get_mu_plugins():

  1. function wp_get_mu_plugins() {
  2.     $mu_plugins = array();
  3.     if ( !is_dir( WPMU_PLUGIN_DIR ) )
  4.         return $mu_plugins;
  5.     if ( ! $dh = opendir( WPMU_PLUGIN_DIR ) )
  6.         return $mu_plugins;
  7.     while ( ( $plugin = readdir( $dh ) ) !== false ) {
  8.         if ( substr( $plugin, -4 ) == ‘.php’ )
  9.             $mu_plugins[] = WPMU_PLUGIN_DIR . ‘/’ . $plugin;
  10.     closedir( $dh );
  11.     sort( $mu_plugins );
  12.     return $mu_plugins;

Как мы видим, директория WPMU_PLUGIN_DIR проверяется на существование и затем, если она существует просматривается на наличие в ней .php файлов, каждый из которых последовательно подключаются.