WordPress 7.0 — что нового и почему обновление ядра важно

Что нового в WordPress 7.0 Armstrong

WordPress 7.0 — крупный релиз ядра и редактора. По официальному Field Guide в него вошло более 419 тикетов Core Trac, из них более 76 — улучшения и запросы функциональности и более 300 — исправления ошибок. Дополнительно для редактора, дашборда и AI-интеграции — 411 улучшений и более 486 исправлений ошибок для редактора, дашборда и AI-интеграции. Ниже — только то, что действительно вошло в финальный релиз.

Функция совместного редактирования в реальном времени не вошла в WordPress 7.0. Её убрали из релиза из-за опасений по surface area, race conditions, нагрузке на сервер и эффективности использования памяти, выявленных при fuzz-тестировании. Команда планирует доработки и тестирование в формате feature plugin перед повторной попыткой в будущем релизе.

AI-фундамент в ядре — что это и чего нет из коробки

WordPress 7.0 заложил инфраструктуру для AI, но не включает готовые генеративные функции без дополнительных интеграций. Разделение такое:

• WP AI Client в Core — центральный интерфейс в ядре, через который плагины обращаются к генеративным моделям. Core маршрутизирует запросы, остаётся provider-agnostic.
• Abilities API — PHP-API для регистрации способностей (abilities) и их категорий. Интегрирован с AI Client для цепочек способностей.
• Client-Side Abilities API — JavaScript-пакет, counterpart серверного Abilities API, с UI и палитрой команд для вызова способностей в редакторе.
• Connectors API и экран Connectors — расширяемый API и экран Настройки → Connectors для управления подключениями к внешним сервисам. На экране демонстрируются featured connectors — примеры интеграций (вроде Anthropic, Google, OpenAI), которые реализуются через внешние плагины-провайдеры и не встроены в ядро напрямую; можно добавить и свои подключения. API поддерживает аутентификацию api_key и none и позволяет переопределять метаданные через wp_connectors_init.
• Внешние AI-провайдеры и плагины — конкретные провайдеры подключаются отдельно через плагины/интеграции. Core не содержит в себе ChatGPT, Claude или Gemini — это внешние сервисы, которые подключаются через Connectors.
• AI-инструменты в редакторе — такие возможности, как генерация заголовков, создание/редактирование изображений, подсказки alt-текста, предоставляются соответствующими AI-интеграциями/плагинами, а не ядром из коробки. Если конкретный плагин нужен — проверьте его официальное название, статус и требования перед установкой.

Само наличие AI Client и Connectors в Core не означает автоматической отправки контента во внешние AI-сервисы. Для фактических AI-запросов требуется соответствующая интеграция и настроенное подключение провайдера.

Обновлённая админка и редактирование

Админка получила сдержанное обновление без ломки привычного интерфейса:

• Modern — новая цветовая схема по умолчанию — обновлённая палитра, контраст, типографика, переработанные шапки админки, кастомайзер, выбор схемы.
• View Transitions — плавные кросс-документные переходы между экранами wp-admin при смене активного подменю. Эффект «слайд» срабатывает только если в системе не включено предпочтение reduced motion.
• Command Palette — иконка ⌘K / Ctrl+K в верхней админ-панели. Открывает палитру команд для быстрого доступа к инструментам из любого места дашборда.
• Font Library на отдельной странице — управление шрифтами из одного места теперь доступно для всех типов тем: блок-тем, гибридных и классических. Установка, загрузка и подключение шрифтов без правки theme.json вручную.
• Visual Revisions — визуальное сравнение двух версий записи/страницы прямо в редакторе: слайдер, сводка изменений в инспекторе документа, цветовые маркеры и переход по клику к месту изменения.
• Iframed Editor — улучшенный изолированный редактор. Iframe принудительно включается, когда все блоки типа Block API используют версию 3 или выше. Если есть блоки ниже v3 — iframe отключается для обратной совместимости. Изоляция помогает меньше смешивать стили админки и контента, но не гарантирует отсутствие всех конфликтов CSS автоматически.

Также в интерфейсах данных появились обновления DataViews/DataForms: новый layout Activity, новый layout Details, улучшенный вид модалок и возможность регистрировать сторонние типы через Field API. Это инфраструктурное обновление компонентов для разработчиков и плагинов, а не полная замена всех табличных списков WordPress.

