WordPress 7.1 kunne ha ødelagt en nettside med Elementor: hvilken kombinasjon av plugins viste seg å være farlig

Оновлення WordPress зазвичай сприймається як стандартна технічна процедура: зробити резервну копію, натиснути «Оновити», перевірити сайт. Але реліз WordPress 7.1 показав, наскільки крихкою може бути ця логіка на реальному сайті, де одночасно працюють конструктор сторінок, кешування, форми, сторонні модулі та PHP 8.

Після виходу WordPress 7.1 частина сайтів із WP Rocket почала отримувати критичну PHP-помилку. У деяких випадках переставав відкриватися тільки frontend, в інших власник втрачав доступ навіть до /wp-admin.

Особливо неприємною ситуація виявилася для сайтів на Elementor, адже одна з підтверджених конфігурацій включала саме Elementor Pro.

Проте причина була складнішою за простий конфлікт «WordPress проти Elementor».

Щоб сайт упав, мало зійтися відразу кілька умов:

WordPress 7.1 + PHP 8.x + WP Rocket + плагін або модуль, який реєстрував callback певним способом.

Серед підтверджених тригерів WP Rocket назвав:

Elementor Pro;
безкоштовний Elementor з активованим експериментальним Atomic Elements;
Redirection for Contact Form 7.

Сам Elementor при цьому не був «винним» у класичному розумінні. Він лише створював умову, за якої помилка в іншому компоненті ставала видимою.

Що сталося після виходу WordPress 7.1

WordPress 7.1 «Mary Lou» офіційно вийшов 19 серпня 2026 року. Реліз містив велику кількість змін у Core та редакторі, включно зі змінами, важливими для розробників плагінів.

Практично відразу після початку оновлень користувачі WP Rocket почали повідомляти про критичні помилки.

Симптом виглядав приблизно так:

There has been a critical error on this website.

У PHP error log з’являвся TypeError, пов’язаний із файлом:

wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php

і функцією substr().

Типова помилка:

substr(): Argument #1 ($string) må være av typen string, int er angitt

WP Rocket підтвердив проблему та випустив виправлення у версії 3.23.2.2.

Чому звичайна PHP-помилка могла покласти весь сайт

Щоб зрозуміти масштаб проблеми, потрібно трохи заглянути всередину WordPress.

Плагіни WordPress взаємодіють із ядром і між собою через систему hooks:

actions;
filters.

Коли плагін підключає певну функцію до hook, WordPress створює для цього callback внутрішній ідентифікатор.

До WordPress 7.1 WP Rocket фактично міг розраховувати, що ідентифікатор, який він аналізує в цьому сценарії, буде рядком.

У WordPress 7.1 механізм формування ID для частини callback змінився. Для callback на основі об’єктів, closures або __invoke() у певних випадках ID міг перетворюватися на числове значення.

Далі спрацьовувала ще одна особливість PHP.

Якщо рядок виглядає як звичайне ціле число і використовується як ключ масиву, PHP може автоматично перетворити його на integer.

У результаті замість умовного:

"5292"

код міг отримати:

5292

Для людини різниця майже непомітна.

Для PHP 8 — принципова.

У коді WP Rocket цей ключ передавався у функцію substr(), яка очікувала рядок.

WP Rocket фактично робив операцію на кшталт:

substr( $key, ... )

але $key у певних конфігураціях вже був не string, а integer.

PHP 8 у такій ситуації кидав TypeError.

І оскільки цей код запускався під час ініціалізації WordPress, помилка могла зупинити виконання всього запиту.

Результат:

HTTP 500 або WordPress Critical Error ще до того, як сайт встиг нормально завантажитися.

Саме зміну типу callback ID WordPress Core окремо зафіксував у ticket #65919 як backward-compatibility проблему та прив’язав її до milestone WordPress 7.1.1.

До чого тут WP Rocket

Джерело фатальної помилки знаходилося в модулі WP Rocket, пов’язаному з Cloudflare.

І тут є важлива деталь.

Для виникнення проблеми не обов’язково було використовувати Cloudflare.

