Поддержка сайта на Drupal в Москве

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

Мы не обновляем всё одной кнопкой. Для Drupal это смертельно опасно.

Наш процесс обновления:

• Создаём полную резервную копию сайта — базу данных, все файлы, конфигурацию.
• Разворачиваем точную копию на изолированном тестовом сервере.
• Обновляем Composer-зависимости, ядро Drupal, потом все установленные модули.
• Проверяем каждый критический маршрут — авторизацию, админку, Views, API, формы.
• Исправляем конфликты версий и несовместимости до выхода на боевой сервер.
• Переносим изменения на живой сайт только после успешного прохождения всех тестов.

Вы даже не замечаете этого процесса. Сайт просто остаётся актуальным, защищённым и стабильным. Никаких внезапных белых экранов после очередного composer update.

В Drupal контент управляется через типы материалов, поля и таксономию. Это мощно, но сложно для обычного менеджера. Новичок путается, где создать статью, а где — товар. Заполняет не те поля, забывает про обязательные характеристики, ошибается в привязке к категориям, а значит тратит 20 минут на одну карточку вместо пяти.

Мы забираем эту рутину на себя, чтобы сотрудники компании занимались продажами и клиентами, а не изучением структуры Drupal.

Что регулярно обновляем в рамках тарифа:

• Карточки товаров и услуг — цены, остатки, характеристики, изображения, SEO.
• Типы материалов — статьи, новости, портфолио, отзывы, кейсы.
• Таксономию — категории, теги, рубрики, иерархические словари.
• Поля всех типов — текстовые, числовые, файловые, ссылочные, медиа.
• Представления Views — настройка фильтров, сортировок, форматов вывода.
• Меню и навигацию — пункты, вложенность, привязка к материалам.

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

Сотрудники каждый день работают с сайтом, рано или поздно что-то идёт не так. Редактор случайно удалил тип материала — пропали все товары или маркетолог поменял настройки Views — перестала работать выдача категории. Администратор добавил нового пользователя с неверными правами — открыл доступ к чужим данным.

Техническая поддержка сайта Drupal — это не про аварии. Это про ежедневное спокойствие вашей команды.

Что входит в пакет:

• Восстановление доступа в админку при утере пароля или блокировке.
• Настройка любых модулей — Views, Rules, Panels, Display Suite, Pathauto.
• Исправление слетевшей вёрстки после неудачных правок шаблона.
• Добавление новых пользователей с точной настройкой ролей и прав доступа.
• Решение мелких проблем без сложной разработки — формы не отправляются, изображения не грузятся, редиректы работают криво.

Вы не ищете фрилансера под каждую мелочь, не торгуетесь за 15 минут работы и не ждёте, когда у специалиста появится окно. Просто пишете в мессенджер — разработчики DIUS решают.

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

Мы не ждём, пока вы проснётесь и сообщите о проблеме. Роботы проверяют доступность круглосуточно.

Что именно проверяем каждые пять минут из разных регионов:

• Доступность сайта по HTTP и HTTPS — открывается ли главная страница.
• Скорость ответа сервера — если время отклика выросло, получаем сигнал.
• Работу админки Drupal — авторизацию, загрузку списка материалов, открытие редактора.
• Ключевые сценарии — отправка форм, добавление товара в корзину, оформление заказа.
• Доступность API и внешних интеграций — выгрузка в «1С», отправка лидов в CRM, работа платёжного шлюза.

При первом же отклонении сигнал летит дежурному инженеру. Мы начинаем разбираться с проблемой до того, как первый клиент напишет в поддержку.

Drupal хранит настройки в конфигурационных YAML-файлах, контент — в базе данных, файлы — в папке sites/default/files. Потеряли одно или другое — сайт не восстановить полностью. Обычные бэкапы «всё подряд с хостинга» не работают: файлы конфигурации оказываются старыми, база — новой, сайт падает с ошибками.

Мы подходим к бэкапам системно. База данных, файлы ядра, все модули, конфигурация, пользовательские файлы — всё сохраняется отдельно и в одной связке в рамках поддержки сайтов Друпал.

Как организовано хранение:

• Ежедневные автоматические копии создаются без пропусков в одно и то же время.
• Копии уходят на два независимых хранилища — на отдельный сервер и в удалённое облако.
• Срок хранения — 30 дней, а этого достаточно, чтобы откатиться к любой версии сайта.
• Регулярно проверяем целостность каждого бэкапа выборочным восстановлением.
• Шифруем все копии перед выгрузкой — доступ есть только у вас и у нас.

Главная боль Drupal-проектов — архитектурная сложность, так как система генерирует десятки запросов к базе данных на одной странице. Представления Views без кеша убивают производительность, а модули навешивают друг на друга хуки. В результате страница грузится 5–8 секунд, хотя сервер мощный.

Мы ищем такие места системно — смотрим медленные логи MySQL, профилируем запросы с помощью Devel, проверяем каждый модуль и представление.

Что исследуем в первую очередь:

• Запросы к базе данных — сколько их на странице, какие повторяются, можно ли закешировать результат.
• Настройки кеширования Drupal — включён ли внутренний кеш, работает ли Redis для кеша и сессий.
• Представления Views — не делают ли они лишних подзапросов, правильно ли настроена фильтрация.
• Индексы таблиц — без них Drupal тормозит на каталогах с тысячами материалов.
• Медиафайлы — загружаются ли в оригинальном размере, нужны ли пресеты, стоит ли подключить WebP.
• Настройки PHP и веб-сервера — memory_limit, max_execution_time, opcache, worker'ы.

После диагностики применяем решения, оптимизируем запросы, включаем Redis или Memcached, настраиваем композитный кеш страниц. Также подключаем CDN и ленивую загрузку, при этом результат замеряем до и после. Сайт начинает летать даже под высокой нагрузкой.

Drupal не имеет готового модуля на каждый случай жизни. Вы не найдёте в админке кнопку «Подключить „1С“» или «Отправить заказ в AmoCRM». Каждый обмен данными — это отдельная задача на уровне кода. Готовые решения часто платные, кривые или давно не обновлялись.

У нас есть библиотека собственных модулей и наработок под Drupal. Мы не пишем с нуля там, где уже есть работающее решение.

Примеры из реальных проектов:

• Интернет-магазин на Drupal Commerce. Нужно выгружать заказы в самописную CRM на PHP. Написали модуль, который ловит событие оформления заказа и отправляет данные через REST API. CRM видит заказ через 10 секунд. Менеджеры перестали вбивать данные руками по 20 минут на каждый заказ.
• Корпоративный сайт завода. Требовался импорт характеристик продукции из Excel-файлов каждую неделю. Сделали админский модуль с загрузкой файла и автоматическим обновлением полей материалов. Технологи работают как привыкли, сайт всегда актуальный.
• Медиапортал с десятком авторов. Понадобилась интеграция с внешней системой переводов. Через вебхуки выгружаем новые материалы, забираем готовые переводы, автоматически обновляем поля. Редакторы не тратят время на ручной копипаст.

Новая доработка не ломает старую логику, так как мы пишем отдельные модули с собственными хуками и сервисами. Ядро Drupal остаётся нетронутым, а при выходе новой версии вы спокойно обновляете сайт. Наши модули продолжают работать.