Cookie-консент и 152-ФЗ на потоке (зонтичный кейс, 6 сайтов)

Решение и подход

Ядро — плагин cookie-consent-shim (PHP, namespace CCS, GPL-2.0): singleton-bootstrap, installer (таблицы/опции), frontend (рендер баннера, enqueue), REST-эндпоинт для кастомных форм, admin (настройки + журнал), CRUD журнала согласий, интеграция CF7, шорткоды. Баннер рендерится на клиенте (совместимость с full-page кэшами). Публичный JS-API window.cookieConsent (get/getAll/isAccepted/open/reset/setAll/getMeta) + CustomEvent'ы cookieConsent:ready/change/withdraw/open/close — стабильный контракт, чтобы код заказчика по реальной блокировке не ломался между релизами. Журнал согласий по формам хранит timestamp, версию политики, HMAC-хеш IP/UA. Страница «Реквизиты ПДн» работает на ACF Pro Options Page, а при отсутствии ACF — на нативном Settings API с совместимыми ключами хранения; шорткод [legal field="."] читает оба источника (приоритет ACF → native → default).

Ключевые инженерные решения, выработанные как переиспользуемые паттерны (источник: HANDOFF.md, progress.md):

• Per-site override через mu-plugin (wp_add_inline_style + хук wp_footer), а не child-тему — изолирует код, не меняет body-class, не вызывает регрессий рендера; child-тема допустима только для FSE-тем.
• Для классических тем без template part — рендер триггера в wp_footer + inline-JS перемещает блок в нужный контейнер футера после DOM-ready.
• Управление z-index и перехватом кликов сторонних floating-виджетов через CSS-переменные плагина и точечные override.
• Backup post_content в meta перед каждой правкой Gutenberg-блоков; правка через strpos/substr или WP API, без жадных regex.

На Bitrix то же решение реализовано средствами платформы: миграционные скрипты создают инфоблок и HL-блок, компонент выводит баннер, журнал согласий пишется в HL-блок, формы дорабатываются через API форм Bitrix — то есть единая концепция 152-ФЗ перенесена на другой CMS-стек.

Стек и обоснование

• PHP / WordPress (плагин + mu-plugins + child-themes) — основной стек заказчиков; плагин как переиспользуемое ядро снижает стоимость каждого нового сайта.
• PHP / Bitrix (компоненты, инфоблоки, HL-блоки, API форм) — для invest-kbr.ru, где WordPress-плагин неприменим; то же решение нативными средствами платформы.
• JavaScript (vanilla) — клиентский рендер баннера и публичный JS-API без зависимостей, чтобы не раздувать LCP/CLS и работать поверх любых кэшей.
• Contact Form 7, ACF/SCF — стандарт форм и кастомных полей в экосистеме заказчиков; реализован fallback на нативный Settings API, чтобы не требовать ACF Pro.
• MySQL, REST API — журнал согласий и эндпоинт для кастомных форм.
• SSH / wp-cli, VPS/shared-хостинги (reg.ru, beget, Timeweb) — аудит и деплой; учтены ограничения shared-хостинга (установка wp-cli phar в ~/.local/bin, fail2ban-окна, отсутствие глобального wp-cli).

Инженерные вызовы

• Один функционал, три архитектуры тем WordPress (две FSE + одна классическая) и четвёртый стек (Bitrix) — потребовалось выработать платформо-специфичные паттерны интеграции, сохранив единое ядро.
• CF7-acceptance под Popup Maker (kidlife05) — 5 итераций фиксов ширины <label> через двухслойный CSS-override; результат вынесен в base-CSS плагина, на следующих сайтах работает из коробки.
• Темы с <button type="submit"> вместо CF7 [submit] (idealgraduation) — helper ищет оба варианта как якорь вставки.
• Безопасный деплой на shared-хостингах: dry-run search-replace, контроль целостности файлов (sha256/md5) после rsync, backup post_content в meta, проверка php -l/base64 -d перед запуском на проде, учёт fail2ban-окон.
• Bitrix: работа с БД в кодировке latin1, миграционные скрипты для инфоблоков/HL-блоков, двуязычность RU+EN, бэкап с поэлементной sha256-сверкой (11/11) перед стартом.
• Юридическая корректность: каждое нормативное утверждение со ссылкой на источник; обнаружены и исправлены некорректные отсылки в исходных материалах.