WP Rocket визнав, що відповідний Cloudflare-модуль міг виконуватися навіть на сайтах, де плагін Cloudflare взагалі не був активований.

Цей модуль аналізував callback на певних WordPress hooks і намагався знайти серед них функції, пов’язані з очищенням кешу Cloudflare.

У проблемному коді WP Rocket передавав callback ID без додаткової перевірки типу в substr().

Після зміни WordPress 7.1 це припущення перестало бути безпечним.

Тому в ситуації були фактично дві окремі технічні проблеми.

З боку WordPress відбулася зміна поведінки внутрішніх callback ID, яка могла порушити backward compatibility.

З боку WP Rocket код припускав, що отримане значення завжди буде string, і не перевіряв тип перед використанням substr().

Сам WP Rocket у своєму post-mortem прямо визнав свою частину відповідальності та окремо зазначив, що реагувати на ранні повідомлення про проблему потрібно було швидше.

Де з’являється Elementor

Один лише Elementor не спричиняв цю помилку.

Потрібен був callback, зареєстрований певним способом на hook, який аналізував WP Rocket.

WP Rocket перевірив повідомлення користувачів, GitHub та близько 200 популярних WordPress-плагінів і назвав три підтверджені сценарії.

1. Elementor Pro

За даними WP Rocket, Elementor Pro міг створити необхідну умову після активації плагіна з чинною ліцензією.

Один із публічних GitHub-звітів зв’язав конкретний callback із модулем Elementor Pro Notes.

Тобто Elementor Pro реєстрував callback, WordPress 7.1 створював для нього numeric ID, PHP перетворював його на integer, а WP Rocket передавав цей integer у substr().

Сам Elementor Pro при цьому не виконував некоректної операції. Він лише активував той сценарій, у якому слабке місце WP Rocket ставало критичним.

2. Elementor Free + Atomic Elements

Для безкоштовного Elementor ситуація була іншою.

Звичайна установка Elementor Free не означала автоматично наявність проблеми.

WP Rocket вказує, що підтвердженим тригером був Elementor Free із увімкненим експериментальним параметром:

e_atomic_elements

Тобто ризик стосувався сайтів, де використовувалися експериментальні Atomic Elements.

3. Redirection for Contact Form 7

Третім підтвердженим тригером став плагін Redirection for Contact Form 7.

У цьому випадку достатньо було його активації разом із рештою проблемної конфігурації.

І саме цей приклад добре показує, чому ситуація була небезпечною для звичайних комерційних WordPress-сайтів.

Contact Form 7, Elementor і WP Rocket часто використовуються разом на:

лендингах;
корпоративних сайтах;
сайтах експертів;
онлайн-школах;
сайтах послуг;
невеликих WooCommerce-проєктах.

Тому технічно досить специфічна помилка могла зачепити дуже поширені реальні конфігурації.

Небезпечна комбінація

У спрощеному вигляді проблема виглядала так:

Компонент	Умова
WordPress	7.1
PHP	8.x
Кешування	WP Rocket
Додатковий тригер	Elementor Pro
Або	Elementor Free + Atomic Elements
Або	Redirection for Contact Form 7

Але навіть ця таблиця не означає, що кожен сайт із такою конфігурацією обов’язково мав упасти.

Мали значення:

активні модулі;
порядок реєстрації hooks;
конкретні callback;
версії плагінів;
момент виконання коду.

Саме тому однакове оновлення на двох зовні схожих сайтах могло пройти абсолютно по-різному.

Наскільки масштабною була проблема

За власною оцінкою WP Rocket, приблизно 27% сайтів його клієнтів потенційно мали конфігурацію, яка потрапляла в зону ризику.

Фактично проблема, за їхньою оцінкою, проявилася приблизно на 10% сайтів.

Для конфлікту, який потребував настільки конкретної комбінації умов, це дуже високий показник.

Водночас ці цифри потрібно трактувати правильно.

Це не означає, що:

