Multilingual cookie-consent administration and frontend integration for DravenCMS. The package stores consent settings and translated modal content, publishes Vanilla CookieConsent assets, and generates the browser initialization script from the active configuration.
- Administration for multiple cookie-consent configurations.
- One active configuration at a time.
- Translated titles, descriptions, revision messages, and policy links.
- Opt-in and opt-out modes.
- Cookie lifetime, domain, automatic cleanup, page-script, and forced-consent settings.
- Reusable frontend settings button.
- Provider-defined admin navigation and ACL permissions.
composer require dravencms/cookie-consentThe DravenCMS package loader loads dravencms.config.neon and publishes assets to %wwwDir%/assets/cookieConsent. The configuration registers presenters, Doctrine mappings, translations, routes, and frontend WebLoader files.
Apply the package's database schema through the application's migration workflow before enabling administration. Navigation and permission definitions come from providers.
Add TCookieConsentPresenter to a shared frontend presenter:
use Dravencms\CookieConsent\TCookieConsentPresenter;
use Dravencms\FrontModule\BasePresenter;
abstract class FrontPresenter extends BasePresenter
{
use TCookieConsentPresenter;
}Render the settings button wherever visitors should be able to reopen their consent preferences:
{control cookieConsentSettingsButton}The button is rendered only when an active configuration exists. The package's frontend bundle loads Vanilla CookieConsent, package styling, and the generated /cookieconsent-init script automatically.
Consent-managed scripts use Vanilla CookieConsent v3 attributes:
<script type="text/plain" data-category="analytics" data-service="Google Analytics">
// Loaded after analytics consent.
</script>Create a configuration for every required locale, then set one configuration active. Available settings include:
- Consent mode (
opt-inoropt-out). - Cookie expiration in days and optional cookie domain.
- Automatic cookie cleanup.
- Page-script handling.
- Forced consent.
- Translated consent text and privacy/cookie-information URLs.
Activating one configuration automatically deactivates the others.
/cookieconsent-init returns the JavaScript configuration generated from the active database record. Do not cache this route longer than the application can tolerate stale consent settings.
The ACL provider defines cookieConsent.edit and cookieConsent.delete; assign them explicitly through the group editor.
This package is licensed under the LGPL-3.0-only license.
Administration uses User 3.1, Admin 3.2 and Application 0.3 guards. Screens and write callbacks enforce the existing provider-defined permissions server-side, including direct URLs and bulk callbacks. Mutating signals require POST and a session-bound action token; synchronize the matching admin assets when upgrading. See the User package's user:security:migrate instructions for the password-reset schema change.
Released packages include a generated public/ directory. Packager 3 links it to
www/assets/ on every Composer install/update; existing asset URLs stay the same.
Development sources, package metadata and tests are kept outside the public directory.
After editing assets, install Composer dependencies and run composer build:assets.
The explicit runtime file list is assets/public-assets.json; local CSS dependencies
are included automatically. Commit public/ and public-assets.manifest.json with
the source changes. The builder rejects missing dependencies and locally modified
or unmanaged generated files. Admin's npm run build:admin also rebuilds public assets.