WordPress переводит разработку на Node.js 24 и npm 11: что нужно обновить

9 сентября 2026 года команда WordPress Core сообщила об обновлении требований к среде разработки. Для актуальной разработки WordPress теперь используются Node.js 24.x с минимальной версией 24.18.0 и npm 11.x с минимальной версией 11.16.0.

Важно правильно понять смысл изменения: это не новое требование к PHP-хостингу обычного WordPress-сайта. Node.js здесь нужен разработчикам для сборки, тестов, пакетов JavaScript и инструментов проекта. Если вы просто администрируете готовый сайт, обновлять сервер до Node.js 24 только из-за этой новости не требуется.

Какие версии теперь нужны

По официальному сообщению Make WordPress Core актуальные требования выглядят так:

• Node.js — ветка 24.x, минимум 24.18.0;
• npm — ветка 11.x, минимум 11.16.0.

Изменение действует для trunk в основных репозиториях, ветки wp/7.1 в Gutenberg и ветки 7.1 в wordpress-develop. Более старые ветки пока сохраняют прежние минимумы: Node.js >=20.10.0 и npm >=10.2.3.

Что нужно сделать разработчику

Первое действие — проверить локальные версии:

node -v
npm -v

Если проект использует nvm, команда WordPress рекомендует внутри checkout выполнить:

nvm install
nvm use
npm ci

Файл .nvmrc временно закрепляет линию 24.18, чтобы разработчики автоматически подхватывали совместимую версию. Аналогичный подход можно использовать через fnm или другой менеджер версий.

Почему недостаточно обновить только локальный Node.js

Версия Node.js часто закреплена сразу в нескольких местах: GitHub Actions, Dockerfile, devcontainer, CI-образах, локальных скриптах и документации проекта. Если обновить только рабочую машину, локальная сборка может проходить, а pull request — падать.

Поэтому после перехода стоит проверить конфигурацию CI, особенно если один pipeline обслуживает несколько веток WordPress или плагина. Актуальная ветка может требовать Node.js 24, тогда как старые поддерживаемые ветки ещё рассчитаны на Node.js 20.

Первый переход уже выявил проблемы CI

Официальная заметка отдельно описывает показательный эпизод: обновление сначала попало в Gutenberg, затем было откатано из-за неожиданных сбоев Actions для старых нумерованных веток wordpress-develop. После исправлений изменения были повторно объединены.

Это хороший пример того, почему обновление toolchain нужно проверять не только на основной ветке. Если проект поддерживает несколько релизных линий, одна версия Node.js в глобальном workflow может оказаться неправильной для части матрицы.

Что даёт переход на Node.js 24

Команда WordPress связывает обновление не только с завершением жизненного цикла Node.js 20. Новая версия открывает более современный набор инструментов: улучшенную совместимость ES modules/CommonJS, встроенные API, возможность запускать TypeScript через type stripping и обновлять зависимости, которым уже недостаточно старых версий Node.js.

npm 11 также нужен для части новых защит цепочки поставок. Это особенно важно в больших JavaScript-проектах, где установка зависимостей является частью каждого локального запуска и CI.

Что проверить в собственном WordPress-проекте

Если вы разрабатываете тему, плагин или блоки Gutenberg, проверьте не только версию Node.js, но и весь путь сборки. Полезный минимум:

• зафиксировать поддерживаемые версии Node.js и npm в документации проекта;
• обновить CI и локальные менеджеры версий;
• пересобрать зависимости через lock-файл;
• прогнать линтеры, unit-тесты и production build;
• отдельно проверить старые релизные ветки, если они ещё поддерживаются.

Для клиентского сайта ситуация зависит от проекта. Если WordPress используется только как CMS, а сборка темы давно завершена, срочного действия может не быть. Если же сайт активно развивается и использует современный frontend toolchain, лучше синхронизировать локальную среду и CI заранее.

Это не означает, что WordPress теперь работает на Node.js

Самая частая ошибка в интерпретации подобных новостей — смешивать среду разработки и runtime сайта. WordPress по-прежнему является PHP-приложением. Node.js используется в разработке JavaScript-части, сборке Gutenberg и инструментах проекта.

Поэтому владельцу обычного сайта не нужно искать «Node.js 24 хостинг для WordPress». А разработчику, который работает с актуальным Core, Gutenberg или современными плагинами, наоборот, стоит обновить рабочую среду.

Что дальше

WordPress уже планирует следующий этап обновления toolchain после того, как Node.js 26 получит Active LTS. При этом старые ветки будут обновляться осторожнее: команда отдельно оценивает, где переход можно сделать без изменений пользовательского программного обеспечения.

Если проект давно не обновлял сборку, CI или зависимости, переход версии Node.js удобно совместить с технической ревизией. В A.S Groups можно заказать доработку WordPress, разработку плагинов и помощь WordPress-разработчика для конкретного проекта.

Вывод

Переход WordPress на Node.js 24 и npm 11 — изменение именно разработческой инфраструктуры. Главная практическая задача — синхронизировать локальное окружение, CI и ветки проекта, не ломая поддержку старых релизов. Для владельцев обычных сайтов это не новое серверное требование, а для разработчиков Core, Gutenberg и сложных WordPress-проектов — уже актуальная часть рабочего окружения.