Главная Новости

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

Опубликовано: 01.09.2018

видео Комментарии 1 — Must-Use plugins или обязательные плагины в WordPress

Super Socializer Review

Знаком с 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

Что касается кода, как конкретно подключаются файлы. Смотрите фрагмент кода отвечающий за 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»).

3D стерео фильмы для 5D
rss