Drupal в 2026 году: честный разбор CMS для бизнеса

Почему подрядчик, который 15 лет отговаривал от Drupal, теперь иногда его советует

Меня зовут Евгений Семёнов, я технический директор ITfresh — мы занимаемся IT-аутсорсингом компаний до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС и сопровождаем десятки сайтов клиентов на самых разных движках. Признаюсь честно: за полтора десятка лет мы ставили Drupal считанным клиентам. Не потому, что он плохой, а потому, что для типичного заказчика из нашего сегмента — клиники, юрфирмы, оптовики, сервисные компании — первый результат на Drupal появлялся через месяцы разработки, тогда как на WordPress тот же сайт-визитка собирался за неделю. Я это знал и отговаривал.

В январе 2025 года ситуация сдвинулась: вышел Drupal CMS — официальный дистрибутив, который ставится одной командой и сразу даёт готовые типовые сборки. Главный барьер «ничего не работает, пока не напишешь код» стал заметно ниже. В январе 2026-го вышла версия 2.0 с визуальным редактором страниц, а к лету — 2.1.3. Я лично прошёл этот путь на тестовом стенде и на двух клиентских проектах, и теперь у меня есть сценарии, где я рекомендую Drupal первым, а не последним.

Второй фактор — импортозамещение, но не в лозунговом смысле. Drupal распространяется под GPLv2+: код лежит у вас на сервере, лицензию никто не отзовёт, аккаунт не заблокируют по географическому признаку. Мы видели, как клиенты теряли доступ к SaaS-конструкторам из-за проблем с оплатой зарубежной картой, и как иностранный хостинг отключал аккаунты без предупреждения. Open-source движок на своём VPS в российском ЦОД от этого защищён полностью. Да, доля Drupal в рунете невелика — порядка 1,7% — но для корпоративного сайта с требованиями к правам доступа и безопасности это не аргумент против.

Архитектура на пальцах: типы контента, поля, таксономии и Views

Объясню на примере, который я использую на встречах с руководителями клиник. Допустим, у вас сеть из трёх филиалов и сорок врачей. На сайте нужна страница каждого врача, список всех кардиологов, список врачей филиала на Юго-Западной и блок «ещё три специалиста этого направления» внизу каждой карточки. В Drupal это решается так:

1. Тип контента «Врач». Вы создаёте его в админке и добавляете поля: ФИО, фото, специализация, стаж в годах, филиал, описание, стоимость приёма. Каждое поле типизировано — число остаётся числом, ссылка на филиал остаётся ссылкой, а не текстом, который менеджер может написать с опечаткой.
2. Таксономии «Направления» и «Филиалы». Это словари — управляемые справочники. Кардиология, неврология, педиатрия — термины словаря «Направления». Юго-Западная, Марьино, Химки — термины словаря «Филиалы». Врач ссылается на термины, а не дублирует текст.
3. Views. Встроенный конструктор выборок. Вы говорите: «покажи все материалы типа "Врач", у которых направление = кардиология и филиал = Юго-Западная, отсортируй по стажу, выведи сеткой по три в ряд». Ни строчки кода — только настройка через интерфейс. Та же Views собирает блок «похожие специалисты», RSS-ленту и таблицу для внутреннего отчёта.

Когда клиника открывает четвёртый филиал, вы добавляете один термин в словарь — и все списки, фильтры и меню подхватывают его автоматически. Когда маркетолог просит «страницу всех врачей со стажем больше 15 лет» — это пять минут в Views, а не задача для программиста. В этом и есть суть Drupal: он не про «страницы», он про структурированные данные и витрины над ними.

Чем это отличается от «страниц и записей» WordPress

В WordPress из коробки есть две сущности: запись и страница. Всё остальное — произвольные типы записей и произвольные поля — добавляется плагинами, причём у каждого плагина свой формат хранения и свой интерфейс. На практике это означает, что сайт клиники на WordPress живёт на связке из трёх-четырёх сторонних плагинов, каждый со своим циклом обновлений и своим автором, который может забросить проект. Работает — но это надстройка над движком, задуманным для блога. В Drupal поля, типы контента, словари и выборки — часть ядра, они обновляются вместе с ним и ведут себя единообразно.

Entity API: почему в Drupal всё устроено одинаково

