Website › Cookie consent switches on the platform's cookie bar (setup/web.consent). It is off by default: a project that runs its own consent solution leaves it off and nothing is added to its pages.
Switching it on#
- Open Website › Cookie consent and turn on Show the cookie bar.
- Pick the appearance: a full-width bar or a floating box, and its position.
- Choose the categories offered beyond Necessary (always on, never asked): Preferences, Analytics, Marketing. Blank offers all three.
- Set the cookie policy page — the bar and the settings panel link to it.
- Run Rescan in the Detected services card and save. The scan classifies everything the site loads (head tags, elements, templates, the design CSS) against the vendor catalog; the saved snapshot is the service and cookie list visitors see in the settings panel. Re-assign a service's category there when the catalog's default does not fit.
- Put the Cookie settings link in the site's footer (see Reopening the settings below).
The bar needs the web capability to configure.
What the visitor gets#
On the first visit the bar offers Accept all, Only necessary and Settings (a panel with one switch per category and the services behind it). The choice is stored in the drop_consent cookie for 180 days and the bar does not come back until it expires — or until you bump the Consent version, which invalidates every stored choice and asks again. Bump it whenever the declaration changes (a new service, a service moved to another category).
When the language is in the URL (Site › Language in URL, path mode), the platform's language cookie drop_locale is never set or read; Detected services marks it "not used — the language is in the URL" and the bar leaves it out of its declaration.
For a site served on both the apex and www, set the Cookie domain (example.com) so one choice covers both hosts; otherwise the cookie is host-only.
What is held back until consent#
With Gate Head tags on (the default), third-party scripts, pixels, embeds and stylesheets in Head tags and Footer tags are neutralized at render and run only after the visitor grants their category. The gating preview card shows exactly which tag waits for which category, and warns about HTML the gate cannot parse (that part is emitted as written).
- Your own site files (same-origin code) are never gated.
- A cross-origin service the catalog does not know is gated as Marketing while Gate unknown services is on (the default).
- Web fonts load without consent. Google Fonts, Adobe Fonts (Typekit), Bunny Fonts, Fontshare, Font Awesome and Cloud.typography are Necessary in the catalog, so a visitor who picks Only necessary sees the same site, not a fallback font. They set no cookies, but the visitor's browser still contacts the font provider; the bar lists them as such. To ask first, re-assign the service to Preferences in Detected services. Self-hosted fonts (uploaded with the design system) contact nobody and are the cleanest choice.
- In Detected services you can re-classify a service or mark it as always allowed.
- When the platform's catalog learns a service, a saved snapshot is shown against the current catalog right away (an
unknown:host it now recognizes appears under the vendor's name); Rescan to refresh the rest.
Turn Gate Head tags off to keep just the bar and gate your own code (below).
Reopening the settings#
A visitor must be able to change their choice at any time. There is no floating button — the Cookie settings link belongs in the site's footer. Any element carrying the data-drop-consent-open attribute opens the settings panel when clicked.
The recommended footer markup is one empty, hidden tag:
<button type="button" class="my-footer-cookies" data-drop-consent-open hidden></button>- Empty — the bar fills in the localized label (
consent.reopen: "Cookie settings" / "Nastavení cookies"), so the template carries no hardcoded text. hidden— the bar un-hides it. While the bar is off, the link stays invisible, so the same footer works either way.
Style it like the footer's other links (a <button> needs its border and background reset). To use your own wording, write the label inside the tag — a non-empty element keeps its text. An <a> works as well as a <button>.
From code, window.DropConsent.open() opens the same panel.
Texts#
The bar reads its copy from the consent translation group under Data › Wording; a missing key falls back to the built-in Czech / English text. Use Seed default texts in the Bar texts card to create the keys, then edit them per locale.
| Key | Used for |
|---|---|
consent.title, consent.body |
The bar's heading and text |
consent.accept, consent.reject, consent.settings |
The bar's three buttons |
consent.save, consent.close |
The settings panel |
consent.policy |
The policy link |
consent.reopen |
The footer's Cookie settings link |
consent.{category}, consent.{category}_desc |
Each category's name and description |
Reacting to consent in page code#
Element and template scripts that must wait for consent listen to the drop:consent event — fired after every decision, and once on load for a returning visitor:
document.addEventListener('drop:consent', (e) => {
if (e.detail.granted.includes('analytics')) startAnalytics();
});window.DropConsent is the API:
| Call | Effect |
|---|---|
get() |
{granted, record, version, categories, services} — granted always contains necessary |
open() / close() |
Show / hide the settings panel |
grant([...]), grantAll(), denyAll() |
Record a decision |
onChange(fn) |
Subscribe; returns an unsubscribe function |
Before first paint the page's <html> carries data-drop-consent="necessary analytics …" (the granted list), so CSS can react too — for example a placeholder over a map that is shown until preferences is granted.
To gate your own tag by hand, write it the way the gate does — the bar revives it once the category is granted:
<script type="text/plain" data-drop-consent="marketing" data-src="https://example.com/pixel.js"></script>Restyling#
The bar follows the design system and can be tuned with CSS custom properties: --drop-consent-bg, --drop-consent-fg, --drop-consent-muted, --drop-consent-accent, --drop-consent-accent-fg, --drop-consent-border, --drop-consent-radius, --drop-consent-font, --drop-consent-shadow.
In the Studio preview#
Previews never show the bar and never ask for consent — not the Studio's site preview, not the document editor's. Gated head and footer tags stay held back there (no third-party tag runs in a preview), and the footer's Cookie settings link has no panel to open. Check the bar itself on the published site.