Must-Use плагины в WordPress (mu-plugins)
Must-use plugins (mu-plugins, мю-плагины) — обязательные к использованию плагины — это плагины, которые устанавливаются в специальную папку /wp-content/mu-plugins
. Они активируются автоматически для сайта и сайтов сети, точнее такие плагины всегда активны.
Их невозможно отключить через админку. Для отключения нужно удалить файл плагина из каталога wp-content/mu-plugins
.
WordPress автоматически подключает все php файлы из папки /wp-content/mu-plugins
. Вложенные папки внутри папки mu-plugins не проверяются. Подключение php файлов из вложенных папок должно прописываться вручную, в файле который находится непосредственно в папке /mu-plugins
.
mu-plugins отображаются в верхней информационной строке в админ-панели.
Изменение каталога MU плагинов
Каталог Обязательных плагинов можно изменить. Для этого нужно определить константы: WPMU_PLUGIN_DIR
и WPMU_PLUGIN_URL
в файле wp-config.php.
Плюсы и минусы
Плюсы «необходимых» плагинов
-
Всегда включены, нет нужды активировать их в админ-панели. Пользователи не могут их отключить, намеренно или случайно.
-
Легко подключать и активировать, для этого просто нужно добавить файл плагина в каталог
wp-content/mu-plugins
. - Загружаются на раннем этапе загрузки WordPress - до того, как загрузятся обычные плагины. Файлы подключаются в алфавитном порядке.
Недостатки «необходимых» плагинов
Чаще всего нет необходимости использовать эти плагины, потому что обычные плагины удобнее.
-
Не проверяются на наличие обновлений, а значит при появлении новой версии плагина мы не увидим уведомление о необходимости обновить плагин. Поэтому следить за появлением новой версии нужно самостоятельно;
-
Хуки активации/деактивации плагина не срабатывает, а ведь именно на них вешаются события связанные с установкой плагина или его удалением. Поэтому при активации добавлять таблицы или опции в базу данных и делать другие действия, а при деактивации удалять все что связано с плагином из базы данных и файлов, придется самостоятельно.
-
WordPress ищет php файлы в каталоге my-plugin и делает это не так как для обычных плагинов - не просматривает файлы внутри вложенных папок. В этом случае, нужно будет создать загрузочный файл в каталоге my-plugin, чтобы он подключал файлы из подкаталогов, вот так:
// mu-plugins/load.php require WPMU_PLUGIN_DIR .'/my-plugin/my-plugin.php';
Когда может пригодится использовать mu плагины?
В случаях, когда это удобнее обычного плагина... Я, например, недавно поместил код в виде такого плагина, чтобы установить 301 редиректы со старых URL, когда изменял ЧПУ на уже давно рабочем сайте. Это показалось мне наилучшим решением, ведь:
- вставлять такой редирект в тему неправильно - вдруг тему изменят и все редиректы исчезнут.
- если установить как обычный плагин, то если случайно его отключить все редиректы пропадут, а этого можно не заметить.
Как это работает?
MU плагины загружаются раньше обычных. Давайте посмотрим схему загрузки WordPress. Тут упомяну интересную картинку (очень она мне понравилась):

Что касается кода, как конкретно подключаются файлы. Смотрите фрагмент кода отвечающий за MU плагины, из файла темы wp-settings.php:
// Загружаем MU плагины. foreach ( wp_get_mu_plugins() as $mu_plugin ) { include_once( $mu_plugin ); } unset( $mu_plugin );
Код функции wp_get_mu_plugins():
function wp_get_mu_plugins() { $mu_plugins = array(); if ( !is_dir( WPMU_PLUGIN_DIR ) ) return $mu_plugins; if ( ! $dh = opendir( WPMU_PLUGIN_DIR ) ) return $mu_plugins; while ( ( $plugin = readdir( $dh ) ) !== false ) { if ( substr( $plugin, -4 ) == '.php' ) $mu_plugins[] = WPMU_PLUGIN_DIR . '/' . $plugin; } closedir( $dh ); sort( $mu_plugins ); return $mu_plugins; }
Как мы видим, директория WPMU_PLUGIN_DIR проверяется на существование. Если она существует из неё собираются все .php файлы, сортируются по алфавиту (по возрастанию) и последовательно подключаются.
История появления 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 было нечто похожее: когда-то аббревиатура PHP означала "Personal Home Page", но затем была пере-интерпретирована как "PHP Hypertext Preprocessor" и, в духе хакерский традиций, превратилась в рекурсивный акроним.
Акро́ним — вид аббревиатуры. Представляет собой слово, являющееся сокращением, которое можно произнести слитно, в отличие от других видов аббревиатур, которые произносят «по буквам», например: КГБ — [ка-гэ-бэ].
Рекурсивный акроним — акроним, который ссылается на себя.
В среде компьютерных хакеров стало традиционным выбирать акронимы, которые косвенно или напрямую ссылаются на себя. Одним из самых ранних примеров является появившаяся в 1977 TINT: «TINT Is Not TECO» («TINT — это не TECO»).