«WordPress 7.0 — це як капітальний ремонт у твоїй квартирі. Результат може бути чудовим, але процес — нервовий»
WordPress 7.0: косметичний ремонт чи справжній апгрейд?
20 лютого WordPress спільнота отримала чудову новину про 7.0 Beta 1 апдейт, а згодом — Beta 2 (26 лютого). Після чого я одразу ж встановив бета версію, поклацав, покрутив — і маю досить неоднозначні враження. Деякі речі дійсно радують і дивують, а деякі — відверто дратують, а щось потребує місяців реального використання з клієнтами, перш ніж можна буде впевнено сказати шось конкретне.
Офіційний реліз запланований на 9 квітня 2026 року і часу на тестування достатньо. Але вже зараз видно напрямок, у якому рухається WordPress. І цей напрямок — не для всіх.
Що каже спільнота
Настрій спільноти — неоднозначний. У тредах і коментарях можна зустріти одну й ту саму думку: глобальний напрямок WordPress не подобається, платформа обростає функціями, які ніхто не просив. Але поки вона стабільно закриває задачі клієнтів — всі продовжують її використовувати. Бізнесу потрібен результат, а не холівари про ідеальну платформу.
Хтось хвалить, хтось ненавидить, хтось просто працює, закриваючи очі на усім давно знайомі недоілки платформи – типова картина для кожного мажорного релізу. Серед коментарів можна зустріти цікаві думки: замовники приходять з бажанням тимчасово побудувати MVP на WordPress, бо це швидко і дешево. Типу, як почне приносити гроші, перейдемо на щось інше. Але по факту, потім ці проєкти живуть роками і приносять нормальні гроші і ніхто нікуди не переходить, залишаючись на WordPress.
Це реальність, яку часто ігнорують у технічних дискусіях. WordPress живе не тому, що він ідеальний. Він живе тому, що закриває задачі. І 7.0 — це спроба зробити так, щоб він закривав ще більше задач, питання лише — якою ціною?
Адмінка: нові кольори, плавні переходи і біль в очах
Почну з того, що мене поки що не дуже влаштовує. WordPress 7.0 змінює зовнішній вигляд адміністративної панелі. Нова кольорова схема і плавні переходи між сторінками без перезавантаження.
Звучить добре на папері. На практиці — кольори ріжуть очі. Я серйозно. Спільнота пише про це прямо: білий екран на переходах між сторінками, кольори — вирви око. Розробники, які ставлять клієнтам кастомні теми адмінки, зітхнули з полегшенням. Решта — не дуже.
Плавні переходи між сторінками адмінки — це те, чого ніхто не просив. Адмінка WordPress — це робочий інструмент. Мені не потрібна анімація при переході з «Записи» на «Сторінки». Мені потрібно, щоб воно працювало швидко і передбачувано. Ці view transitions — це як поставити неонову підсвітку днища на робочий мікроавтобус. Красиво? Можливо. Потрібно? Ні.
Добре, що кастомні теми адмінки все ще працюють. Для клієнтських проєктів я завжди ставлю брендовану тему адмінки, тож ця проблема мене зачепить мінімально. Але для тих, хто працює з дефолтним інтерфейсом — це буде ще той сюрприз.
Gutenberg у iframe — нарешті
А ось це — реально хороша новина. У WordPress 6.9 почали переносити редактор в ізольований iframe, але тільки для блоків з apiVersion 3. У 7.0 цей перехід завершується повністю.
Чому це важливо? Тому що до цього стилі теми, плагінів і самої адмінки змішувались у редакторі в один хаос. CSS-конфлікти між темою і Gutenberg — це класика жанру для кожного WordPress-розробника. Iframe ізолює редактор від решти адмінки. Чистий sandbox та ніяких CSS конфліктів. Для кастомної WordPress розробки це означає менше часу на дебаг проблем зі стилями і більше передбачуваності. Те, що мало бути зроблено ще два роки тому, але краще пізно, ніж ніколи.
Спільне редагування: Google Docs для WordPress?
WordPress 7.0 вводить режим спільного редагування в реальному часі. Кілька людей можуть одночасно працювати над одним записом, бачити курсори один одного і залишати коментарі через Notes. Синхронізація йде через HTTP-polling з можливістю WebSocket.
У спільноті вже жартують: «Мабуть, щоб клієнт міг ламати верстку в реальному часі та заважати розробнику». І знаєте що — це правда, воно так і буде в майбутньому.
Чесно, я не знаю, наскільки це буде корисно на реальних проєктах. У Notes з версії 6.9 вже знайшли вразливість обходу авторизації, яку латали в 6.9.4. Collaboration звучить як фіча для великих редакцій з десятками авторів. Для типового WordPress-сайту з одним-двома контент-менеджерами — це потужний оверкіл.
Але я не відкидаю це повністю. Треба тестити на реальних проєктах та з реальними клієнтами, дивитися як воно поводиться під навантаженням, з повільним інтернетом, з конфліктуючими правками. Поки що — цікаво, але без ейфорії.
AI в ядрі: Settings → Connectors
WordPress 7.0 додає нову сторінку Settings → Connectors для підключення зовнішніх AI-провайдерів. OpenAI, Claude, Gemini — все через єдиний інтерфейс. Плюс WP AI Client — уніфікований API для роботи з будь-яким провайдером із плагінів і тем.
Хтось із спільноти написав: «Всі намагаються влізти в цей вагон “Нам треба AI, пофіг для чого”. Чую прийдеться його вирізати щоб сайт був стабільніший». Я розумію цей скепсис. Але у мене інший кут зору.
За останній рік я побудував кілька AI-інструментів для своїх клієнтів: автоматичний переклад контенту, генерація текстів, створення постів і навіть ШІ асистент з повноцінною RAG логікою. Підключав Claude, OpenAI, Gemini — кожен раз писав інтеграцію з нуля або через власні плагіни. Кожен раз — свій формат запитів, свій спосіб зберігання ключів, своя логіка обробки відповідей.
Якщо WordPress дасть єдиний стандартизований спосіб працювати з AI-провайдерами — це спростить розробку. Замість того, щоб кожен плагін винаходив свій велосипед для зберігання API-ключів і маршрутизації запитів, буде один інтерфейс. Один хук. Одна точка конфігурації.
Інше питання — як це реалізовано. Abilities API, Client Side Abilities, Connectors UI — це три нових абстракції за два мінорних релізи. Не забагато? Час покаже. Але сама ідея вбудованої AI-інфраструктури — правильна.
PHP-only блоки: найцікавіше для розробників
Ось це — та фіча, від якої в мене реально чешуться руки. WordPress 7.0 дозволяє реєструвати блоки повністю на PHP. Без JavaScript. Без React. Без збірки. Без npm install. Один виклик register_block_type() — і блок з’являється в редакторі.
Як це працює: ви описуєте атрибути блоку в PHP, додаєте прапорець autoRegister в масив supports, вказуєте render_callback — і WordPress автоматично генерує панель налаштувань в інспекторі. Рядкові атрибути стають текстовими полями. Boolean — перемикачами. Enum — випадаючими списками. Все це без жодного рядка JavaScript.
Для контексту: зараз, щоб створити навіть найпростіший кастомний блок, потрібно написати block.json, React-компонент для редактора, налаштувати збірку через @wordpress/scripts, і тільки потім додати PHP-рендер ну або використовувати інші обхідні шляхи через Advanced Custom Fields, як це зараз роблю я. Для серверного блоку типу «банер з CTA» або «блок автора» йти шляхом block.json — це непропорційно багато роботи.
PHP-only блоки прибирають цей бар’єр повністю. Один PHP-файл. Одна функція. Ніякого білд-процесу. Для WordPress-розробників, які живуть у PHP і не хочуть заглиблюватися в React-екосистему — це проривна зміна.
Є обмеження. Немає підтримки InnerBlocks — вкладених блоків. Немає rich-text редагування прямо в редакторі — превʼю рендериться через ServerSideRender, і кожна зміна атрибуту йде через REST API. Немає вибору медіафайлів через стандартний Media Library picker. Для складних інтерактивних блоків це не підходить.
Але для 80% кастомних блоків, які я створюю на клієнтських проєктах — інформаційні банери, CTA-секції, блоки з контактами, кастомні цитати — PHP-only підхід закриє потребу повністю. Менше коду, менше залежностей, швидший розвиток.
Нові блоки і покращення редактора
Крім архітектурних змін, WordPress 7.0 додає нові core-блоки та покращує існуючі:
- Breadcrumbs та Icons — нарешті в ядрі, без сторонніх плагінів
- Navigation Block — переписаний, з підтримкою мобільних overlay-меню
- Cover Block з відео-фоном — можна ставити відеоролик як фон секції
- Grid Block — адаптивний за замовчуванням
- Gallery з лайтбоксом — перегляд зображень у модальному вікні
- Адаптивна видимість блоків — можна ховати конкретні блоки для мобілки чи десктопа прямо з коробки
Щодо адаптивної видимості — я не зміг її знайти одразу. Інші розробники теж пишуть, що в плейграунді цього не видно. Або вона працює не для всіх блоків, або потребує додаткових налаштувань. Буду тестити далі.
Відео-фони для Cover Block і кастомний CSS прямо в панелі блоку — це те, для чого раніше потрібні були плагіни типу Stackable або GenerateBlocks. Якщо це працює стабільно — одним плагіном менше на кожному проєкті і це вже добре!
Обробка зображень у браузері
WordPress 7.0 додає client-side media processing — зображення змінюються і стискаються прямо в браузері перед завантаженням на сервер. Менше навантаження на хостинг, підтримка новіших форматів.
На папері — чудово. На практиці — потрібно тестувати. Як це працює на слабких пристроях? Що з великими зображеннями? Чи не кластиме це браузер? У мене немає відповідей поки що, але для клієнтів, які завантажують фото з телефону без будь-якої оптимізації — це потенційно корисна фіча.
Безпека: 6.9.4 нагадує про реальність
Поки всі обговорюють 7.0, 11 березня тихо вийшов WordPress 6.9.4 — безпековий патч. Три уразливості: path traversal у PclZip, обхід авторизації в Notes і XXE у бібліотеці getID3. Причому деякі з них не змогли закрити з першого разу — 6.9.2 і 6.9.3 не повністю вирішили проблему.
Це нагадування: нові фічі — це добре, але безпека існуючого коду — це пріоритет. Хто ще не оновився до 6.9.4 — зробіть це зараз же!
Підсумок
WordPress 7.0 — це капітальний ремонт. Стіни зносять, труби міняють, електрику перекладають. Жити в цьому поки що некомфортно. Але якщо все зроблять правильно — через рік ми будемо дякувати за ці зміни.
Реліз — 9 квітня. Побачимо.