Блоки и дизайн-инструменты в 7.0

Ниже — только то, что подтверждено финальным релизом 7.0:

• Headings Block — новый блок с вариациями всех уровней заголовков, быстрым переключением в сайдбаре и поддержкой поиска/slash-вставки.
• Breadcrumbs Block — автоматически отражает иерархию навигации сайта, подходит для глобального размещения в шапке. Для разработчиков — фильтры для добавления/удаления/изменения цепочек и выбора таксономий.
• Gallery block — лайтбокс уже существовал ранее; в 7.0 добавлена опция слайдшоу: при включении «enlarge on click» изображения листаются как слайд-шоу с навигацией клавиатурой.
• Cover Block — получил поддержку фонового видео с YouTube и связанные улучшения работы с видеофоном.
• Navigation Block и настраиваемые оверлеи — редактирование навигации стало проще; гамбургер-оверлей можно собирать из блоков и паттернов в Site Editor с отдельным блоком закрытия Navigation Overlay Close и предпросмотром на месте.
• Custom CSS на уровне блока — возможность добавить кастомный CSS для конкретного блока прямо в редакторе. Это точечный инструмент для одного блока, а не универсальная замена дочерней темы. Для системных правок темы, шаблонов и глобальных стилей дочерняя тема/плагин остаётся правильным местом.
• Responsive Editing Mode — управление видимостью блока по типу устройства. Элементы управления доступны в тулбаре блока, сайдбаре инспектора и палитре команд; в List View показывается иконка у блоков с активными правилами. Это управление видимостью на уровне редактора, а не произвольный CSS-override для любого элемента без ограничений.
• Pattern Overrides — расширяют возможности синхронизированных паттернов: отдельные части паттерна можно сделать редактируемыми для конкретного экземпляра. В 7.0 эта возможность также расширена на кастомные блоки.

Производительность и инструменты разработчика

• Улучшена точность приоритизации загрузки изображений: скрытые изображения в оверлеях навигации или интерактивных блоках реже ухудшают загрузку критических ресурсов, включая LCP.
• On-demand загрузка стилей блоков в классических темах стала надёжнее и действительно загружает только нужные стили в определённых сценариях. Универсального большого прироста для любого классического сайта это не гарантирует — эффект зависит от темы, набора блоков, плагинов и кэша.
• Скрипты теперь могут зависеть от модулей (allow scripts to depend on modules) — это смягчает переход к ESM и может снижать блокировку рендера в поддерживаемых сценариях. Используется официальная терминология Script Loader.
• PHP-only регистрация блоков — возможность создавать и регистрировать блоки и паттерны напрямую на сервере средствами PHP с авто-регистрацией через Block API. Это возможность для разработчиков (объявление supports => ['autoRegister' => true] и render callback), а не кнопка в админке для обычного пользователя.
• Interactivity API — новая функция watch() в пакете @wordpress/interactivity и директива data-wp-watch для подписки на изменения сигналов и реакции жизненного цикла элемента. Значение state.url теперь заполняется на сервере при обработке директив.
• DataViews и DataForms — новые layout Activity/Details, улучшенные модалки, возможность регистрировать сторонние типы.
• Block Bindings и Pattern Overrides — итерации API для привязок блоков и переопределений паттернов для кастомных блоков.
• Site Editor extensibility — фундамент для расширяемого редактора сайта: маршрутизация, валидация маршрутов, пакет wordpress/boot для кастомных страниц редактора, переработанный @wordpress/scripts.

Конкретные цифры прироста скорости зависят от темы, плагинов, CDN и сервера, поэтому универсальных обещаний вроде «минус N мс на LCP каждому сайту» 7.0 не даёт. Изменения могут уменьшать лишнюю загрузку CSS и улучшать загрузку ресурсов в определённых конфигурациях.

Требования к PHP и базе данных

• Минимальная поддерживаемая версия PHP для WordPress 7.0 — 7.4. Поддержка PHP 7.2 и 7.3 снята в этом релизе. PHP 7.4 сама по себе устарела (EOL) — использовать её на новом проекте не следует, это лишь нижняя граница совместимости.
• Рекомендуемая версия — PHP 8.2 или выше. PHP 8.3+ — хороший выбор для нового или обновляемого проекта, но это уже практическая рекомендация, а не минимальное требование WordPress 7.0.
• MySQL / MariaDB — в официальных требованиях WordPress рекомендует MariaDB 10.11+ или MySQL 8.0+. Минимальные требования WordPress ниже, но для безопасности и производительности разумно держать современную базу. Не путайте минималку WordPress с рекомендуемой конфигурацией хостинга.

