Защо Drupal се нуждае от преднамерена архитектура за съгласие

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

Всяка от тези операции задейства отделна порта за съгласие. Съгласно Article 5(3) от ePrivacy Directive, всяка незадължителна бисквитка или аналогична операция за съхранение и достъп изисква предварително, свободно дадено, конкретно, информирано и недвусмислено съгласие в EEA, UK и всяка юрисдикция, приела същия стандарт. Съгласно GDPR, поведенческите данни, генерирани от тези операции за съхранение, са обработка на лични данни, тъй като комбинацията от идентификатор на бисквитка, IP адрес и поведенческа следа е достатъчна за идентифициране на отделен индивид. Въпросът за съответствие на сайт на Drupal следователно не е дали да се инсталира банер — всеки отговорен екип вече го е направил — а дали банерът действително предотвратява изстрелването на таговете преди потребителят да е дал съгласие и дали решението за съгласие оцелява в слоевете за кеширане на Drupal.

Пейзажът на модулите: EU Cookie Compliance, Klaro и вендорски интегрираните опции

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

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

Вендорски интегрираните опции — Cookiebot, OneTrust, Usercentrics и подобни — са подходящи, когато сайтът е част от имот, вече стандартизиран върху един от тези CMP на организационно ниво. Те обикновено са най-силните опции по отношение на UI и одитна следа, но въвеждат платена зависимост от трета страна и може да изискват Data Processing Agreement, преминаващо през отделна процедура за обществени поръчки.

Капанът за кеширане, който провалва повечето Drupal имплементации за съгласие

Това е проблемът, който потапя иначе правилно конфигурираните сайтове на Drupal: Internal Page Cache и Dynamic Page Cache, работещи по предназначение, ще сервират кеширано рендериране на страница на посетител, все още невидял банера, а кешираното рендериране може да включва тагове за скрипт или външни ресурси, които банерът трябва да контролира. Поправката не е да се деактивира кеширането — това унищожава причината, поради която повечето предприятия са избрали Drupal — а да се рендерират таговете, контролирани от съгласие, чрез път, зачитан от кеширащите слоеве.

Моделът с заместващи елементи

Моделът, работещ в производство, е да се рендерира всеки незадължителен таг като заместващ елемент в кешираната HTML — обикновено таг <script type="text/plain"> с атрибут за категория, или персонализиран елемент, активиран само от страна на клиента от JavaScript на модула за съгласие след обръщане на съответната порта. Самата страница на Drupal е кешируема, защото заместващият елемент е еднакъв за всеки посетител; логиката за активиране е в JavaScript на модула за съгласие и се изпълнява при хидратация срещу статуса на съгласие на конкретния посетител, съхранен в браузъра. EU Cookie Compliance поддържа този модел от кутията; за Klaro еквивалентът е механизмът за замяна на скрипт за всяка услуга, предоставен от библиотеката нагоре по веригата.

Кешът за рендериране и слоевете на Varnish

Кешът за рендериране на Drupal и всеки Varnish или CDN кеш нагоре по веригата трябва да бъдат конфигурирани да варират по статус на съгласие само когато статусът на съгласие променя рендерираната HTML — което при модела с заместващи елементи не се случва. Самият банер се рендерира като отделен кешируем блок с контекст, разграничаващ "нужен банер" от "ненужен банер", а останалата част от страницата се рендерира идентично независимо от статуса на съгласие. Това е архитектурният избор, правещ кеширащите слоеве на Drupal съвместими с разгръщане на първо място за съгласие. Алтернативата — рендериране на страницата по различен начин за всеки статус на съгласие и деактивиране на кеша за потребители, направили избор — е тази, която произвежда поведението на бавни-страници-след-приемане, карайки потребителите да отхвърлят банерите.

Модели на интеграция модул по модул

Работата по интеграция на сайт на Drupal се свежда главно до свързване на статуса на съгласие с модулите, излъчващи незадължителни бисквитки или външни ресурси. Моделът се повтаря в екосистемата от допринесени модули.

• Google Analytics module и Google Tag Manager module трябва да бъдат конфигурирани да рендерират таговете си като контролирани от съгласие заместващи елементи, с категорията на съгласие, съотнесена към портата за анализи. И двата модула излагат кука, към която модулът EU Cookie Compliance може да се закачи.
• Webform module with reCAPTCHA е най-честото фино изтичане: reCAPTCHA задава незадължителни бисквитки при зареждане дори преди потребителят да е подал формуляра. Поправката е да се постави библиотеката reCAPTCHA зад съответната функционална или маркетингова категория, или да се използва вариантът invisible-v3, отлагащ записите на бисквитки до подаване на формуляра.
• Вградените видеоклипове на Media module от YouTube, Vimeo или Brightcove трябва да използват режима за подобрена поверителност или да бъдат обвити в заместващ елемент за кликване за зареждане, отлагащ заявката от трета страна до активирането й от потребителя. Моделът Lite YouTube Embed е еквивалентът, приет от няколко теми на Drupal.
• Приспособленията за споделяне в социалните мрежи от местни доставчици са модел от 2010-те, който трябва да бъде заменен в полза на статични линкове за споделяне, изобщо не зареждащи JavaScript от трети страни. Ако приспособлението на доставчика трябва да остане, то стои зад маркетинговата порта.
• Бисквитките на Drupal Commerce и всякакви свързани с количката са строго необходими и не изискват съгласие, но идентификаторите на програми за лоялност, бисквитките на препоръчителния двигател и аналитично свързаните събития на количката изискват подходящата порта.

Валидиране, одитна следа и многоезичният аспект

Стъпката на валидиране на сайт на Drupal е същата четири-проверъчна последователност, приложима навсякъде: посещение без действие трябва да произведе нула незадължителни бисквитки, посещение с отказ трябва да запази това състояние, посещение с приемане трябва да произведе само одобрените тагове, а оттеглянето трябва незабавно да спре по-нататъшното изстрелване на тагове и да изтрие съответните бисквитки. Конкретно за Drupal, това валидиране трябва да се направи с топъл кеш на страницата — не заобиколен — за да се потвърди, че моделът с заместващи елементи работи правилно при реалистични условия на трафик.

Одитната следа в Drupal се възползва от силните страни на платформата. EU Cookie Compliance съхранява записи за съгласие в базата данни с времеви маркери и статус на категория; Klaro може да бъде конфигуриран да прави същото чрез кука от страна на Drupal. И двата пътя произвеждат записваем журнал за съгласие, срещу който може да бъде отговорено на заявка на регулатор. Многоезичният аспект също е важен: слоят за превод на Drupal се простира до текста на банера за съгласие, така че известието за поверителност и категорийните етикети трябва да бъдат преведени за всеки език, обслужван от сайта, а журналът за съгласие трябва да записва коя езикова версия потребителят действително е видял. Защитимото разгръщане на Drupal през 2026 г. е такова, при което изборът на модул, моделът на кеширане, интеграциите за всеки модул и многоезичната одитна следа са разгледани заедно — и където изборът на Drupal като основна платформа е превърнат от кешираща отговорност в предимство за съгласие.