Куда движутся CMS в 2026 году?

Поскольку я слежу за разными CMS, то заметил несколько основных тенденций в их развитии. Делюсь мыслями на этот счёт.

Усложнение админ-панели

Пожалуй — это основной тренд для большинства CMS. Я говорю не только о Flat-File System, но и о DB-driven (аля-WordPress).

Тут движение в двух направлениях. Первое — это смена «движка» самой админки на что-то сложное в виде Vue/React и переход на отдельное API, которое подразумевает тотальное использование AJAX.

То есть внутреннее устройство админки теперь усложнено за счёт компонентов js-фреймворков, поскольку нужен ещё и сервер Node.js для компиляции в итоговый код.

Нативный HTML/CSS/JS/PHP уже «не кошерно».

Это нужно только владельцу CMS, который показывает, что его система может работать как «Headless», то есть через API.

Я думаю, что это глупость, поскольку работа через API только усложняет код админки, а работа через AJAX (я имею ввиду js-фреймворки) требует разделение front (сторонний UI) от back на PHP. Вместо того, чтобы всё делать на PHP, вводится новый («жирный»!) слой абстракции.

Что касается концепции Headless, то она рассчитана на крупные конторы, готовые платить много денег за обслуживание и сторонние серверы. Это очень специализированная задача, но какая при этом используется CMS, большой роли уже не играет.

Второе направление — это смена простого текстового редактора на «блочный». Большинство систем изначально имеют визуальный редактор уровня TinyMCE, но теперь предлагается не просто редактировать текст «как в Ворде», а собирать тексты из неких «блоков». Это что-то вроде Gutenberg в WordPress, на который только ленивый не плевался.

Сложность здесь в том, что «блочный редактор» — это борьба с качественным html-кодом. В таком редакторе невозможно получить чистый код, не говоря уже о том, насколько он «тяжел» для браузера. Парадокс в том, что всё это легко заменяется буквально парой строк на обычном HTML.

Зачем это делается?

Основная причина — это желание владельца CMS заявить «мы modern no-code!». Обычному пользователю в массе своей это всё не нужно, у него просто нет таких задач. Но для владельца CMS это движение в сторону «больших» систем, рассчитанных на большие деньги (как в WordPress, Drupal и т.п. с корпоративными клиентами). Либо движение в сторону Wix, Webflow и т.п. — визуальных построителей сайтов. Здесь они могут выступать как конкуренты в виде услуги «Page Builder».

Есть мнение, что это удобно для редактора (юзера) сайта, но на самом деле это не так. По какой-то неведомой причине, теперь писать код на чистом HTML стало моветоном. Лично я не могу понять — это пользователи настолько отупели, или это разработчики сайтов свернули в «темный лес» и никак не могут оттуда выбраться? Не позволять использовать HTML для создания web-страниц — что может быть абсурднее?

«Интеграция» с AI

Тут скорее не интеграция как таковая, а создание механизмов для доступа ИИ к данным сайта. Поэтому некоторые системы создают API под протокол MCP.

Здесь двоякая ситуация. Если система на базе данных, то у стороннего юзера нет никаких возможностей получить данные сайта и ими управлять вне админки. Поэтому такой API вроде как позволяет решить ту задачу. Когда-то мы это уже проходили через блог-клиенты, только теперь другой формат данных. Сути это не меняет, поскольку решает те же самые задачи.

Но если это flat-file, то наличие API для AI выглядит странно, поскольку данные уже представляют текстовые файлы, что и есть лучший формат для ИИ. Зачем ему ещё и прослойка в виде API, загадка.

Ну и кроме того, разработчики CMS, видимо, решили, что их пользователи готовы платить по 200 баксов в месяц ИИ за то, чтобы автоматизировать создание текстовых файлов (записи сайта).

Лично я вообще не представляю себе задач, которые может решить AI-агент для flat-file CMS. Поскольку это файлы как есть, то агент здесь как собаке пятая нога.

Сужение своих «рамок»

Это тоже заметная тенденция в развитии систем. Например некоторые системы построены на Laravel или используют компоненты Symfony. Для многих систем наличие Composer обязательное условие. Есть даже те, которые требуют Docker!

Многие системы переходят на Tailwind CSS, что катастрофически влияет на скорость загрузки (css-файл огромный). Либо вводят условие использования того же Vue.

Некоторые системы усиливают привязку к внутреннему устройству шаблонов: у них жесткие каркасы, блоки, типы и т.п.

В целом же большинство CMS сужают свободу выбора для программистов, поскольку требуют не просто написания кода на PHP и HTML, а настаивают на использовании своих жестких рамок. Например Twig — часто встречается как шаблонизатор, но по факту это настолько «тупая система», что просто удивительно, как ей до сих пор кто-то пользуется.

Другой пример рамок — жестка завязка на формат текста записей. Тут повсеместное помешательство от Markdown и YAML, хотя это страшно убогие форматы данных. То есть опять же складывается впечатление, что текст на HTML для многих уже звучит как проклятие.

Это странно, но системы всё дальше сужаются в своих рамках, вместо того, чтобы расширяться за счёт других сторонних разработок.

Скажем нужно вывести текущую дату и время в тексте записи (вот так 2026-07-03 15-08-30). Если у вас есть сайт, попробуйте это сделать. Почти все системы потребуют написания отдельного плагина или шорткода, то есть что-то внешнее, зависящее от рамок системы. Напрямую выполнить код не сможет (почти) ни одна система.

По факту это примитивное <?= date('Y-m-d H-i-s') ?>

Парадокс в том, что CMS написана на PHP, но пользователю сайта запрещено им пользоваться. То есть юзера просто лишают базовых возможностей для решения большинства задач. Вместо этого предлагается изучать документацию, чтобы понять как именно можно интегрировать php-код внутрь текстовой записи.

Итого

Я изучаю другие системы, потому что мне интересно сравнивать их возможности с Albireo CMS. Но в большинстве случаев я сталкиваюсь не сколько с возможностями и «фишками» систем, сколько с изначальной ограниченностью (обычно искусственной) и последующими способами её преодоления.

Когда я встречаю очередную новость о том, как в какой-то системе внедрили очередной «blueprint», то меня всё чаще посещает мысль сделать лозунгом моей системы: «Albireo CMS — система не для дураков». 😂