Материалы (узлы), пользователи, термины таксономии, медиафайлы, комментарии, блоки — всё это в Drupal сущности одной модели. К любой из них можно добавить поля тем же способом, любую можно вывести через Views, к любой применяются одни и те же правила доступа. Практическое следствие: если вы научили контент-менеджера добавлять поле к типу «Врач», он так же добавит поле «Должность» к профилю пользователя или поле «Адрес» к термину «Филиал». Это экономит часы обучения и сильно упрощает интеграции — внешняя система через встроенный модуль JSON:API получает любую сущность в одном и том же формате.

Права доступа: то, за что в других системах платят отдельно

Я считаю систему прав Drupal сильнейшей среди бесплатных CMS, и это не комплимент, а констатация. Основа — роли и разрешения на уровне отдельных операций. Не «редактор может всё», а «роль "Помощник юриста" может создавать материалы типа "Публикация", редактировать только свои материалы этого типа, не может публиковать, не может удалять, видит неопубликованные материалы». Таких разрешений у свежей установки — несколько сотен, и каждый contrib-модуль добавляет свои.

Поверх этого — два модуля, которые закрывают типичные корпоративные требования. Content Moderation (в ядре) добавляет рабочий процесс: черновик → на проверке → опубликовано → в архиве, с правами на каждый переход. Group (contrib) делит сайт на группы с собственным членством и правами — подразделения, филиалы, практики, проекты.

Реальный пример из нашей практики: юридическая фирма с четырьмя практиками — корпоративное право, налоги, интеллектуальная собственность, трудовые споры. Требование руководства: помощники пишут аналитические заметки, но видят черновики только своей практики; руководитель практики правит и отправляет на утверждение; публикует только партнёр. В Drupal это собирается так:

• четыре группы в модуле Group — по одной на практику;
• роли внутри группы: «помощник» (создание черновиков, просмотр черновиков группы), «руководитель» (редактирование, переход «на утверждение»), «партнёр» (переход «опубликовано»);
• рабочий процесс Content Moderation с тремя состояниями;
• Views для партнёра: «всё, что ждёт моего утверждения по всем практикам».

На настройку у нас ушло порядка одного рабочего дня, без программирования. На WordPress такое же требование означало бы либо платный плагин управления правами, либо кастомный код, и в обоих случаях — набор костылей вокруг исходной модели «автор/редактор/администратор», которая про разделение по подразделениям ничего не знает. Я не говорю, что это невозможно; я говорю, что это будет хрупко и при очередном обновлении плагина может разъехаться.

Безопасность: собственная Security Team и почему Drupal любит госсектор

У Drupal есть выделенная команда безопасности, которая работает по расписанию: бюллетени (security advisories) публикуются по средам, для ядра — как правило, в третью среду месяца. Это важно практически: мы знаем, когда ждать патч, и планируем окно обновлений заранее, а не бежим тушить пожар в пятницу вечером. Бюллетени покрывают не только ядро, но и contrib-модули, прошедшие процедуру «security coverage» — у таких модулей на странице стоит соответствующая отметка, и мы ставим клиентам только их.

Отсюда же репутация Drupal в государственном и корпоративном секторе за рубежом: предсказуемый процесс, публичная история уязвимостей, понятная ответственность. Для наших клиентов это переводится в конкретное требование: сайт, где есть личный кабинет, персональные данные пациентов или закрытые документы для партнёров, должен стоять на движке с выстроенным процессом безопасности. Drupal этому требованию отвечает.

Ещё один момент, о котором стоит помнить: жизненный цикл версий. Drupal 7 закончил поддержку 5 января 2025 года, Drupal 10 заканчивает 9 декабря 2026 — после этой даты патчей безопасности для десятки не будет. Если вам достался сайт на одной из этих версий, планируйте переезд на 11-ю ветку уже сейчас: переход с 10 на 11 относительно мягкий, с 7 — это фактически миграция на новую платформу.

Что изменилось с автообновлениями в Drupal CMS

Исторически обновление Drupal — это работа через Composer на сервере: команда обновления зависимостей, затем drush updb для обновлений базы, затем drush cr для сброса кеша. Для контент-менеджера это недоступно, для подрядчика — рутина. В Drupal CMS заложена возможность автоматических обновлений патч-релизов ядра: сайт сам подтягивает безопасность в рамках той же минорной ветки. Мы на клиентских проектах включаем это с осторожностью — только на сборках, где есть автоматический бэкап перед обновлением и тестовая копия. Но сам факт важен: для небольшой компании без штатного девопса это снимает главный риск «забыли обновить».

Drupal CMS 2025–2026: что за дистрибутив и что в нём из коробки

