WordPress как на ладони
Недорогой хостинг для сайтов на WordPress: wordpress.jino.ru Новые WordPress шаблоны

Must-Use плагины в WordPress

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

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

mu-plugins отображаются в верхней информационной строке в админ-панели.

Их невозможно отключить через админку. Для отключения нужно удалить файл плагина из упомянутого каталога wp-content/mu-plugins.

WordPress автоматически подключает все файлы из папки mu-plugins, но не проверяет вложенные папки, где могут быть и другие php файлы. Поэтому такие плагины не могут находится в папках - это должен быть файл в папке wp-content/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. Тут упомяну интересную картинку (очень она мне понравилась):

Порядок загрузки ядра WordPress
Схема загрузки 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»).

6 комментов
  • Андрей

    smile извиняюсь, ничего не понял с самого начала статьи. О каких всё же плагинах идёт речь, у меня вообще нет папки "mu-plugins" в каталоге wp-... Где на сервере смотреть путь - wp-content/mu-plugins ?

    Ответить4.9 года назад #
    • Kama7021

      Можно создать такую папку в wp-content, затем создать в ней файл php и он автоматически будет выполняться - суть статьи в двух словах.

      1
      Ответить4.9 года назад #
  • А что, очень классная вещь! Я как-то и не обращал внимания раньше на эту статью, теперь есть новые возможности crazy

    1
    Ответить4.2 года назад #
  • kolshix452 cайт: paxtoy.com

    Отличная штука , спасибо

    Ответить1.9 год назад #
  • Otshelnik-Fm197 cайт: otshelnik-fm.ru

    Я написал подобный mu-плагин. "Otshelnik-Fm Kint" - php дебаг для админа, на основе удобной библиотеки Kint. Отдаю на гитхабе под MIT-лицензией: https://github.com/Otshelnik-Fm/otshelnik-fm-kint
    Сам использую на своем рабочем dev-сервере.

    4
    Ответить1.6 год назад #
  • @ Николай

    Возможно ли создать плагин, который требует mu-plugin и подтягивает его за собой как зависимость. К примеру если mu-plugin используется как вспомогательный класс - класс утилит или декоратор в нескольких моих плагинах?

    Ответить4 месяца назад #
Здравствуйте, !     Войти . Зарегистрироваться