WordPress 7.0: що ламається, що варто вмикати й коли оновлюватися
WordPress 7.0 «Armstrong» вийшов 20 травня 2026 року, і це перший за багато років реліз, для якого чесна порада власнику бізнесу звучить не як «оновлюйтеся швидше». Не тому, що він поганий, а тому, що він змінює адміністративні екрани, які плагіни розширювали пʼятнадцять років, — і не всі плагіни встигли.
За три місяці картина стала чіткішою, ніж на старті. Нижче — що саме змінилося, що ламається і в кого, що варто вмикати й як вирішити, коли має оновлюватися саме ваш сайт.
Що змінилося, за вагомістю
У релізі 7.0 домінують три зміни й піднята вимога.
- DataViews замінює класичні таблиці списків у «Записах», «Сторінках» і «Медіа». Це екрани на React, які фільтрують і сортують без перезавантаження сторінки. Кастомні типи записів у 7.0 не зачеплені й досі використовують старі таблиці — тому багато сайтів бачать зміну в одному місці й не бачать в іншому.
- Основа для ІІ в ядрі: AI Client, Abilities API і конектори з підтримкою моделей OpenAI, Anthropic і Google плюс адаптер MCP. Ядро постачає інфраструктуру, а не функцію, на яку можна показати пальцем; корисні застосування прийдуть від плагінів, побудованих на ній.
- Покращення редактора й дизайну, включно з новими блоками й переробленою командною палітрою.
- Мінімальна версія PHP тепер 7.4, підтримка 7.2 і 7.3 припинена, а для всього, що використовує ІІ-функції, рекомендується 8.3.
Одне помітне вилучення: спільне редагування в реальному часі прибрали з релізу на початку травня через проблеми з конкурентним доступом і стабільністю. Якщо на нього спирався якийсь план, цьому плану потрібна нова дата.
Що насправді ламається
Майже всі повідомлення про поломки зводяться до однієї зміни: адміністративних екранів, які розширювали плагіни, більше немає в тій формі, якої ці плагіни очікують.
| Що було | Що відбувається в 7.0 | Наскільки помітно |
|---|---|---|
| Кастомні колонки в списку записів | Часто зникають; старі хуки колонок не повністю інтегровані з DataViews | Одразу, для редакторів |
| Кастомні масові дії | Можуть зникнути з нових екранів | Коли хтось спробує ними скористатися |
| Доробки швидкого редагування | Часто втрачаються | Під час звичайної роботи |
| Налаштування «Параметри екрана» | Не застосовуються до нового інтерфейсу | Незначно, косметично |
| Адмінський CSS під стару розмітку | Візуальні поломки: DOM інший | Одразу, і виглядає як зламане |
| Плагіни-теми для адмінки | Часткова стилізація, змішаний вигляд | Одразу |
| Сайти на PHP 7.2 або 7.3 | Оновитися неможливо, доки хостинг не переведе вас | Блокує |
Зверніть увагу, кого це зачіпає: страждають редакційні команди й усі, чий процес спирається на кастомні колонки — залишок на складі, статус, імʼя клієнта в списку. Публічні сторінки не зачеплені. Сайт-візитівка з кількома плагінами не помітить майже нічого; сайт, де адмінка є робочим інструментом, помітить у перший же день.
Різниця, яка визначає ваш ризик: 7.0 змінює адміністративний інтерфейс, а не фронтенд. Якщо цінність сайту в тому, що бачать відвідувачі, оновлення низькоризикове й може відбутися після звичайного тестування. Якщо цінність включає людей, які щодня працюють в адмінці — магазин, редакція, система запису, — сприймайте це як зміну робочого процесу, що потребує репетиції, а не як рутинний патч.
Чи варто вмикати ІІ-функції?
Здебільшого ще ні, і аргументація тут важливіша за відповідь.
Постачено інфраструктуру: стандартний спосіб для плагінів звертатися до моделі, описувати можливості й підключатися до провайдера. Це справді цінно, бо замінює десяток несумісних інтеграцій в окремих плагінах одним механізмом. Але саме ядро не робить із цим нічого, що бізнес помітив би, а підключення провайдера означає додати до сайту API-ключ, витратну експозицію й питання про потоки даних.
Три питання до вмикання будь-чого з цього. Який провайдер отримує контент і чи прийнятно це для конкретного матеріалу? Хто тримає API-ключ і який ліміт витрат? І що саме робить плагін, який це використовує, чого людина вже не робила краще? Це ті самі управлінські питання, місце яким у письмовій політиці, а не в екрані налаштувань, — вони викладені в матеріалі про ІІ-регламенти, які варто написати зараз.
Захищена позиція для більшості бізнесів у 2026 році: оновитися до 7.0 за його власними перевагами, залишити ІІ-конектори неналаштованими й повернутися до цього, коли конкретний плагін розвʼязуватиме вашу конкретну проблему.
Що це означає для сайтів на конструкторах сторінок
Окрема категорія ризику — сайти, зібрані на важких білдерах. Тут ситуація парадоксальна: сам редактор білдера здебільшого не зачеплений, бо він і так підміняє собою редактор WordPress і живе у власному інтерфейсі. Ламається периферія: доповнення до списків записів, панелі налаштувань, кастомні екрани, які білдер або його аддони додають в адмінку.
Практичний наслідок — перевіряти треба не сам конструктор, а набір його розширень, який зазвичай ніхто не інвентаризував. Саме там живуть маленькі плагіни від сторонніх авторів, куплені колись за пʼятнадцять доларів, і саме вони першими залишаються без оновлень. Це продовження тієї самої вартості володіння, що описана в матеріалі про конструктори всередині WordPress і рахунок, який приходить пізніше: кожна мажорна версія ядра перетворює накопичені аддони на список рішень.
Коли оновлюватися
Чотири ситуації — чотири різні відповіді.
- Прості сайти з поширеними плагінами. Оновлюйтеся після тесту на копії. До серпня 2026 року основні плагіни випустили сумісні версії; ризик зосереджений у дрібних або покинутих.
- Магазини й сайти з насиченою роботою в адмінці. Репетируйте на стейджингу з людьми, які реально працюють в адмінці, а не лише з розробником. Закладіть пів дня на перенавчання, бо екрани виглядають інакше навіть там, де нічого не зламано.
- Сайти з кастомними плагінами або власними розширеннями адмінки. Перевірте код на старі хуки таблиць і адмінський CSS до того, як чіпати продакшн. Це робота розробки з реальною оцінкою, а не кнопка оновлення.
- Сайти на PHP 7.2 або 7.3. Спершу полагодьте хостинг. Перебування на непідтримуваній версії PHP і так було більшою проблемою — з причин, викладених у матеріалі про вибір хостингу й те, де не варто економити.
У кожному випадку послідовність та сама, що робить оновлення нецікавими: копія на стейджинг, оновлення, прохід реальними сценаріями, потім повторення на продакшні у вікні, коли хтось доступний, — дисципліна описана в матеріалі про оновлення живого сайту без поломок.
Передоновлювальний аудит, конкретно
Година перевірок запобігає більшості неприємних наслідків.
Складіть список усіх плагінів із датою останнього оновлення й подивіться, чи заявив автор сумісність із 7.0. Усе, чого не торкалися рік, — кандидат на заміну, а не питання сумісності. Це водночас момент помітити, що покинуті плагіни є основним шляхом компрометації сайтів, як показано в матеріалі про те, як швидко експлуатують вразливості плагінів.
Далі відкрийте екрани «Записи» й «Медіа» і випишіть кожну доробку, яку бачите: додаткові колонки, фільтри, масові дії, кольорові рядки. Цей список і є вашим тестовим сценарієм після оновлення.
Перевірте версію PHP у «Інструменти → Здоровʼя сайту» й уточніть у хостера, що передбачає перехід. Зробіть резервну копію, яку ви хоча б раз реально відновлювали, і тримайте її, доки оновлення не переживе тиждень нормальної роботи.
Окремо попередьте редакторів і контент-менеджерів до, а не після оновлення. Найдорожчі години підтримки після мажорних релізів витрачаються не на поломки, а на людей, які не впізнали інтерфейс і вирішили, що зламався сайт. Скриншот нового екрана записів у робочому чаті напередодні, з одним реченням про те, що саме змінилося і де тепер шукати фільтри, знімає більшість цих звернень і коштує пʼять хвилин.
Нарешті визначте, хто на звʼязку. Оновлення, застосоване в пʼятницю по обіді людиною, яка потім пішла на вихідні, — найнадійніший спосіб перетворити малу проблему на довгу.
Про що цей реліз свідчить на наступні два роки
Три наслідки варто закласти в плани, бо вони змінюють вартість володіння сайтом, а не лише його вигляд цього місяця.
Перебудова адмінки не завершена. Кастомні типи записів зберегли класичні екрани в 7.0, і це відстрочка, а не політика. Усе, що ви будуєте зараз із розширенням адмінських списків, має писатися з розрахунком на переїзд, а плагін, куплений заради інтеграції в адмінку, — це плагін, до якого ви ще повернетеся.
Екосистема плагінів проріджуватиметься. Адаптація до DataViews — це реальна робота, і для безкоштовного плагіна з кількома тисячами встановлень і без доходу мейнтейнера ця робота не станеться. Очікуйте хвилю тихих покинутих проєктів протягом року. Це аргумент перевірити залежності зараз, поки заміну можна обрати спокійно.
PHP рухатиметься далі. Планка піднялася до 7.4 після років застою, а рекомендація вже 8.3. Хостинг, який не може дати актуальну версію PHP на запит, заблокує й ваше наступне оновлення, і це вже питання закупівлі, а не техніки.
Якщо оновитися поки не можна
Залишатися на 6.x якийсь час — легітимне рішення, за умови що це рішення, а не недогляд.
Продовжуйте отримувати оновлення безпеки: попередня гілка ще певний час їх отримує, але цей час скінченний і не залежить від вас. Призначте дату перегляду замість безстрокового відкладання й використайте час, щоб замінити плагін, який вас блокує, а не чекати на виправлення від того, хто перестав відповідати.
Не вимикайте автоматичні мінорні оновлення, поки чекаєте. Мінорні релізи — це релізи безпеки; ви відкладаєте мажорну версію, а змішування цих двох речей і є тим, як сайти опиняються на два роки позаду.
Коротко
- WordPress 7.0 «Armstrong» вийшов 20 травня 2026 року, піднявши мінімальну версію PHP до 7.4 і рекомендуючи 8.3 для ІІ-функцій.
- DataViews замінює таблиці списків у «Записах», «Сторінках» і «Медіа». Кастомні типи записів у цьому релізі зберігають класичні екрани.
- Поломки адміністративні, а не публічні. Страждають кастомні колонки, масові дії, доробки швидкого редагування й адмінський CSS; відвідувачі не бачать нічого.
- Спільне редагування в реальному часі прибрали з релізу в травні 2026 року через проблеми зі стабільністю.
- ІІ-функції — це інфраструктура, а не продукт. Оновлюйтеся заради самого релізу й залишайте конектори неналаштованими, доки конкретний плагін їх не виправдає.
- Аудит до оновлення: дати оновлення плагінів, доробки, видимі на екрані записів, версія PHP, відновлена резервна копія й названа людина на звʼязку.