Разберёмся в терминах, потому что путаница здесь постоянная. Drupal — это ядро, фреймворк для сборки сайтов; сейчас актуальная ветка 11.4, релиз 11.4.0 вышел 1 июля 2026 года, текущий патч — 11.4.5. Drupal CMS — это дистрибутив поверх ядра: то же самое ядро плюс подобранный набор модулей, готовая конфигурация и инструменты, чтобы сайт заработал без программиста. Ставится командой composer create-project drupal/cms вместо классического drupal/recommended-project.

Ключевые вехи дистрибутива:

• 1.0 — 15 января 2025. Первый выпуск: рецепты, набор SEO-модулей, медиатека, базовые AI-функции.
• 2.0.0 — 28 января 2026. Главное — Drupal Canvas, визуальный редактор страниц с перетаскиванием блоков и живым превью. К нему библиотека готовых компонентов Mercury и стартовые шаблоны сайта Byte и Starter. AI-функции стали опциональными: генерация лендинга из текстового запроса, чат-помощник в админке, автоматические alt-тексты картинок через OpenAI или Anthropic — подключаете свой ключ, если нужно.
• 2.1.0 и далее. Поддержка бесплатных и платных шаблонов сайтов (первый — Haven). Актуальный релиз на момент написания — 2.1.3, июнь 2026.

Самая важная для бизнеса механика — рецепты. Рецепт — это декларативный пакет «модули + конфигурация», который ставится одной командой поверх уже работающего сайта. Рецепт «Новости» создаёт тип контента, поля, словарь рубрик, выборку Views для ленты и блок анонсов, настраивает права. Рецепт «SEO» включает metatag, pathauto, redirect и simple_sitemap с разумными настройками. Рецепт «Формы» ставит webform и защиту от спама. Раньше всё это подрядчик собирал руками и выставлял в счёт как «настройка базовой структуры»; теперь это минуты.

Мой вывод по итогам полутора лет с дистрибутивом: тезис старых обзоров «Drupal — это для разработчиков» устарел процентов на шестьдесят. Типовой корпоративный сайт — структура, формы, SEO, медиатека, права — теперь собирается без кода. Оставшиеся сорок процентов никуда не делись: нестандартная интеграция, сложная тема оформления, миграция с чужой базы — это по-прежнему PHP-разработчик, знакомый с Drupal. Просто теперь он нужен на этапе, когда у вас уже есть работающий сайт, а не до него.

Заглядывая вперёд: на неделю 7 декабря 2026 запланированы сразу Drupal 12.0.0 и Drupal 11.5.0 (beta — сентябрь, rc — ноябрь). Ветка 11.5 станет LTS: линейка 11 будет поддерживаться до конца 2028 года. Для новых проектов это означает простое правило: ставим 11.4 сейчас, переходим на 11.5 после выхода и сидим на ней спокойно два года, а на 12-ю ветку смотрим без спешки.

Русская локализация: что переведено на самом деле

Вопрос «а он по-русски?» звучит на каждой встрече, отвечаю по пунктам. Официальная локализация живёт на localize.drupal.org — это общий сервер переводов, откуда сайт подтягивает языковые файлы автоматически. При установке вы выбираете русский язык (в консоли — drush site:install --locale=ru), и переводы ядра скачиваются в процессе. Для contrib-модулей то же самое: поставили модуль — при следующем обновлении переводов подтянулся его русский пакет, если он существует.

Что по факту переведено:

• Ядро — практически полностью. Интерфейс редактора, меню, настройки, сообщения об ошибках, формы — контент-менеджер без английского работать сможет.
• Популярные contrib-модули (webform, metatag, pathauto, redirect) — переведены в основном, но не на сто процентов: в глубоких настройках встречаются английские подписи.
• Новые компоненты Drupal CMS — Canvas, AI-помощники — переведены частично; интерфейс визуального редактора местами английский. Это ожидаемо для функционала, которому полгода.
• Админские термины — «Views», «Entity», «Display mode», «Recipe» — часто остаются как есть или переведены буквально. Мы в инструкциях для клиентов пишем их по-английски, чтобы не плодить разночтений.

Если перевод где-то не нравится, правится на месте: /admin/config/regional/translate — поиск строки, ввод своего варианта, сохранение. Мы так «доводим» интерфейс под терминологию клиента: «узел» превращается в «материал», «таксономия» — в «справочник».