10% усіх WordPress-сайтів перестали працювати;
27% сайтів з Elementor були в небезпеці;
Elementor Pro сам по собі був несумісний із WordPress 7.1.

Йдеться саме про оцінку WP Rocket щодо його клієнтської бази.

Проблему помітили ще до фінального релізу WordPress 7.1

Ця частина історії особливо показова.

Перший GitHub issue про проблему був відкритий ще 6 липня 2026 року, коли тестувався WordPress 7.1 alpha.

Автор уже тоді:

правильно визначив проблему;
вказав на integer callback key;
пояснив зв’язок із PHP 8;
запропонував фактично той самий тип виправлення, який згодом знадобився WP Rocket.

Однак автоматичні тести WP Rocket проблему не відтворили.

Після виходу WordPress 7.1 Beta 1 15 липня тестування WP Rocket також пройшло успішно, тому плагін був позначений як сумісний із WordPress 7.1.

Причина стала зрозумілою вже після масових повідомлень користувачів.

У тестовому наборі WP Rocket були:

Query Monitor;
Imagify;
WPML;
Divi;
Avada;
Astra;
Hello Elementor;
WooCommerce Storefront;
GeneratePress;
Kadence;
Neve та інші.

Але Elementor Pro у відповідному compatibility test suite не було.

Тому звичайний тест із Hello Elementor не міг відтворити сценарій, який з’являвся саме через Pro-модуль.

Чому «плагін сумісний із WordPress 7.1» ще нічого не гарантує

Цей випадок дає дуже практичний урок власникам WordPress-сайтів.

Ми часто бачимо:

Compatible with WordPress 7.1.

І сприймаємо це як гарантію.

Насправді тест сумісності здебільшого означає:

цей конкретний плагін був протестований із цією версією WordPress у певному наборі конфігурацій.

Він не гарантує перевірку всіх можливих комбінацій:

WordPress + PHP + тема + Elementor + Elementor Pro + WP Rocket + WooCommerce + CF7 + add-ons + custom code + hosting stack.

WordPress має відкриту plugin architecture, тому кількість потенційних конфігурацій практично необмежена.

Кожен компонент окремо може бути коректним.

Проблема з’являється в точці їхньої взаємодії.

Чому PHP 8 став важливою частиною цієї історії

На старіших версіях PHP частина подібних ситуацій могла пройти непомітно завдяки автоматичному приведенню типів.

PHP 8 значно суворіший.

Якщо функція очікує:

string

а отримує:

int

в окремих сценаріях PHP більше не намагається «вгадати», що мав на увазі розробник.

Він зупиняє виконання з TypeError.

З погляду якості коду це позитивна зміна: помилки типів стають видимими.

Але на production-сайті результат може виглядати жорстко:

один неправильний тип даних → fatal error → весь WordPress не завантажується.

Чому могла зникнути навіть адмінпанель

Це ще одна причина, чому інцидент був серйозним.

Помилка виникала під час WordPress init.

Тобто ще до нормального формування сторінки.

Через це могли перестати працювати одночасно:

головна сторінка;
посадкові сторінки;
блог;
/wp-admin;
AJAX-запити;
інколи навіть WP-CLI bootstrap.

Користувач не міг просто зайти в Plugins і натиснути Deactivate.

Потрібен був доступ до:

File Manager хостингу;
FTP/SFTP;
SSH.

Саме тому власнику WordPress-сайту варто мати доступ не тільки до адмінпанелі WordPress, а й безпосередньо до хостингу.

Що робити зараз, якщо на сайті стоять WordPress 7.1, Elementor і WP Rocket

Перше — перевірити версію WP Rocket.

Проблема виправлена у:

WP Rocket 3.23.2.2

та новіших версіях.

WP Rocket офіційно рекомендує оновити плагін щонайменше до цієї версії.

Якщо сайт зараз працює нормально, але використовується стара версія WP Rocket, відкладати оновлення немає сенсу.

Правильний порядок для сайту, який ще не оновлювався до WordPress 7.1

Якщо сайт досі працює на WordPress 7.0.x і використовує WP Rocket, я б рекомендувала такий порядок:

