Как отключить автоматические обновления одного плагина WordPress

Когда стоит отложить автоматическое обновление плагина

Выборочная блокировка должна быть временным исключением, а не постоянной стратегией обслуживания сайта. Её уместно использовать, если после обновления необходимо проверить совместимость с платёжным шлюзом, CRM, темой или собственным кодом.

Отдельный случай — плагин с локальными изменениями. Если команда поддержки внесла патч непосредственно в файлы расширения, автоматическое обновление может его перезаписать. Однако более правильным долгосрочным решением будет вынести изменения в отдельный плагин, дочернюю интеграцию или поддерживаемый форк.

Не откладывайте обновления без контроля. После выхода новой версии проверьте журнал изменений, совместимость и наличие исправлений безопасности, а затем обновите плагин вручную после создания резервной копии или тестирования в staging-среде.

• критически важная интеграция ещё не проверена с новой версией;
• плагин содержит локальные изменения или пользовательский патч;
• обновление временно несовместимо с версией PHP, темой или другим расширением.

Почему не следует отключать обновления для всего WordPress

Глобальная блокировка изменений файлов отключает не только автоматические обновления одного плагина. Она может помешать обновлению других плагинов, тем и компонентов ядра, а также усложнить штатное обслуживание сайта.

В результате сайт дольше остаётся уязвимым к известным угрозам, хотя проблема касается только одного расширения. Фильтр auto_update_plugin работает точнее: для нужного плагина он возвращает false, а для всех остальных сохраняет стандартное решение WordPress.

Этот механизм влияет только на автоматические обновления. Он не запрещает администратору обновить плагин вручную через панель управления WordPress или WP-CLI.

• не используйте DISALLOW_FILE_MODS только для блокировки одного плагина;
• не отключайте все автоматические обновления без процесса регулярной ручной проверки;
• фиксируйте причину исключения и назначайте ответственного за его пересмотр.

Как определить идентификатор нужного плагина

Фильтр сравнивает значение $item->plugin с внутренним идентификатором плагина. Это не всегда название, которое отображается в панели администратора. Обычно значение имеет формат directory/file.php, например vendor/plugin.php.

Первую часть можно определить по названию каталога в wp-content/plugins, а вторую — по главному PHP-файлу плагина. Для надёжной проверки изучите заголовок плагина в этом файле или воспользуйтесь WP-CLI.

Если указать только название плагина, slug каталога или неправильный файл, условие не сработает. Перед добавлением правила желательно зафиксировать фактический путь в документации проекта.

• пример правильного значения: vendor/plugin.php;
• у плагина без отдельной вложенной папки может быть другой формат;
• идентификатор нужно брать из фактической структуры установленного плагина, а не угадывать.

Пошаговая настройка через mu-plugin

Mu-plugin, или must-use plugin, автоматически загружается WordPress независимо от активной темы. Такое расположение удобно для технических правил, которые не должны исчезнуть после смены темы или случайного отключения обычного плагина.

Создайте каталог wp-content/mu-plugins, если его ещё нет. Затем добавьте файл, например disable-plugin-auto-update.php, и вставьте приведённое ниже правило. Вместо vendor/plugin.php укажите фактический идентификатор нужного плагина.

• убедитесь, что файл имеет расширение .php, а не .php.txt;
• не добавляйте лишние пробелы или текст перед открывающим PHP-тегом;
• выполняйте изменение через контролируемый доступ к файлам или систему развёртывания.

<?php
add_filter('auto_update_plugin', function ($update, $item) {
    if (
        isset($item->plugin) &&
        $item->plugin === 'vendor/plugin.php'
    ) {
        return false;
    }

    return $update;
}, 10, 2);

Как проверить работу правила

После создания mu-plugin проверьте сайт в тестовой среде или в панели администратора. В списке плагинов у расширения может по-прежнему отображаться уведомление о новой версии — это нормально. Правило не скрывает обновление, а лишь не позволяет установить его автоматически.

Для дополнительной проверки изучите журналы процесса обновления или запустите тестовую проверку через WP-CLI. Ручное обновление конкретного плагина командой wp plugin update остаётся доступным и помогает убедиться, что блокировка не распространилась на все способы обновления.

Если автоматическое обновление всё же произошло, проверьте три вещи: фактический путь к главному файлу, расположение mu-plugin и синтаксис PHP. Также убедитесь, что файл загружается именно из wp-content/mu-plugins, а не из обычного каталога plugins.

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

Типичные ошибки и правила безопасности

Самая распространённая ошибка — блокировка по названию, которое не совпадает с $item->plugin. Другая проблема — добавление кода в functions.php активной темы. После смены темы такой код исчезнет или перестанет работать, поэтому для системного правила лучше использовать mu-plugin.

Не считайте отложенное обновление окончательным решением. Ведите список исключений с датой создания, причиной и запланированной датой пересмотра. Если плагин получил релиз с исправлением безопасности, оцените риск дальнейшей задержки и обновите его после проверки.

Доступ к файлу mu-plugin должен быть ограничен так же, как доступ к другим файлам WordPress. Изменения желательно хранить в системе контроля версий или хотя бы в журнале развёртываний, чтобы команда понимала, почему конкретный плагин не обновляется автоматически.

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