«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 апреля. Увидим.
