WordPress 7.0 не вышел по первоначальному графику. Релиз планировали на 9 апреля, но цикл разработки продлили. Сейчас дополнительные pre-release версии поставлены на паузу до 17 апреля, а обновленный график финального этапа команда ядра обещает опубликовать не позднее 22 апреля.
Это не история про «не успели докрутить пару кнопок». В WordPress 7.0 заложены крупные изменения, которые затрагивают саму логику работы редактора и будущую архитектуру экосистемы. Самая заметная часть, из-за которой вокруг релиза стало особенно шумно, это совместное редактирование в реальном времени.
Почему WordPress 7.0 задерживается
Главная причина продления цикла связана с отзывами тестировщиков по реализации real-time collaboration. Команде ядра нужно больше времени, чтобы разобраться с архитектурой хранения данных, синхронизацией, присутствием пользователей в редакторе и поведением кеша.
Совместное редактирование звучит просто только на презентации. На практике это не «показать два курсора в редакторе». Нужно обеспечить корректную работу нескольких пользователей в одном документе, не устроить конфликт изменений, не перегрузить базу данных и не сломать привычную модель WordPress, где большинство сайтов больше читают, чем постоянно записывают данные.
Отдельная дискуссия идет вокруг того, как лучше хранить данные для такой функции. Рассматривался вариант с новой таблицей в базе данных, потом часть логики обсуждали через postmeta и transients. В итоге разработчики решили взять дополнительное время, чтобы не заложить в ядро решение, которое потом придется годами обходить костылями. В WordPress такие вещи лучше делать один раз нормально, потому что потом это будет жить в миллионах сайтов.
Что происходит с релизным циклом
Формально WordPress 7.0 уже был на позднем этапе подготовки, поэтому возврат к более ранней логике тестирования выглядит необычно. В официальном сообщении прямо говорится, что ситуация с возвратом к beta-подходу после стадии Release Candidate для WordPress нетипичная.
На время паузы новые функции в релиз уже не должны добавляться. Разрешены исправления багов текущего цикла, улучшения тестов и правки, связанные со стабильностью совместного редактирования. Также отдельно упоминаются доработки нового экрана Connectors в админке. То есть речь не о том, что в WordPress 7.0 сейчас начнут накидывать новые идеи. Скорее наоборот, разработчики пытаются стабилизировать то, что уже попало в релизный поезд.
Для тестирования рекомендуют использовать свежие nightly builds из ветки 7.0. Это нормальный вариант для разработчиков тем, плагинов и тех, кто хочет заранее проверить совместимость на тестовом окружении. На рабочий сайт такое ставить не надо. Продакшен и nightly builds дружат примерно так же, как обновление базы на живом магазине в пятницу вечером.
Совместное редактирование в реальном времени
Самая заметная функция WordPress 7.0 это real-time collaboration. Идея понятная: несколько пользователей смогут одновременно работать над одним материалом в редакторе. В идеале это должно приблизить работу с постами и страницами к привычной логике Google Docs, где видно, кто сейчас редактирует документ и где именно находится другой участник.
Для контентных команд это действительно большой шаг. Один человек пишет текст, второй правит структуру, третий проверяет факты, четвертый занимается изображениями и блоками. Сейчас такая работа часто превращается в очередь: один зашел, второй ждет, третий пишет правки в мессенджер, четвертый уже забыл, что хотел поменять. Совместное редактирование должно убрать часть этой возни.
Для агентств и командных проектов польза тоже очевидна. Можно вместе работать над посадочной страницей, обзором продукта, новостью, документацией или большим SEO-материалом. Клиент видит изменения, редактор правит текст, разработчик проверяет блоки и верстку. Если это заработает стабильно, привычный процесс подготовки контента в WordPress станет заметно удобнее.
Но именно слово «стабильно» здесь ключевое. Совместное редактирование влияет на записи в базе, синхронизацию состояния, активные сессии пользователей и поведение хостинга. Для одиночного блога это может быть почти незаметно. Для большого сайта с редакцией и десятками авторов это уже полноценная инфраструктурная история.
AI Client в ядре WordPress
Вторая важная часть WordPress 7.0 это AI Client. Это не встроенный чат-бот и не кнопка «сделать сайт умным». Скорее это базовый слой для разработчиков, который дает более единый способ подключать AI-возможности к плагинам и функциям WordPress.
Раньше каждый плагин мог тащить свою логику работы с AI, свои зависимости, свои подходы к запросам и настройкам. Это быстро превращается в зоопарк. Один плагин использует один пакет, второй другой, третий хранит настройки по-своему, четвертый конфликтует с зависимостями. AI Client должен помочь привести эту часть экосистемы к более единой архитектуре.
Практическая польза для пользователей появится не сама по себе, а через плагины и темы, которые начнут использовать этот слой. Например, расширение для SEO сможет аккуратнее генерировать мета-описания, плагин медиа-библиотеки сможет предлагать alt-тексты, редакторский инструмент сможет помогать с сокращением текста или изменением тона. Но это не значит, что после обновления до WordPress 7.0 в админке внезапно появится полноценный универсальный AI-центр. Это фундамент, а не готовый дом с мебелью.
Для разработчиков плагинов здесь больше интересного. Если часть инфраструктуры переезжает ближе к ядру, становится проще писать совместимые решения и меньше шансов получить конфликты из-за одинаковых библиотек. Особенно это касается проектов, которые уже экспериментировали с пакетами WordPress для AI до попадания части логики в Core.
PHP 7.4 становится минимальным требованием
Еще одно изменение, которое нельзя игнорировать, это повышение минимальной версии PHP. В WordPress 7.0 поддержку PHP 7.2 и 7.3 убирают, новой минимальной версией становится PHP 7.4. Рекомендуемая версия при этом выше, но именно 7.4 станет нижней границей для запуска.
Для большинства современных хостингов это не проблема. Но на старых VPS, забытых shared-хостингах и проектах, которые давно никто не трогал, PHP 7.2 или 7.3 все еще могут встречаться. Такой сайт сначала нужно привести в порядок на уровне окружения, а уже потом думать про WordPress 7.0.
Проверить версию PHP можно в админке WordPress через «Инструменты» и «Здоровье сайта». На сервере это делается еще проще:
php -v
Если на сервере несколько версий PHP, дополнительно стоит проверить именно ту, которую использует сайт через PHP-FPM. На VPS с Nginx это часто важнее, чем просто посмотреть системный php -v в консоли.
php -v
systemctl list-units --type=service | grep php
Что еще ждать от WordPress 7.0
WordPress 7.0 выглядит как крупный релиз не только из-за совместного редактирования и AI Client. В нем ожидаются изменения в редакторе, админке, внутренних API и общей инфраструктуре. Часть этих вещей обычный владелец сайта заметит не сразу, зато разработчики тем и плагинов увидят разницу быстрее.
Для редакторов и контентных команд главная ценность, конечно, в улучшении совместной работы. Для разработчиков важнее архитектурные изменения, AI Client, совместимость с новыми требованиями и подготовка своих расширений. Для владельцев сайтов главный вопрос проще: обновляться можно будет, но только после проверки окружения, бэкапа и теста на копии сайта.
Именно поэтому я бы не относился к WordPress 7.0 как к рядовому обновлению в стиле «нажал кнопку и пошел пить чай». Это крупная версия, а крупные версии любят показывать характер именно там, где сайт годами жил на старых плагинах и честном слове.
Кому обновляться сразу, а кому подождать
Если сайт простой, плагины актуальные, тема поддерживается, PHP свежий, а перед обновлением есть нормальный бэкап, переход на WordPress 7.0 после стабильного релиза должен быть спокойным. Но даже в этом случае лучше сначала пройти стандартный минимум: копия базы, копия файлов, проверка PHP и тест на staging.
Если сайт сложный, с WooCommerce, кастомными плагинами, нестандартной админкой, ACF-полями, интеграциями, Redis, Nginx, cron-задачами и прочей взрослой инфраструктурой, обновляться в первые часы после релиза я бы не спешил. Лучше дождаться первых отзывов, проверить совместимость ключевых плагинов и прогнать тестовую копию.
Особенно внимательно стоит смотреть на плагины, которые вмешиваются в редактор, REST API, админку, списки записей, пользовательские роли и права. Именно такие вещи чаще всего ломаются не на главной странице сайта, а где-нибудь в глубине админки, когда клиент уже спрашивает, почему кнопка пропала.
Как подготовить сайт к WordPress 7.0
Нормальная подготовка начинается не с кнопки «Обновить», а с проверки окружения. Сначала смотрим PHP. Если сайт ниже 7.4, сначала обновляем PHP на тестовой копии. Лучше сразу целиться в актуальную ветку PHP, которую поддерживает ваш стек и плагины, а не просто прыгать на самый нижний допустимый уровень.
Дальше делаем полный бэкап базы и файлов. Для WordPress на VPS это можно сделать через обычный дамп базы и архив сайта. Например:
wp db export ~/backup-before-wp-70.sql --allow-root tar -czf ~/site-files-before-wp-70.tar.gz /var/www/example.com/htdocs
После этого обновляем плагины и тему на тестовом окружении, включаем отладку при необходимости и проверяем основные сценарии: вход в админку, редактор блоков, публикацию записи, формы, поиск, кеш, WooCommerce, если он есть, личный кабинет, корзину и checkout.
Для сайтов на Nginx и WordOps отдельно стоит проверить кеширование, Redis, cron и логи PHP-FPM. Иногда после крупных обновлений проблема не в самом WordPress, а в старом плагине, который начал сыпать предупреждениями или конфликтовать с новой логикой редактора.
journalctl -u php8.3-fpm --since "30 minutes ago" tail -n 100 /var/log/nginx/error.log
Что делать прямо сейчас
Сейчас главное не гадать на кофейной гуще, а следить за обновленным графиком. До 22 апреля команда ядра должна опубликовать новый план финального этапа WordPress 7.0. После этого будет понятнее, когда ждать стабильный релиз и сколько времени остается на подготовку.
Если вы сопровождаете сайты клиентов, уже сейчас стоит проверить версии PHP, список старых плагинов и наличие тестовых копий. Если сайт один и он ваш, все равно лучше не откладывать. Проверка PHP занимает пару минут, а спасает иногда от очень долгого вечера.
WordPress 7.0 обещает быть заметным релизом. Совместное редактирование, AI Client и изменения в архитектуре действительно могут изменить привычную работу с контентом. Но именно поэтому обновляться нужно спокойно. Без паники, без спешки и без героического клика на продакшене сразу после выхода версии.
Итог
WordPress 7.0 задерживается не потому, что релиз развалился, а потому что в него попали крупные функции, которые требуют аккуратной доводки. Real-time collaboration влияет на редактор, базу данных, синхронизацию и поведение хостинга. AI Client закладывает базу для будущих AI-интеграций в плагинах. Повышение минимальной версии PHP до 7.4 заставит владельцев старых сайтов наконец посмотреть на сервер не как на вечный холодильник из 2009 года.
Ждать WordPress 7.0 стоит. Обновляться тоже стоит, но только после нормальной проверки. Большой релиз любит подготовленных. Остальных он обычно учит через логи, бэкапы и фразу «а почему у нас редактор не открывается».