Про сообщество. Русскоязычное сообщество Drupal заметно меньше, чем у WordPress или MODX: форум drupal.ru живёт, но ответов на конкретный вопрос на русском вы найдёте в разы меньше. Что это значит на практике: хороший Drupal-специалист читает документацию и issue-трекер drupal.org на английском, это обязательное требование при найме. Зато само сообщество — качественное: люди, которые работают с Drupal в 2026-м, как правило, пришли в него осознанно. При найме мы советуем смотреть не на «знает Drupal», а на «знает Composer, Views, Config Management и читает SA-бюллетени».

Честные минусы: где Drupal проиграет

Я обещал без маркетинга, поэтому — список того, что мы проговариваем клиенту до подписания.

• Разработчиков мало и они дороже. В Москве найти человека под WordPress или Битрикс — неделя; под Drupal — заметно дольше, и ставка выше. Если сайт живёт пять лет, вам дважды-трижды придётся менять подрядчика, и каждый раз это будет сложнее, чем с массовым движком.
• Хостинг-требования. Drupal 11 хочет PHP 8.3 и новее с набором расширений (PDO, mbstring, GD или ImageMagick, xml, json, curl, openssl), базу MySQL 8.0+ / MariaDB 10.6+ / PostgreSQL 16+ (или SQLite 3.45+ для мелких проектов), Composer 2 и доступ к консоли. Минимум памяти PHP — 64 МБ, на проде мы ставим 128–256 МБ. Дешёвый виртуальный хостинг без SSH — не вариант; это VPS от четырёх гигабайт памяти или корпоративный сервер.
• Кривая обучения контент-менеджера длиннее. Человек, который вчера вёл блог на WordPress, в Drupal первые две недели будет путаться в типах контента, режимах отображения и кеше. Мы закладываем два-три часа обучения и письменную инструкцию под конкретный сайт.
• Drupal для визитки — выброшенные деньги. Пять страниц и форма обратной связи не нуждаются ни в Entity API, ни в Content Moderation. Для этого есть WordPress, и там это дешевле на всех этапах. Про это у нас отдельный обзор WordPress в 2026 году.
• Интернет-магазин начального уровня. Коммерческие модули для Drupal существуют, но для магазина на пару сотен товаров с оплатой и доставкой по России быстрее и дешевле взять OpenCart или WooCommerce.

Сводная картина, как я её вижу для компаний нашего сегмента:

Во сколько обходится сопровождение: порядки, а не прайс

Точные цифры зависят от сайта, поэтому только порядки по нашему опыту. Регулярная часть — обновления ядра и модулей после каждого бюллетеня безопасности, проверка бэкапов, мониторинг — это порядка двух-четырёх часов инженера в месяц для типового корпоративного сайта. Это примерно вдвое больше, чем у аналогичного WordPress, потому что обновление идёт через Composer и тестовую копию, а не кнопкой в админке. Нерегулярная часть — минорное обновление ветки раз в полгода (например, 11.4 → 11.5) — ещё четыре-восемь часов с проверкой совместимости contrib-модулей. Плюс переход на мажорную версию раз в два-три года: по объёму это отдельный небольшой проект. Если эти цифры вас не пугают на фоне ценности, которую даёт структура и права, — читайте дальше. Если пугают — честно, берите WordPress.

Итог: матрица «брать / не брать» и что дальше в серии

Сведу всё сказанное в таблицу, по которой мы сами принимаем решение на первой встрече с клиентом.

Если в первых четырёх строках вы узнали себя — Drupal стоит того, чтобы потратить день на тестовый стенд. Поставьте composer create-project drupal/cms на любой VPS, примените пару рецептов, соберите один тип контента и одну выборку Views. Через день вы поймёте, ваше это или нет, куда точнее, чем по любому обзору, включая этот.

Что дальше в серии. Во второй статье — как мы разворачиваем Drupal 11 и Drupal CMS в продакшен: сервер, Composer, trusted_host_patterns в settings.php, Redis, бэкапы, перенос конфигурации через drush cex/drush cim. В третьей — миграция на Drupal с другого движка и интеграции с 1С, CRM и почтой через модули migrate и JSON:API. Если у вас уже есть сайт на Drupal 7 или 10, третья статья — самая срочная: декабрь 2026 ближе, чем кажется.

Нужно решить, подходит ли Drupal именно вашей компании, или взять существующий сайт на сопровождение с регламентом обновлений и бэкапов? Напишите в ITfresh: Telegram @ITfresh_Boss, телефон +7 903 729-62-41. Посмотрим на задачу вместе и скажем честно — брать или не брать.