1. Створити повну резервну копію.

Не тільки бази даних.

Du trenger:

база;
wp-content;
uploads;
plugins;
themes;
wp-config.php;
за можливості повний server backup або snapshot.

2. Оновити WP Rocket.

Переконайтеся, що використовується 3.23.2.2 або новіша версія.

3. Оновити Elementor та Elementor Pro.

4. Перевірити інші критичні плагіни.

Особливо:

WooCommerce;
LMS;
payment gateways;
Contact Form 7;
CF7 add-ons;
security plugins;
cache/performance plugins.

5. Тільки після цього оновлювати WordPress Core.

Для важливого комерційного сайту — спочатку на staging.

Що робити, якщо після оновлення сайт уже впав

Якщо бачите Critical Error і не можете зайти в /wp-admin, офіційний workaround WP Rocket починається з ручної деактивації WP Rocket.

Через File Manager або FTP знайдіть:

/wp-content/plugins/wp-rocket/

і тимчасово перейменуйте папку, наприклад на:

wp-rocket-off

WordPress перестане бачити плагін як активний, і в багатьох випадках сайт знову почне завантажуватися.

Після цього:

зайдіть у /wp-admin;
переконайтеся, що WP Rocket деактивований;
поверніть папці правильну назву wp-rocket;
оновіть WP Rocket до 3.23.2.2 або новішої версії;
активуйте його;
очистіть усі рівні кешу;
перевірте frontend і backend.

Як зрозуміти, що ви зіткнулися саме з цією помилкою

Подивіться PHP error log.

Характерний запис містить:

Cloudflare.php

line 562

та повідомлення:

substr(): Argument #1 ($string) må være av typen string, int er angitt

Саме такі error logs WP Rocket наводить у своїй офіційній документації.

Якщо лог містить іншу помилку, не варто автоматично вважати, що причина та сама.

Critical Error у WordPress може виникнути через:

нестачу memory_limit;
несумісну версію PHP;
інший плагін;
тему;
custom code;
пошкоджені файли;
помилку Composer autoload;
кеш;
PHP extension.

Спочатку потрібно визначити конкретний stack trace.

Чи потрібно вимикати Elementor Pro

Після встановлення актуальної версії WP Rocket — ні.

WP Rocket прямо наголошує, що Elementor Pro, Atomic Elements та Redirection for Contact Form 7 не робили нічого неправильного.

Вони лише реєстрували callback способом, який запускав проблемний код.

Тому лікувати ситуацію постійним видаленням Elementor Pro нелогічно.

Виправлення має бути там, де виникала помилка.

І WP Rocket його вже випустив.

А що з WordPress 7.1.1

WordPress Core також визнав зміну callback ID як backward-compatibility проблему.

Ticket #65919 отримав milestone 7.1.1.

Станом на кінець серпня WordPress 7.1.1 планується як maintenance release, орієнтовне вікно релізу Core називав між 1 та 24 вересня 2026 року, залежно від кількості й серйозності знайдених багів.

Але чекати лише WordPress 7.1.1, якщо на сайті встановлений старий WP Rocket, я б не рекомендувала.

WP Rocket уже має власне виправлення.

Чому auto-update Core на комерційному сайті варто використовувати обережно

У цієї історії є ще один практичний висновок.

Автоматичні оновлення Core корисні з погляду безпеки.

Особливо для security releases.

Але major update на складному комерційному WordPress-сайті може змінити:

API;
hooks;
editor behavior;
PHP interaction;
JS dependencies;
block editor;
database behavior.

Тому для сайту з:

Elementor;
Elementor Pro;
WooCommerce;
LMS;
payment gateway;
WP Rocket;
custom snippets;
CRM;
зовнішніми інтеграціями

я б розділяла security updates і major feature updates.

Для major release на кшталт 7.1 безпечніший сценарій:

backup → staging → update → functional test → production.

Що потрібно тестувати після великого WordPress update

Недостатньо відкрити головну сторінку й сказати: «Все працює».

Після major update потрібно перевірити щонайменше:

