Первая бета WordPress 7.2 запланирована на 20 октября 2026 года. Об этом напоминает официальный обзор разработчиков от 14 октября. Для владельца работающего сайта это не сигнал срочно переключать версию ядра, а возможность заранее договориться с разработчиком о проверке совместимости. До финального выпуска ещё несколько этапов, и состав изменений пока нельзя считать окончательным.
По состоянию на 17 октября 2026 года Beta 1 ещё не вышла по опубликованному графику. Ниже — календарь и наш разбор того, как использовать оставшееся время без экспериментов с рабочим сайтом.
| Этап WordPress 7.2 | Плановая дата | Что это означает |
|---|---|---|
| Beta 1 | 20 октября 2026 | Начало запланированной серии бета-выпусков |
| Beta 2–4 | 27 октября, 3 и 10 ноября | Следующие контрольные сборки для тестирования |
| RC1 | 17 ноября 2026 | Первый кандидат в релиз |
| Финальный выпуск | 8 декабря 2026 | Запланированная общедоступная версия |
Источник дат — расписание релизов Make WordPress Core, опубликованное 6 октября. Команда допускает корректировки. Это план, а не подтверждение состоявшегося выпуска каждой сборки; перед началом тестирования нужно сверить расписание и фактическую доступность версии.
Что пока остаётся планом, а не готовой функцией
Дорожная карта от 18 сентября прямо предупреждает: работа над направлением не гарантирует его включения в итоговый релиз. Среди намеченных изменений — расширяемый Site Editor, развитие DataViews и DataForms, новые возможности оформления форм и новая минималистичная тема Ipsum.
Поэтому обещать заказчику конкретный интерфейс до проверки сборки рано. Например, улучшение Global Styles не означает, что все поля стороннего плагина форм автоматически получат нужное оформление. Здесь наша практическая оговорка: результат зависит и от реализации самого расширения.
Отдельно важно не путать заметки к блокам с полноценным совместным редактированием в реальном времени. Последнее намеренно не включено в дорожную карту 7.2. React 19 также не стоит закладывать как гарантированную основу проекта: в roadmap его полный переход для этой версии назван маловероятным.
Для AI-направления действует похожая граница. Работы над соответствующими возможностями ведутся в отдельных плагинах, без обещания перенести их в ядро именно в 7.2. Если интеграция нужна вашему бизнесу сейчас, её следует оценивать как отдельную задачу, а не как функцию, которая обязательно появится после декабрьского обновления.
Три разных сайта — три разных приоритета проверки
Дальше — рекомендации UWEAM, а не перечень подтверждённых ошибок WordPress 7.2. Мы не утверждаем, что перечисленные сценарии сломаны: это способ выбрать проверки, значимые для конкретного проекта.
Сайт услуг с обычными страницами. Возьмите одну реальную посадочную страницу и один материал блога. Сохраните их, повторно откройте редактор и проверьте изображения, ссылки, мобильную раскладку и форму обращения. Полезный результат — не просто отметка «главная открылась», а подтверждение, что редактор может выполнить повседневную задачу от начала до конца.
Проект с собственными Gutenberg-блоками. В приоритете — сохранение атрибутов, повторное редактирование уже опубликованного контента и настройки в боковой панели. Сравните исходную запись и её копию после сохранения на тестовой версии. Если настройка исчезла или блок требует восстановления, зафиксируйте точный пример, а не исправляйте исходную публикацию на рабочем сайте.
Магазин или сайт с внешними интеграциями. Отделите проверку редактора от бизнес-операций: корзины, оформления заказа, уведомлений и обмена данными. Используйте тестовые реквизиты и получателей. Тестовая копия не должна отправлять клиентам настоящие сообщения или повторно создавать сделки в рабочей CRM.
Общий принцип один: выбирайте проверки по цене возможного отказа. Для медиа критично сохранение и публикация статьи, для магазина — завершение заказа. Чужой универсальный список легко пройти целиком и при этом пропустить единственный сценарий, на котором держится ваш бизнес.
Что подготовить до 20 октября
Сейчас достаточно зафиксировать текущие версии ядра, PHP, темы и ключевых расширений, выбрать ответственного и подготовить изолированную копию. Как отделить её от рабочего окружения, разобрано в материале про тестовый стенд WordPress. Не нужно заменять стабильное ядро на production ради готовности к бете.
Для результатов заведите короткий журнал: сборка, окружение, действие, ожидаемое поведение, фактический результат. Добавьте скриншот или минимальный воспроизводимый пример, если нашли проблему. Запись «не работает редактор» почти не помогает разработчику; запись «после повторного сохранения конкретный блок теряет выбранное изображение» уже даёт направление проверки.
Не объединяйте в одном эксперименте новое ядро, другую версию PHP и смену набора плагинов. Иначе при отклонении придётся сначала выяснять, какое изменение его вызвало. Если ограничены во времени, начните с одного важного сценария на подготовленном стенде и расширяйте набор постепенно.
Ближайшая контрольная точка — появление Beta 1 по плану 20 октября. После неё стоит повторно сверить фактический состав изменений и сообщения разработчиков используемых расширений. Решение об обновлении рабочего сайта принимают по готовности проекта и стабильного релиза, а не только по красивой дате в календаре.
Проверено 17 октября 2026 года. Первичные источники: официальный обзор от 14 октября, расписание Make/Core от 6 октября и roadmap от 18 сентября. Даты будущих выпусков приведены как плановые. Практическая программа проверки — редакционные рекомендации UWEAM, не отчёт о тестировании вашего сайта.
