Практичні поради з безпечного видалення модулів у Drupal 11
Після кількох років роботи з Drupal я можу сказати прямо: неправильне видалення модулів — одна з найчастіших причин нестабільності сайтів. Особливо це актуально для Drupal 10/11, де Composer і Configuration Management є обов’язковою частиною workflow.
У цьому дописі покажу базовий, але правильний підхід до видалення модулів без сюрпризів.
Чому видалення модулів — це не просто «Uninstall»?
Модуль у Drupal — це не лише код. Він може:
- створювати власні таблиці в базі даних;
- додавати конфігурацію;
- бути залежністю для інших модулів або тем;
- впливати на routing, permissions і cache.
Тому механічне видалення папки або composer remove без підготовки — прямий шлях до помилок.
Правильний порядок дій
1. Перевір залежності
Перед видаленням переконайся, що:
- модуль не використовується іншими модулями;
- немає конфігурації, яка від нього залежить.
У продакшені це критично.
2. Деінсталяція модуля
Спочатку деінсталюй модуль, а не видаляй код.
Через адмінку:
Адміністрування → Розширення → Uninstall
Або через CLI (якщо використовуєш Drush):
drush pm:uninstall module_nameЦей крок коректно прибирає конфігурацію і очищає стан системи.
3. Очищення кешу
Після деінсталяції — обов’язково:
drush crАбо через інтерфейс. Без цього Drupal може продовжувати тримати застарілі дані.
4. Видалення коду модуля
Лише тепер можна видаляти сам модуль:
Якщо модуль встановлений через Composer:
composer remove drupal/module_nameЯкщо кастомний — видалити папку з /modules/custom.
5. Перевірка сайту
Після цього:
- переглянь логи;
- перевір статус сторінок;
- відкрий
/admin/reports/status.
Це мінімум, який варто зробити навіть на невеликому сайті.
Кілька практичних застережень
- Не видаляй модулі напряму з файлової системи, якщо вони ще встановлені.
- Не ігноруй конфігурацію — вона часто є джерелом проблем після міграцій.
- На продакшені — тільки через staging і контрольовані деплої.
Висновок
Drupal стабільний тоді, коли з ним працюють дисципліновано. Видалення модулів — дрібниця лише на перший погляд. Насправді це частина загальної культури підтримки проєкту.
Останні публікації
Пастка дешевої розробки. Чому економія на старті може коштувати значно дорожче за рік?
Що таке технічний борг та чому дешевий сайт коштує дорожче за рік? Дізнайтеся, чим загрожує економія на розробці та як створити надійну архітектуру.
Чому сучасний Drupal досі недооцінюють
Розрив між репутацією та реальністю Drupal. Чому стереотипи про CMS застаріли, як змінилася розробка на Drupal 11 та до чого тут штучний інтелект?
Запуск нового бренду: чому шаблонні рішення та конструктори — це пастка на старті
Чому конструктори та шаблонні сайти — це пастка для нового бренду? Розбираємо переваги Drupal 11 перед WordPress та Shopify для унікальних бізнес-проєктів.