Почему обновляться — но корректно

Обновление ядра — вопрос безопасности, совместимости и поддержки, но не магии для скорости.

• Безопасность. WordPress продолжает выпускать отдельные security-исправления для поддерживаемых старых веток, поэтому отсутствие перехода на 7.0 само по себе не означает мгновенную потерю всех security-патчей. Пример: 7.0.4 от 12 августа 2026 содержит security-фикс, который был бэкпортирован вплоть до ветки 4.7. Однако новые функции и большинство изменений развиваются в актуальной ветке. См. разбор что делать после взлома.
• Совместимость. Современные плагины и темы тестируются на актуальных версиях ядра. Застревание на старом ядре повышает риск конфликтов при обновлении одного плагина. Перед major-обновлением проверяйте совместимость темы и ключевых плагинов на staging.
• Поддержка окружения. PHP 7.2/7.3 больше не поддерживаются в 7.0; современная конфигурация — PHP 8.2+ (PHP 8.3+ — хороший выбор для нового проекта). Чем дольше тянете, тем больше шанс, что придётся обновлять PHP и ядро одновременно.
• Скорость. WordPress 7.0 не обещает измеримый прирост скорости каждому сайту. Изменения вроде on-demand стилей и точной приоритизации изображений могут помогать в частных случаях, но итоговый LCP зависит от темы, плагинов и CDN.

Как безопасно перейти на ветку 7.0 (7.0.4) — пошагово

Делайте в копии (staging), не на живом сайте. Время зависит от размера сайта и количества плагинов.

Шаг 1. Бэкап файлов и базы

Универсальный пример (подставьте свой путь к WordPress вместо /path/to/wordpress):

# файлы — архивируем именно папку WordPress, а не корень системы
tar -czf ~/backup-2026-08-26.tgz -C /path/to wordpress
# база
mysqldump -u DB_USER -p DB_NAME | gzip > ~/db-2026-08-26.sql.gz
# альтернатива WP-CLI
wp db export ~/db-export.sql --path=/path/to/wordpress

На shared-хостинге без SSH используйте бэкап из панели хостинга. Убедитесь, что архив скачивается и восстанавливается.

Шаг 2. Проверить PHP и MySQL

php -v
wp core version --path=/path/to/wordpress
wp core check-update --path=/path/to/wordpress

Откройте Инструменты → Здоровье сайта → Информация → Сервер. Для 7.0 нужен PHP 7.4+; разумно держать 8.2+ (8.3+ — хороший выбор). Помните: версия в CLI (php -v) и версия, под которой работает сайт (FPM), могут различаться — проверяйте обе.

Шаг 3. Обновить окружение в staging

• Проверьте текущие версии темы и ключевых плагинов. Обновляйте компоненты контролируемо на staging и проверяйте сайт после каждого существенного изменения. Плагин без поддержки повышает риск несовместимости и безопасности — если есть поддерживаемый аналог, лучше заменить.
• Проверьте дочернюю тему: уберите прямые правки ядра, перенесите кастом в отдельный плагин или mu-plugin.
• Исключите кэш из диагностики на время теста или очистите его после обновления — полностью отключать весь кэш без необходимости не нужно.

Шаг 4. Обновиться в staging

# через WP-CLI
wp core update --path=/path/to/wordpress
# админка: Консоль → Обновления → Обновить сейчас
# версия БД при необходимости обновится автоматически при первом заходе в админку
# принудительно проверить/завершить можно:
wp core update-db --path=/path/to/wordpress

WordPress обычно выполняет необходимое обновление БД сам; отдельная команда wp core update-db нужна лишь для проверки/завершения, а не как обязательный ручной шаг после каждого обновления.

Если нужны AI-возможности — подключайте их потом через соответствующие плагины/провайдеры и экран Настройки → Connectors, а не как «один официальный AI-плагин с тремя кнопками».

Шаг 5. Прогнать проверки

