Автооновлення плагіна поклало сайт за п'ять хвилин: розбір і запобіжники

О 18:06 WordPress на сайті, який ми обслуговуємо, сам оновив плагін. О 18:11 сайт перестав відкриватися. Ніхто нічого не натискав, ніхто не заходив в адмінку, не було ані зламу, ані збою хостингу. Система просто зробила те, для чого її налаштували роки тому, і зробила це бездоганно.

Цей розбір — про те, чому автоматичне оновлення, яке мало б захищати сайт, інколи його кладе, і що зробити, щоб у вас такого не сталося. Без теорії: усе нижче — хронологія одного вечора й одного наступного ранку.

Хронологія: п'ять хвилин від оновлення до мертвого сайту

18:06. WordPress запускає планове автооновлення плагіна Elementor — конструктора, на якому зібрані всі сторінки сайту. На сайті стояла версія 3.6.5, випущена ще 2022 року. Оновлення ставить одразу 4.3.5, перестрибнувши через кілька років змін.

18:11. Головна сторінка віддає помилку. Відвідувачі бачать білий екран замість сайту. Редактор в адмінці не може ні відкрити сторінку, ні зберегти її.

18:14. У робочу групу прилітає повідомлення: «не зберігається сторінка». Про те, що сайт лежить цілком, ще ніхто не знає.

19:25. Сайт працює. Між цими двома точками — година розбору, і саме вона цікава.

Чому це сталося: три причини, що зійшлися в одну

1. Версія плагіна з 2022 року

Автооновлення не оновлювало цей плагін чотири роки — а потім спрацювало. Чому саме цього вечора, неважливо: важливо, що стрибок із версії 3.6 на 4.3 — це не «латка», а зміна покоління. Розробник за цей час прибрав частину старого коду, який вважав застарілим. Це нормальна практика — але лише для тих, хто оновлюється регулярно й помічає попередження по дорозі.

2. Тема сайту спиралась на той самий старий код

Тема оформлення теж із 2022 року і теж не оновлювалась. У восьми її блоках використовувались функції, які в новому Elementor зникли. Тема викликає функцію — функції немає — PHP зупиняє виконання. Для відвідувача це виглядає як порожня сторінка з помилкою.

3. Сусідній плагін загубив налаштування

На сайті стояв ще один плагін, який приховує стандартні адреси WordPress від роботів і сканерів. Під час оновлення він загубив правило підміни адрес саме для файлів Elementor. Тож навіть там, де тема не ламалась, редактор не міг завантажити власні файли: сервер відповідав «не знайдено».

Автооновлення не знає, що ваша тема з 2022 року, що поруч стоїть плагін, який перехоплює адреси, і що на цьому сайті ніхто не оновлювався чотири роки. Воно знає лише одне: є нова версія, і її треба поставити.

Як лікували

• Повернули плагін на 3.6.5 — ту версію, що працювала вранці. Нову не видалили, а відклали: повернутись до неї можна за хвилину, коли тема буде готова.
• Відновили загублене правило у плагіні, що ховає адреси.
• Вимкнули автооновлення саме для Elementor. Інакше вночі все повторилося б — WordPress не пам'ятає, що минулого разу стало гірше.
• Перевірили головну й внутрішні сторінки — відкриваються, помилок немає, оформлення на місці.

І окремо сказали власнику чесно: версія 3.6.5 — чотирирічної давнини, тримати її довго не варто. У старих версіях з часом знаходять вразливості, і тоді вже не оновлюватись стає небезпечно. Найсвіжіша версія, сумісна з цією темою, — 3.25. Але й тема з 2022 року: рано чи пізно вона впреться у це знову. Правильний шлях — зробити копію сайту й там спокійно перевірити оновлення, без ризику для робочого.

Другий дзвіночок наступного ранку

О 9:49 нове повідомлення: «помилка 503» при збереженні сторінки. На перший погляд — продовження вчорашнього. Насправді — інша історія, і вона теж повчальна.

Сервер не відмовляв. Під час збереження падав сам процес PHP, а браузер показував це як 503. Сторінка виявилась дуже важкою: 226 блоків, із них 111 картинок. А обмеження PHP на сайті стояли найменші, з коробки хостингу: 128 МБ пам'яті й 30 секунд на запит. Конструктор для нормальної роботи вимагає щонайменше 256 МБ і 300 секунд. Сайт роками працював на межі — і на найважчій сторінці ця межа закінчилась.

Підняли ліміти, перезапустили PHP — не допомогло. Журнал показав: пам'ять і час тут ні до чого, процес гине на самому збереженні. Причиною виявилось одне з налаштувань прискорення PHP, відома проблема на цій версії. Вимкнули — запрацювало.

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

Що робити власнику сайту

1. Дізнайтеся, що у вас оновлюється саме. В адмінці WordPress: «Плагіни» → колонка «Автооновлення». Те саме для тем. Якщо ви не знаєте відповіді — це вже перша проблема.
2. Розділіть оновлення на «безпекові» і «великі». Дрібні виправлення всередині версії (3.25.10 → 3.25.11) можна лишити автоматичними. Перехід між великими версіями (3 → 4) — лише руками, і лише після перевірки.
3. Перевіряйте великі оновлення на копії. Хостинги зазвичай дають тестову копію сайту одним натисканням. Оновили там, подивились, що нічого не відвалилось, — тоді оновлюєте робочий.
4. Робіть копію перед кожним оновленням. Не «бекап є на хостингу», а копія, з якої ви особисто знаєте, як відновитись за десять хвилин.
5. Не тримайте версії чотирирічної давнини. Чим довше не оновлюєтесь, тим болючішим буде стрибок, і тим більше вразливостей накопичується. Планове оновлення раз на місяць дешевше за одну ніч без сайту.
6. Майте того, хто побачить за п'ять хвилин. Сайт лежав з 18:11, а повідомлення прийшло о 18:14 — і то не про сайт, а про редактор. Без моніторингу власник дізнається про мертвий сайт від клієнта, який не зміг замовити.

Парадокс: не оновлюватись — теж небезпечно

Може здатися, що висновок — «вимкніть автооновлення і живіть спокійно». Ні. Нещодавно ми писали про критичні вразливості PHP, де єдиний захист — саме оновлення, і відкладати його не можна. Там зволікання коштує зламаного сервера. Тут поспіх коштував вечора без сайту.

Різниця в одному: безпекові оновлення треба ставити швидко й усі, а функціональні — усвідомлено й після перевірки. Автооновлення цієї різниці не бачить. Її має бачити людина.

---

Не впевнені, що у вас оновлюється саме й що станеться після наступного оновлення? Напишіть нам — подивимось на ваш сайт і скажемо прямо, де він на межі.