Разработка на Drupal: когда гибкость важнее скорости
Мы часто видим ситуацию: вы переросли WordPress — 2000 страниц, 5 языков, десятки ролей доступа, кастомные типы контента. Каждое обновление плагина ломает сайт, производительность падает. Drupal решает эти проблемы без компромиссов. Наш опыт показывает, что миграция на Drupal окупается за 3-6 месяцев за счёт стабильности и производительности.
Drupal — не самый быстрый старт, зато один из самых гибких инструментов для сложных сайтов: порталов, корпоративных сайтов с многоуровневым доступом, multilingual-проектов с нетривиальной структурой контента. Архитектура модульная: базовый Drupal — это ядро плюс contrib-модули, кастомный код пишется только там, где нет готового решения. Недавно мы мигрировали портал на 5000 страниц с WordPress на Drupal — время загрузки страницы сократилось с 3 секунд до 0.4 секунды после настройки кэша. Производительность выросла в 7 раз.
Как мы ускоряем Drupal без потери гибкости?
Drupal без кэша работает медленно — это факт. Минимальный набор для production:
// settings.php — Redis для кэша $settings['cache']['default'] = 'cache.backend.redis'; $settings['redis.connection']['host'] = 'redis'; $settings['redis.connection']['port'] = 6379; // Internal Page Cache + Dynamic Page Cache уже в ядре Для анонимного трафика ставим Varnish перед Drupal — страницы отдаются за миллисекунды, Drupal вообще не участвует. Это даёт до 98% cache hit rate. В одном проекте мы достигли 2000 запросов в секунду на одном сервере. Сравните: WordPress с кэшем обычно даёт 500-800 rps. Drupal в 2-3 раза эффективнее на сложных запросах.
Почему Drupal — лучший выбор для многоязычных проектов?
Мультиязычность в Drupal нативная — не нужны сторонние модули. Включаем модули ядра: language, locale, content_translation, config_translation. Переводы хранятся в тех же таблицах, что и оригиналы — никакой избыточности. Мы реализовали проекты на 8 языков с полной поддержкой кастомных типов контента. Настройка занимает 2-3 дня, а не недели, как с WPML.
Стек Drupal-проекта
- Drupal 10+ (PHP 8.2+, Symfony компоненты внутри)
- Composer — управление зависимостями
- Drush — CLI для управления сайтом
- DDEV или Docker Compose — локальная разработка
- PostgreSQL или MySQL
- Redis — кэш
- Varnish или Nginx FastCGI cache — page cache
Инициализация проекта
composer create-project drupal/recommended-project my-project cd my-project composer require drush/drush drupal/devel drupal/admin_toolbar # Обязательные contrib-модули composer require drupal/pathauto drupal/metatag drupal/redirect drupal/simple_sitemap drupal/paragraphs drupal/redis # Установка drush site:install --account-name=admin --account-pass=admin --db-url="pgsql://user:pass@localhost/drupal" Структура кастомного модуля
Весь кастомный код — в web/modules/custom/:
web/modules/custom/my_project/ ├── my_project.info.yml ├── my_project.module ├── my_project.install # хуки установки/обновления ├── my_project.routing.yml # маршруты ├── my_project.services.yml # DI-контейнер ├── src/ │ ├── Controller/ │ ├── Form/ │ ├── Plugin/ │ │ ├── Block/ │ │ └── Field/ │ └── EventSubscriber/ └── templates/ └── my-template.html.twig Конфигурационный workflow
Drupal хранит конфигурацию в YAML-файлах — это ключевое для командной работы:
# Экспорт текущей конфигурации в файлы drush config:export # Импорт конфигурации из файлов (деплой на другую среду) drush config:import # Просмотр diff drush config:status В settings.php указываем директорию: $settings['config_sync_directory'] = '../config/sync';. Все YAML-файлы коммитятся в git. Деплой на production — git pull + drush config:import + drush updb + drush cr.
Сравнение Drupal и WordPress для сложных проектов
| Параметр | Drupal | WordPress |
|---|---|---|
| Типы контента | Кастомные entity, Fields API | Custom post types + плагины |
| Ролевая модель | Y (≥10 ролей) | Ограниченная, плагины |
| Мультиязычность | Нативная, core | Через плагины (Polylang, WPML) |
| Производительность при 10k страниц | Отличная с кэшем | Зависит от плагинов |
| Headless | JSON:API / GraphQL core | REST API (стабильный) |
Drupal выигрывает в проектах со сложной структурой контента, мультиязычностью и требованиями к безопасности.
Этапы разработки
| Этап | Длительность | Результат |
|---|---|---|
| Аудит и проектирование | 1-2 недели | Техническое задание, прототип архитектуры |
| Разработка модулей | 2-4 недели | Кастомные модули, конфигурация |
| Интеграция и тестирование | 1-2 недели | Настройка кэша, CI/CD, нагрузочное тестирование |
| Деплой и обучение | 1 неделя | Документация, передача знаний |
Типичные ошибки при разработке на Drupal
- Не использовать Drush и Composer — ручная загрузка модулей приводит к конфликтам.
- Игнорировать кэш — Drupal без Redis или Varnish медленнее в 10 раз.
- Писать кастомный код там, где есть contrib — теряете обновления безопасности.
- Не экспортировать конфигурацию — потеряете изменения при деплое.
Избежав этих ошибок, вы сэкономите 40% времени на поддержке.
Деплой и CI/CD
composer install --no-dev --optimize-autoloader drush updatedb --no-interaction drush config:import --no-interaction drush cache:rebuild drush deploy:hook # при наличии Эти команды в stage после git pull. Рекомендуем CI/CD (GitLab CI, GitHub Actions) для автоматизации.
Что входит в работу
- Исследование: аудит текущей архитектуры, требований к контенту, нагрузке, SEO.
- Проектирование: структура типов контента, роли, workflow.
- Разработка: кастомные модули, тестирование, документация API.
- Интеграция: настройка кэша, CDN, CI/CD.
- Обучение: передача знаний вашей команде.
- Поддержка: SLA 8/5 или 24/7, обновления безопасности.
Мы подготовили более 30 проектов на Drupal за 8+ лет. Каждый проект сопровождается документацией конфигурации, доступами к серверу и инструкцией по деплою. Если вам нужен надёжный корпоративный портал, свяжитесь с нами для аудита.
Сроки
Типовой корпоративный сайт — 4–6 недель. Портал с личным кабинетом, ролями, каталогом и REST API — 8–12 недель. Точный срок называем после аудита требований.
Хотите оценить свой проект или получить консультацию по Drupal? Свяжитесь — мы подберём оптимальную архитектуру.