Обязательные плагины в WordPress (MU-плагины)

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

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

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

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

Содержание

• Изменение директории MU-плагинов
• Плюсы и минусы
• Когда полезно использовать mu-плагины?
• Как это работает?
• История MU-плагинов

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

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

Плюсы и минусы

Преимущества обязательных плагинов

• Всегда активны: нет необходимости активировать их в панели администратора. Пользователи не могут отключить их случайно или намеренно.

• Простота подключения: нужно просто добавить файл плагина в директорию wp-content/mu-plugins.

• Загружаются на раннем этапе: mu-плагины загружаются раньше обычных плагинов. Файлы подключаются в алфавитном порядке.

Недостатки обязательных плагинов

• Нет проверки обновлений: для mu-плагинов не будет уведомлений о новых версиях. Необходимо самостоятельно следить за обновлениями.

• Не работают хуки: функции для активации и деактивации плагинов не работают. При активации вам придется вручную добавлять таблицы или настройки в базу данных, а при деактивации – удалять все, что связано с плагином.

• Поиск файлов: WordPress ищет PHP-файлы в директории плагина иначе, чем в обычных плагинах – он не проверяет внутренние папки. Вам нужно создать файл-загрузчик в директории вашего плагина, чтобы подключить файлы из поддиректорий. Например:

// mu-plugins/load.php
require WPMU_PLUGIN_DIR .'/my-plugin/my-plugin.php';

Когда полезно использовать mu-плагины?

Mu-плагины полезны в случаях, когда это удобнее, чем использование обычных плагинов. Например, недавно я добавил код в форме mu-плагина для настройки 301 редиректов с устаревших URL, когда менял структуру URL на старом сайте. Это оказалось лучшим решением, потому что:

• Вставлять такой редирект в тему неверно – что если тему заменят, и все редиректы исчезнут?

• Если установить как обычный плагин, случайное его отключение приведет к исчезновению всех редиректов. Можете этого и не заметить.

Как это работает?

Mu-плагины загружаются раньше обычных плагинов. Рассмотрим схему загрузки WordPress. Вот интересная схема, которую я нашел:

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

// Загружаем обязательные плагины.
foreach ( wp_get_mu_plugins() as $mu_plugin ) {
    include_once $mu_plugin;

    /**
     * Срабатывает один раз после загрузки обязательного плагина.
     *
     * @since 5.1.0
     *
     * @param string $mu_plugin Полный путь к главному файлу плагина.
     */
    do_action( 'mu_plugin_loaded', $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 файлы, они сортируются по алфавиту и подключаются один за другим.

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

Директория "mu-plugins" изначально была создана для WPMU (мультипользовательской сети) плагинов, чтобы администраторы могли активировать плагины для всей сети сайтов или блогов. В то время это было важно, поскольку администраторы не могли активировать плагины для всей сети через панель управления. С версии 2.8 это стало возможным.

Код, отвечающий за работу много-пользовательск��х плагинов (mu-плагины), был перенесен в основной код WordPress. И вскоре после этого код WPMU был объединен с основным кодом WordPress, что сделало возможным автоматическую загрузку плагинов на всех сайтах, независимо от их сборки.

В результате изменения название "mu-plugins" утратило свою актуальность, так как теперь mu-плагины работали и для обычных установок. Несмотря на это, название решили оставить, переосмыслив его как "Must-use plugins" (обязательные плагины). Это плагины, которые должны всегда использоваться, они работают для всех сайтов и не зависят от настроек в админке.

Аналогично, PHP изначально означало "Personal Home Page", но затем было переосмыслено как "PHP Hypertext Preprocessor".

Теперь стало традицией выбирать акронимы, которые косвенно или прямо ссылаются на себя. Один из первых примеров – TINT, появившийся в 1977 году: "TINT Is Not TECO".