Знаете, как обычно появляются новые программные продукты? Кто-то придумывает гениальную идею, составляет бизнес-план, изучает рынок, ищет инвесторов…
В моём случае всё было гораздо прозаичнее. Клиенту понадобилось нормально организовать работу с cookie и сторонними сервисами на сайте под MODX.
Казалось бы, что может быть проще? Поставить баннер, написать «Мы используем cookie», добавить кнопку «Принять» — и готово. Таких решений существует немало.
Но довольно быстро выяснилось, что между «показать баннер» и «действительно управлять согласием посетителя» лежит небольшая пропасть. Причём с Яндекс.Метрикой, Google Analytics, рекламными пикселями, видеоплеерами и картами на дне.
Так и появился Cookie Consent Manager — компонент, который изначально создавался для конкретного рабочего сайта, но постепенно вырос в универсальный инструмент для MODX 2 и 3.
С чего всё началось
На сайте клиента использовались аналитические счётчики, рекламные интеграции, видео и карты. Требовалось сделать так, чтобы посетитель мог управлять разрешениями, а сайт действительно учитывал его выбор.
И здесь обнаружилась проблема, характерная для многих сайтов: баннер существует сам по себе, а подключённые скрипты живут своей жизнью.
Посетитель ещё ничего не разрешил, но Метрика уже загрузилась. Пользователь отключил аналитику, а где-то в шаблоне по-прежнему подключён рекламный пиксель. Видео загружается вместе со страницей, хотя человек даже не собирался его смотреть.
Получается интересная ситуация: посетитель вроде бы управляет cookie, но сами cookie об этом не знают.
Мне хотелось решить задачу системно:
- Управлять запуском аналитики и рекламы в зависимости от разрешений.
- Откладывать загрузку видео, карт и другого внешнего содержимого.
- Настраивать категории, сервисы и тексты прямо из панели MODX.
- Поддерживать несколько языков.
- Сохранять историю предоставленных и изменённых согласий.
- Предусмотреть возможность подключения собственных JavaScript-интеграций.
- Не превращать каждую новую настройку в редактирование шаблонов и переписывание половины сайта.
Последний пункт был особенно важен. Кто давно работает с MODX, тот знает: если для изменения одной галочки приходится искать пять чанков, три сниппета и загадочный JavaScript-файл, значит, где-то архитектура свернула не туда.
А разве для MODX уже нет готовых решений?
Конечно, есть. Например, cookieconsent на базе библиотеки Osano или более функциональный EasyCookies.
И это хорошие новости: тема приватности наконец перестала ограничиваться простой надписью внизу страницы. Уже существуют компоненты, которые умеют работать с категориями согласий, счётчиками, журналами и настройками оформления.
Поэтому задача вовсе не заключалась в том, чтобы сделать «то же самое, только со своей иконкой».
Мне хотелось несколько другого подхода — дать разработчику MODX максимально гибкий инструмент, в котором можно управлять не только баннером и счётчиками, но и практически любыми внешними интеграциями.
Не просто красивое окно согласия, а полноценный механизм, связывающий выбор пользователя с поведением сайта.
При этом хотелось сохранить привычную для MODX свободу: доступ к исходникам, собственные сниппеты, расширяемость, управление из админки и отсутствие обязательной зависимости от внешней облачной CMP-платформы.
Собственно, именно из этого и выросла философия Cookie Consent Manager.
Два режима работы: Strict и Legacy
Один из первых вопросов, который пришлось решить: нужно ли всегда блокировать сторонние сервисы до получения разрешения?
У разных сайтов могут быть разные требования. Поэтому в компоненте появились два режима работы.
Strict — сначала разрешение, потом загрузка
Это основной режим, который я рекомендую использовать, когда требуется предварительное согласие на необязательные сервисы.
До того как посетитель сделал выбор, подключённые через компонент необязательные скрипты не запускаются. Аналитика, реклама и внешний контент ожидают разрешения соответствующих категорий.
Разрешил аналитику — запускаются разрешённые счётчики. Не разрешил рекламу — рекламные пиксели не загружаются. Не разрешил внешний контент — вместо видео или карты отображается заглушка.
Всё логично. Как и должно быть.
Legacy — для сайтов с другой моделью работы
Второй режим позволяет некоторым включённым сервисам запускаться ещё до первого выбора посетителя.
При этом компонент не создаёт фиктивного согласия, а сохранённый отказ посетителя продолжает учитываться.
Зачем такой режим? Для совместимости со сценариями, где используется уведомительная модель работы с cookie.
Важный момент: Legacy не подходит для ситуаций, когда законодательство требует предварительного согласия. Да и Strict сам по себе не делает сайт автоматически соответствующим GDPR или другим законам — многое зависит от реальных подключений и настроек сайта.
Компонент предоставляет инструменты, а решение о необходимом режиме остаётся за владельцем сайта.
Баннер, который можно настроить под дизайн сайта
Не всем нравится огромная плашка, занимающая треть экрана. Особенно на небольших сайтах, где посетитель пришёл узнать телефон компании, а вместо него увидел торжественное объявление о cookie.
Поэтому я предусмотрел три варианта расположения:
- Полоса снизу — привычный классический вариант.
- Компактное окно справа снизу — для тех, кто предпочитает менее навязчивое оформление.
- Компактное окно слева снизу — если справа уже находится чат, кнопка обратного звонка или другой элемент интерфейса.
На узких экранах компактные варианты адаптируются под мобильный формат.
Можно менять заголовок, описание, надписи кнопок, названия категорий, а внешний вид дополнительно корректировать через CSS сайта.
И что особенно удобно — посмотреть результат можно прямо в панели MODX, не сохраняя изменения и не открывая каждый раз сайт в новой вкладке.
Категории и сервисы: никаких жёстких рамок
Ещё одной важной особенностью стала универсальная система категорий.
В компоненте предусмотрены необходимые cookie, аналитика, маркетинг и внешний контент. Необходимая категория всегда активна, а остальные можно показывать или скрывать в зависимости от задач сайта.
При этом сервисы не привязаны намертво к определённой категории.
Например, можно назначить Яндекс.Метрику категории аналитики, рекламный пиксель — маркетингу, а видеоплеер — внешнему контенту. Но если конкретная интеграция требует другой логики, разработчик может изменить назначение.
Посетителю не нужно изучать длинный перечень технических скриптов и гадать, чем один пиксель отличается от другого. Он принимает решение на уровне понятных категорий.
Готовые интеграции
Из коробки предусмотрены адаптеры и механизмы подключения популярных сервисов:
- Яндекс.Метрика и Top.Mail.Ru;
- Google Analytics 4 и Google Tag Manager;
- Google Ads, VK Ads Pixel и Meta Pixel;
- YouTube, RUTUBE и VK Видео;
- Google Maps и Яндекс.Карты;
- собственные JavaScript-сервисы.
Можно добавлять несколько экземпляров одного сервиса с разными идентификаторами и настройками.
А если завтра появится новый рекламный сервис с названием из пятнадцати согласных и двумя цифрами — необязательно ждать, пока кто-нибудь выпустит отдельный компонент для MODX.
Собственные JavaScript-сервисы
Допустим, у клиента используется сторонний онлайн-консультант, аналитическая платформа или нестандартный виджет.
Достаточно создать пользовательский сервис, указать название, адрес JavaScript-файла, назначить категорию и включить его.
В Strict такой скрипт будет загружаться только после разрешения соответствующей категории.
Без необходимости встраивать его непосредственно в шаблон и писать собственный механизм отслеживания согласия.
Разумеется, сам JavaScript должен быть безопасным и корректно работать с внешними зависимостями — компонент не превращается в антивирус и не проверяет произвольный код разработчика.
Видео и карты: загрузка только тогда, когда она действительно нужна
На мой взгляд, это одна из самых полезных возможностей Cookie Consent Manager.
Многие привыкли думать, что управление cookie — это исключительно про счётчики. Но встроенный YouTube, RUTUBE, VK Видео или карта тоже могут отправлять данные на сторонние серверы.
Причём иногда ещё до того, как посетитель нажал кнопку воспроизведения или начал взаимодействовать с картой.
Поэтому я добавил специальные сниппеты CookieConsentVideo и CookieConsentMap.
В режиме Strict вместо iframe до разрешения отображается заглушка с понятным объяснением. После разрешения компонент создаёт настоящее встраивание.
Для видео можно использовать локальный постер, размеры, соотношение сторон и дополнительные параметры.
А если нужен нестандартный iframe?
Для этого предусмотрен ещё один способ — использование HTML-элемента <template>.
Его содержимое остаётся неактивным, пока компонент не разрешит встроенный сервис. Такой подход позволяет работать с доверенными HTML-встраиваниями, не ограничиваясь только несколькими заранее заданными сниппетами.
Иными словами, вместо попыток сначала загрузить iframe, а потом героически его блокировать, мы просто не создаём его до разрешения.
Меньше лишних запросов, меньше неожиданностей и понятнее логика.
Также предусмотрена работа с содержимым, добавленным через AJAX, с помощью публичного JavaScript API.
Самая интересная фишка для разработчиков — редактируемые адаптеры
Теперь немного о том, что мне самому особенно нравится.
Знакомая ситуация: внешний сервис меняет способ подключения SDK. Вчера всё работало, сегодня перестало. Обновления компонента пока нет, а клиент уже спрашивает, почему пропала статистика.
Обычно остаётся ждать новую версию пакета или разбираться с его внутренностями.
В Cookie Consent Manager я решил сделать иначе.
Исходные JavaScript-адаптеры доступны разработчику для редактирования. Если необходимо изменить способ загрузки конкретного сервиса, можно поправить соответствующий файл.
Но просто разрешить редактирование мало. Возникает следующий вопрос: что будет при обновлении пакета?
Чтобы собственные изменения не исчезали, компонент использует сохранённые SHA256-хеши оригинальных версий адаптеров и сравнивает их при обновлении.
- Если исходник не меняли, его можно автоматически обновить.
- Если разработчик изменил файл, его версия сохраняется.
- Если новая сборка завершилась ошибкой, предыдущая рабочая версия JavaScript остаётся доступной.
Один минифицированный файл вместо россыпи скриптов
Встроенные адаптеры объединяются в один готовый минифицированный JavaScript-файл.
Сборка выполняется средствами PHP прямо на сервере — без обязательной установки Node.js, npm или Composer.
И самое главное: сборка запускается из панели MODX, а не во время посещения сайта.
Очистили кеш через Manager или нажали кнопку пересборки — получили новый bundle. Посетители получают уже подготовленный файл.
Никаких компиляций на каждом запросе и неожиданных сюрпризов для производительности.
Мне кажется, такой подход особенно удобен для разработчиков, которые хотят контролировать интеграции, но при этом не желают создавать собственный механизм согласий с нуля для каждого сайта.
Мультиязычность без ограничений двумя флажками
Ещё одна вещь, которую хотелось сделать правильно, — локализация.
Русский и английский предусмотрены из коробки. Но этим возможности не ограничиваются: можно добавлять собственные языки, переводы и формулировки.
Редактируются не только основной текст баннера и кнопки, но также:
- названия и описания категорий;
- названия подключённых сервисов;
- сообщения для видео и карт;
- подписи элементов настроек согласия.
Язык определяется с учётом настроек контекста MODX.
Это особенно удобно, когда один и тот же сайт работает сразу с несколькими странами, а формулировки нужно адаптировать не только лингвистически, но и под фактическую политику обработки данных.
И да, тексты можно менять без необходимости каждый раз открывать редактор исходного кода. Иногда это само по себе уже повод для маленького праздника.
Журнал согласий: не только спросить, но и сохранить ответ
Один из важных вопросов, связанных с согласием на cookie: как подтвердить, какой выбор сделал посетитель?
Для этого в Cookie Consent Manager предусмотрен журнал.
Компонент может сохранять события выбора и изменения разрешений в JSONL-файлах на собственном сервере сайта.
В панели MODX можно просматривать записи, использовать фильтры, открывать детали событий и экспортировать данные в CSV.
Для хранения не требуется отдельная облачная платформа или сторонняя база данных.
Разумеется, сам журнал тоже требует ответственного отношения: он может содержать технические и персональные данные, поэтому необходимо правильно настроить доступ к файлам и сроки хранения.
При этом журнал — не замена политике конфиденциальности и не универсальная юридическая индульгенция. Но как технический инструмент фиксации решений посетителей он очень полезен.
Для программистов есть JavaScript API
Разумеется, предусмотреть вообще все сценарии использования невозможно.
Поэтому у компонента есть публичный JavaScript API. Через него можно получить сохранённое решение, открыть настройки, разрешить выполнение собственного кода и активировать управляемые встраивания.
Например, с помощью onAllowed() можно запускать собственную интеграцию только при наличии разрешения соответствующей категории.
Это особенно полезно для нестандартных виджетов, динамического содержимого и AJAX-интерфейсов.
При этом API учитывает актуальность разрешения, что важно для асинхронных операций, когда пользователь может изменить решение уже после начала выполнения JavaScript.
Есть и готовая кнопка повторного открытия настроек, которую можно разместить в подвале сайта. Посетитель в любой момент сможет вернуться к своему выбору.
Подключение без сложных ритуалов
Я старался, чтобы начало работы с компонентом было максимально простым.
После установки достаточно включить нужные сервисы, настроить категории и тексты, а затем добавить в шаблон два некешируемых вызова:
[[!CookieConsentAssets]]
[[!CookieConsentBanner]]Code language: JSON / JSON with Comments (json)Первый подключает необходимые ресурсы, второй выводит баннер. Если удобнее, есть и альтернативный вариант с одним сниппетом CookieConsent.
Никаких обязательных облачных аккаунтов для работы самого менеджера согласий, никакого jQuery и никакой ежемесячной подписки на внешнюю CMP-платформу.
Конечно, идентификаторы и доступ к самим сторонним сервисам по-прежнему нужны, если вы собираетесь их использовать.
Но настройка правил запуска этих сервисов остаётся на вашем сайте.
MODX 2 и MODX 3 — обе платформы поддерживаются
Изначально разработка велась для MODX 2, но довольно быстро стало понятно, что ограничиваться одной веткой CMS не хочется.
Поэтому я подготовил две самостоятельные версии компонента:
- Cookie Consent Manager — для MODX 2.8.4–2.8.x.
- Cookie Consent Manager 3 — для MODX 3.1.2 и 3.2.x.
Обе версии требуют PHP 8.1 или новее в пределах проверенных конфигураций и имеют одинаковую основную функциональность. Для установки используются отдельные transport-пакеты.
При разработке особое внимание уделялось совместимости, обновлениям, сохранению пользовательских адаптеров и штатному удалению пакета без необдуманного уничтожения пользовательских журналов и изменённых файлов.
Что получилось в итоге?
Если коротко, я хотел сделать компонент, которым было бы удобно пользоваться и владельцу сайта, и программисту.
Чтобы администратор мог без правок шаблонов поменять текст баннера или подключить счётчик. Чтобы разработчик мог добавить нестандартный сервис, управлять асинхронной загрузкой и при необходимости изменить адаптер. А посетитель — действительно влиять на то, какие необязательные интеграции загружаются на сайте.
Сейчас Cookie Consent Manager — это уже гораздо больше, чем небольшой скрипт с кнопкой согласия.
При этом я не ставил перед собой задачу создать самую сложную систему управления приватностью на свете. Скорее наоборот: дать достаточно возможностей, но не заставлять разработчика проходить десять кругов настроек ради подключения одного счётчика.
И это, пожалуй, мой любимый результат всей работы: компонент вырос, а идея осталась прежней — меньше ручной рутины и больше понятного контроля.
Где скачать Cookie Consent Manager?
Обе версии подготовлены для публикации на Modstore:
Также я подготовил подробную документацию на русском и английском языках для проекта MODX Docs. Там есть инструкции по настройке, примеры подключения видео и карт, описание JavaScript API, адаптеров, журналирования и работы с собственными скриптами.
Если вы разрабатываете сайты на MODX и хотите не просто выводить уведомление о cookie, а управлять реальной загрузкой сторонних сервисов, попробуйте Cookie Consent Manager на своём проекте.
Буду рад обратной связи, замечаниям и предложениям по развитию компонента. Особенно интересны нестандартные сценарии, для которых пока не предусмотрена готовая интеграция.
В конце концов, вся эта история началась с одного клиентского запроса. Кто знает, какая следующая задача поможет сделать компонент ещё полезнее?