Frontend

головну;
ключові landing pages;
блог;
мобільну версію;
меню;
popup;
cookie banner.

Elementor

Elementor Editor;
Elementor Pro widgets;
templates;
header/footer;
popup builder;
forms;
dynamic content.

Форми

Відправити реальний тест.

Перевірити:

валідацію;
e-post;
redirect;
CRM;
webhook;
Telegram;
autoresponder.

WooCommerce

Якщо використовується:

кошик;
checkout;
shipping;
taxes;
coupons;
payment gateway;
order email.

LMS

Для онлайн-школи:

login;
registration;
lessons;
video;
progress;
quizzes;
purchase;
access rules.

Кешування

Перевірити:

page cache;
mobile cache;
preload;
minification;
delay/defer JavaScript;
CDN;
Redis/object cache.

Адмінпанель

Перевірити:

редагування сторінки;
медіабібліотеку;
створення запису;
plugins;
scheduled actions;
cron.

Найважливіший урок: тестувати потрібно не плагіни, а стек

Ця історія добре показує одну з головних особливостей WordPress.

Сайт — це система.

На ньому може стояти:

WordPress
↓
PHP
↓
тема
↓
Elementor
↓
Elementor Pro
↓
WP Rocket
↓
WooCommerce
↓
Contact Form 7
↓
CF7 add-ons
↓
security plugin
↓
custom code
↓
hosting cache
↓
CDN

Кожен компонент окремо може бути повністю робочим.

А збій виникає між третім, п’ятим і сьомим компонентом.

Саме тому фраза:

«Я оновила плагін, у нього хороші відгуки, тому все має працювати»

не є технічною гарантією.

Окремий урок для власників лендингів та онлайн-шкіл

Саме такі сайти часто мають найбільшу кількість інтеграцій.

Типова конфігурація може виглядати так:

Elementor Pro — дизайн і форми;
WP Rocket — швидкість;
WooCommerce — оплата;
LMS — доступ до курсів;
Contact Form 7 — додаткові форми;
SMTP — доставка листів;
security plugin — firewall;
reCAPTCHA — захист;
Telegram/CRM integration;
custom snippets.

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

Тому технічне обслуговування WordPress — це вже не натискання кнопки Update.

Це контроль залежностей.

Чек-лист перед наступним великим оновленням WordPress

Перед major update я рекомендую пройти короткий список:

□ Є свіжа повна резервна копія.

□ Я знаю, як відновити її, а не тільки де вона лежить.

□ Є доступ до хостингу або SFTP.

□ PHP error log доступний.

□ Плагіни оновлені до актуальних стабільних версій.

□ Elementor Pro має актуальну версію.

□ Кешуючий плагін оновлений.

□ Я перевірила compatibility notes критичних плагінів.

□ Для комерційного сайту є staging.

□ Після оновлення я тестую форми, checkout, login та інші бізнес-функції.

Якщо на п’ять пунктів із десяти відповідь «не знаю», major update краще не запускати автоматично.

Konklusjon

Історія WordPress 7.1, WP Rocket та Elementor — хороший приклад того, як насправді виникають серйозні WordPress-збої.

Причиною не був один «поганий плагін».

Зійшлося кілька факторів:

WordPress 7.1 змінив поведінку callback ID → певний плагін зареєстрував callback потрібного типу → PHP перетворив numeric key на integer → WP Rocket очікував string → PHP 8 зупинив виконання fatal TypeError.

Elementor Pro виявився одним із найпоширеніших тригерів, тому проблема стала особливо помітною.

WP Rocket випустив виправлення у 3.23.2.2, а відповідну backward-compatibility проблему WordPress Core планує адресувати в гілці 7.1.1.

Головний практичний висновок значно ширший за цей конкретний баг.

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

Особливо якщо сайт приносить заявки, продає товари, приймає оплату або забезпечує доступ до онлайн-курсів.

У такому випадку staging, резервна копія, error logs і контрольоване оновлення коштують набагато дешевше, ніж кілька годин повністю недоступного сайту.