wp core verify-checksums --path=/path/to/wordpress
# проверяет только ядро WordPress, не плагины и не тему
tail -n 100 /path/to/wordpress/wp-content/debug.log
# при включённом WP_DEBUG_LOG

Шаг 6. Выкатить на прод и очистить кэш

Перенесите проверенные файлы/БД из staging или повторите шаги на проде после свежего бэкапа. Затем:

wp cache flush --path=/path/to/wordpress

Если используете Cloudflare/CDN — очистите кэш там. Для Nginx на VPS — systemctl reload nginx по необходимости. В браузере — жёсткая перезагрузка.

Проверка результата

Откройте сайт в инкогнито и пройдите чек-лист:

• Инструменты → Здоровье сайта — без критических замечаний, PHP поддерживаемый, версия WordPress — 7.0.4 (если остаётесь на ветке 7.0) или 7.1.x (если переходите на актуальную).
• Консоль → Обновления — «У вас последняя версия» для выбранной ветки.
• Логи — ищите fatal error, warning, deprecated и JS-ошибки. Разовые harmless notices сами по себе не означают поломку, но их стоит проверить.
• Фронтенд: главная, запись, страница, поиск — без 500 и без битых стилей.
• Админка: вход, создание/сохранение записи, загрузка медиа.
• Формы — отправка и получение письма (проверьте через лог SMTP).
• WooCommerce (если есть): корзина и чекаут.
• Консоль браузера — без критических JS-ошибок.
• Cron: wp cron event list --path=/path/to/wordpress — без зависших задач.
• Кэш/CDN — сброшен и сайт отдаёт свежую версию.

Когда обновление может сломать сайт

• Хостинг застрял на PHP 7.2/7.3. WordPress 7.0 (и 7.0.4) не установится — минимум 7.4. Решение — повысить версию PHP в панели или перейти на VPS. Гайд по VPS — настройка VPS под WordPress.
• Заброшенные плагины/темы. Код без обновлений может быть несовместим с современным PHP или новыми API. Симптомы — fatal errors после обновления. Замените на поддерживаемые аналоги.
• Тяжёлая тема с хардкодом ядра. Правки напрямую в wp-includes или переопределение внутренних функций ломаются на обновлениях. Держите правки в дочерней теме или отдельном плагине.
• Старый кастомный код. Устаревшие конструкции вроде create_function() несовместимы с современными PHP. Это проблема окружения, а не конкретно WordPress 7.0. Проверьте php -l и логи.
• Конфликты JS/CSS. Несовместимые скрипты/стили темы или плагина могут дать белый экран или битые стили. Отключайте плагины по одному на staging.
• Серверная конфигурация и кэш. После апдейта админка может показывать старые стили из-за кэша Cloudflare/CDN или оптимизации. Сбросьте кэш и проверьте настройки кэширования/оптимизации только при наличии симптомов. Универсальный «Bypass для /wp-admin/*» нужен не всегда — зависит от конфигурации. См. Cloudflare ломает админку.
• Кастомные хуки и фильтры. Устаревшие или неверные использования хуков могут перестать работать. Проверьте кастомный код на использование актуальных хуков.

Откат — как вернуться безопасно

Откат ядра командой — не равноценен полноценному восстановлению сайта, особенно если база уже изменилась.

# восстановление файлов — распаковываем в папку WordPress, а не в корень /
tar -xzf ~/backup-2026-08-26.tgz -C /path/to
# восстановление БД (с потерей данных после бэкапа — см. предупреждение выше)
gunzip < ~/db-2026-08-26.sql.gz | mysql -u DB_USER -p DB_NAME

Пример downgrade ядра через WP-CLI используйте только как крайний случай и только с актуальной версией ветки, в которую откатываетесь, после проверки на тестовой копии:

wp core update --version=7.0.4 --force --path=/path/to/wordpress
# или, если цель — актуальная ветка 7.1.x, укажите её свежий выпуск

Если не уверены — восстанавливайте из файлового и базового бэкапов целиком и только после оценки потери данных.

Сопровождение и поддержка сайта

Исправлю ошибки WordPress, восстановлю сайт.

от 5.400 ₽/мес

Подробнее

Техническая оптимизация

Ускорю сайт, настрою кэш, устраню узкие места.

7.200

Подробнее