WordPress как на ладони
wordpress jino

Must-Use plugins или обязательные плагины в WordPress

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

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

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

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

Изменение каталога MU плагинов

Каталог Обязательных плагинов можно изменить. Для этого нужно определить константы: 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 плагины?». Ответ: «В случаях, когда это удобнее обычного плагина...» Я, например, недавно поместил код в виде такого плагина, чтобы установить 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»).

Must-Use plugins или обязательные плагины в WordPress 9 комментариев
  • Андрей

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

    Ответить3.7 года назад #
    • Kama4485

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

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

    1
    Ответить3 года назад #
  • karskiy3 cайт: karskiy.com

    Тимур, здравствуйте. Я тоже сравнительно недавно стал использовать эту возможность. Лично для меня удобно помещать туда (mu-plugins) функции связанные с настройкой админки под клиента, изменением ее функционала.

    1
    Ответить3 года назад #
  • Отличная штука , спасибо

  • petrozavodsky675 cайт: alkoweb.ru

    Опечатку нашел сортируются плфавиту

  • Otshelnik-Fm179 cайт: across-ocean.otshelnik-fm.ru

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

    4

Здравствуйте, !

Ваш комментарий