Як вибірково вимкнути автооновлення одного плагіна WordPress

Коли варто відкладати автооновлення плагіна

Вибіркове блокування має бути тимчасовим винятком, а не постійною стратегією обслуговування сайту. Його доречно використовувати, якщо після оновлення потрібно перевірити сумісність із платіжним шлюзом, CRM, темою або власним кодом.

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

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

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

Чому не слід вимикати оновлення для всього WordPress

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

У результаті сайт довше залишається з відомими вразливостями, хоча проблема стосується лише одного розширення. Фільтр auto_update_plugin працює точніше: для потрібного плагіна він повертає false, а для всіх інших зберігає стандартне рішення 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.

Не вважайте відкладене оновлення завершеним рішенням. Ведіть перелік винятків із датою створення, причиною та запланованою датою перегляду. Якщо плагін отримав security-реліз, оцініть ризик подальшої затримки й оновіть його після перевірки.

Доступ до файлу mu-plugin має бути обмежений так само, як і доступ до інших файлів WordPress. Зміни бажано зберігати в системі контролю версій або хоча б у журналі розгортань, щоб команда розуміла, чому конкретний плагін не оновлюється автоматично.

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