Чому Drupal потребує продуманої архітектури згоди

Сильні сторони Drupal і ризики щодо згоди походять з одного й того самого місця. Редакційна гнучкість платформи, доступ на основі ролей і структурована модель вмісту — саме це робить її вибором за замовчуванням для урядових порталів, університетських сайтів і глобальних корпоративних веб-ресурсів — тих самих сайтів, які найімовірніше будуть перевірені, які мають найрізноманітніші інвентарі тегів третіх сторін, накопичені за роки рекламних кампаній, і які мають найбільшу поверхню необов'язкових файлів cookie для контролю. Типовий сайт Drupal 10, який використовує аналітичний стек, піксель маркетингової автоматизації, вбудоване відео, веб-форму з reCAPTCHA і віджет для поширення в соцмережах, може виконувати понад дюжину різних необов'язкових операцій зберігання під час одного завантаження сторінки — часто через модулі, про налаштування яких початковий розробник уже не пам'ятає.

Кожна з цих операцій задіює окремі ворота згоди. Відповідно до Article 5(3) Директиви ePrivacy, кожен необов'язковий файл cookie або аналогічна операція зберігання та доступу вимагає попередньої, вільно наданої, конкретної, обґрунтованої та однозначної згоди в EEA, UK і будь-якій юрисдикції, що прийняла той самий стандарт. Відповідно до GDPR, поведінкові дані, які генерують ці операції зберігання, є обробкою персональних даних, оскільки комбінація ідентифікатора файлу cookie, IP-адреси та поведінкового сліду є достатньою для ідентифікації особи. Тому питання відповідності вимогам на сайті Drupal полягає не в тому, чи встановлювати банер — кожна відповідальна команда вже це зробила — а в тому, чи дійсно банер запобігає спрацьовуванню тегів до того, як користувач надав згоду, і чи рішення про згоду переживає шари кешування Drupal.

Ландшафт модулів: EU Cookie Compliance, Klaro та вендор-інтегровані варіанти

Модуль EU Cookie Compliance — contributed-модуль, що підтримується на Drupal.org під цією назвою — є історичним стандартом і найбільш широко розгорнутим варіантом. Він постачається з налаштовуваним банером, підтримує категорії, надає стан згоди JavaScript для прив'язки коду теми сайту та зберігає записи про згоду в базі даних Drupal. Сильні сторони — глибока інтеграція з системою дозволів і ролей Drupal, багатомовна підтримка через шар перекладу Drupal та можливість контролювати теги, відображені Drupal, за категоріями на рівні побудови сторінки. Слабкі сторони — UI банера відстає від стандартів дизайну, яких тепер очікують регулятори, мітки категорій за замовчуванням розпливчасті, а взаємодія модуля зі шарами кешування Drupal потребує явного налаштування.

Модуль Klaro Cookie & Consent Management — це новіший варіант, що інтегрує бібліотеку Klaro JavaScript — менеджер згоди з відкритим вихідним кодом із сучасним UI банера і детальними елементами керування на рівні кожного сервісу. Сильні сторони — якість UI, деталізація на рівні сервісу, а не категорії, та активна розробка upstream. Слабкі сторони — модуль тонший, ніж EU Cookie Compliance, вимагає більших зусиль у роботі з темами та переносить більше стану згоди на клієнт, де його необхідно узгоджувати з серверним рендерингом Drupal.

Вендор-інтегровані варіанти — Cookiebot, OneTrust, Usercentrics та подібні — доречні, коли сайт є частиною ресурсу, де вже стандартизований один із цих CMP на рівні організації. Вони зазвичай є найсильнішими варіантами щодо UI та журналу аудиту, але вводять платну залежність від третьої сторони та можуть вимагати Угоди про обробку даних, яка проходить через окремий процес закупівлі.

Пастка кешування, яка знищує більшість реалізацій згоди у Drupal

Ось проблема, яка топить інакше правильно налаштовані сайти Drupal: Internal Page Cache і Dynamic Page Cache, працюючи за призначенням, обслуговуватимуть кешований рендеринг сторінки відвідувачу, який ще не бачив банера, і кешований рендеринг може включати теги script або зовнішні ресурси, які банер мав би контролювати. Виправлення — не вимикати кешування, це знищує причину, через яку більшість підприємств обрали Drupal, — а рендерити теги з контролем згоди через шлях, який шари кешу поважають.

Шаблон заповнювача

Шаблон, що працює у виробництві, — це рендеринг кожного необов'язкового тегу як заповнювача в кешованому HTML — зазвичай тег <script type="text/plain"> з атрибутом категорії або кастомний елемент, який JavaScript модуля згоди активує лише на стороні клієнта після того, як відповідні ворота змінили стан. Сама сторінка Drupal кешується, оскільки заповнювач однаковий для кожного відвідувача; логіка активації знаходиться в JavaScript модуля згоди і виконується під час гідратації відносно стану згоди для конкретного відвідувача, збереженого в браузері. EU Cookie Compliance підтримує цей шаблон одразу після встановлення; для Klaro еквівалентом є механізм заміни скриптів на рівні сервісу, що надається upstream-бібліотекою.

Шари render-cache та varnish

Кеш рендерингу Drupal і будь-який upstream-кеш Varnish або CDN повинні бути налаштовані на варіювання відповідно до стану згоди лише тоді, коли стан згоди змінює відрендерений HTML — що з шаблоном заповнювача не відбувається. Сам банер рендериться як окремий кешований блок із контекстом, який розрізняє «банер потрібен» і «банер не потрібен», а решта сторінки рендериться ідентично незалежно від стану згоди. Це архітектурний вибір, який робить шари кешування Drupal сумісними з розгортанням за принципом «згода насамперед». Альтернатива — рендеринг сторінки по-різному залежно від стану згоди та вимкнення кешу для користувачів, які зробили вибір, — саме вона породжує поведінку «повільні сторінки після прийняття», що змушує користувачів відхиляти банери.

Шаблони інтеграції модуль за модулем

Робота з інтеграцією на сайті Drupal здебільшого полягає в підключенні стану згоди до модулів, що випускають необов'язкові файли cookie або зовнішні ресурси. Шаблон повторюється в екосистемі contributed-модулів.

• Модуль Google Analytics та модуль Google Tag Manager повинні бути налаштовані так, щоб рендерити свої теги як заповнювачі з контролем згоди, а категорія згоди має відображатися на ворота аналітики. Обидва модулі надають hook, до якого може підключитися модуль EU Cookie Compliance.
• Модуль Webform із reCAPTCHA — найпоширеніший непомітний витік: reCAPTCHA встановлює необов'язкові файли cookie під час завантаження навіть до того, як користувач надіслав форму. Виправлення — розмістити бібліотеку reCAPTCHA за відповідною функціональною або маркетинговою категорією або використати варіант invisible-v3, який відкладає записи cookie до моменту надсилання форми.
• Вбудовані відео модуля Media з YouTube, Vimeo або Brightcove повинні використовувати режим з підвищеним захистом конфіденційності або бути обгорнутими в заповнювач «клацніть, щоб завантажити», що відкладає запит третьої сторони до активації користувачем. Шаблон Lite YouTube Embed є еквівалентом, який прийняли кілька тем Drupal.
• Віджети для поширення в соцмережах від нативних вендорів — це шаблон 2010-х років, який слід замінити статичними посиланнями для поширення, що взагалі не завантажують JavaScript третіх сторін. Якщо віджет вендора має залишитися, він розміщується за маркетинговими воротами.
• Drupal Commerce та будь-які файли cookie, пов'язані з кошиком покупок, є суворо необхідними і не вимагають згоди, але ідентифікатори програм лояльності, файли cookie рушія рекомендацій і події кошика, пов'язані з аналітикою, потребують відповідних воріт.

Валідація, журнал аудиту та багатомовний аспект

Крок валідації на сайті Drupal — це та сама послідовність чотирьох перевірок, що застосовується скрізь: відвідування без дії повинно давати нуль необов'язкових файлів cookie, відвідування з відмовою повинно зберігати цей стан, відвідування з прийняттям повинно давати лише дозволені теги, а відкликання повинно негайно зупинити подальше спрацьовування тегів і видалити відповідні файли cookie. Зокрема в Drupal ця валідація повинна проводитися з «гарячим» кешем сторінки — без його обходу — щоб підтвердити, що шаблон заповнювача працює правильно за реалістичних умов трафіку.

Журнал аудиту в Drupal використовує переваги платформи. EU Cookie Compliance зберігає записи про згоду в базі даних із мітками часу та станом категорій; Klaro можна налаштувати на те саме за допомогою hook на стороні Drupal. Обидва шляхи дають змогу отримати запитуваний журнал згоди, на основі якого можна відповісти на запит регулятора. Багатомовний аспект також важливий: шар перекладу Drupal поширюється на текст банера згоди, тому повідомлення про конфіденційність та мітки категорій повинні бути перекладені для кожної мови, якою обслуговує сайт, а журнал згоди повинен фіксувати, яку мовну версію користувач фактично бачив. Захищене розгортання Drupal у 2026 році — це те, де вибір модуля, шаблон кешування, інтеграції для кожного модуля та багатомовний журнал аудиту розглядалися разом — і де вибір Drupal як базової платформи перетворився з відповідальності кешування на перевагу щодо згоди.