GDPR & storage
Popup frequency requires storing “I already saw this popup” state somewhere on the visitor’s machine. That’s potentially regulated by ePrivacy / GDPR depending on jurisdiction and how aggressive the store wants to be. The plugin offers three modes and a PHP session fallback so you can match your legal posture.
The mode is picked in Settings → Plugins → P2Lab Stage → Popup → Dismiss persistence (GDPR), per sales channel.
The three modes
Section titled “The three modes”Wait for cookie acceptance (consent) — default
Section titled “Wait for cookie acceptance (consent) — default”The plugin doesn’t touch sessionStorage / localStorage / cookies until the visitor accepts cookies via your consent manager. Until consent arrives, suppression lives in PHP session (server-side).
Effect for visitors who don’t consent:
- Frequency = Session — works fully, suppression lives in PHP session.
- Frequency = Every N days — degrades to session-only suppression (PHP session expires when browser closes, no localStorage to remember the N days).
- Frequency = Permanent — degrades to session-only suppression for the same reason.
Effect for visitors who consent:
- Suppression state is migrated from PHP session into
localStorage/sessionStorage. - All frequency modes work as documented.
The plugin polls for consent changes on cookieAcceptedAndCacheable events (Shopware’s standard cookie-consent event), so accepting cookies mid-visit takes effect immediately.
Use browser storage (storage)
Section titled “Use browser storage (storage)”The plugin writes to sessionStorage and localStorage immediately, no consent gate.
When to pick: if your legal posture treats these stores as exempt — typically the case when frequency suppression is considered a “strictly necessary” / “functional” purpose, e.g. preventing the same modal from annoying a visitor on every page load. Confirm with your legal team.
Effect: all frequency modes work as documented for every visitor.
Use cookies (cookie)
Section titled “Use cookies (cookie)”Same as storage mode but uses actual HTTP cookies as the backing store. Some legal frameworks treat cookies differently from localStorage; some block strictly first-party functional cookies, some don’t.
When to pick: in shops where the legal posture explicitly carves out cookies for this purpose, or in environments where localStorage is unreliable (legacy browsers, embedded contexts).
Storage keys
Section titled “Storage keys”When writing client-side:
sessionStorage— prefixp2lab-stage-. Plain<popupId> → dismissedflag.localStorage— prefixp2lab-stage-. Includes expiry timestamp fordaysfrequency, no expiry forpermanent.- Session counter —
p2lab-stage:shown-counttracks the per-session distinct-popup count for the queue display mode cap.
When writing server-side (PHP session): an array under a custom session key.
The PHP session fallback
Section titled “The PHP session fallback”PHP session is the always-on backing store. The plugin uses it unconditionally for:
- Tracking which popups have been server-dismissed during this session.
- Recording dismissal when client storage is gated (consent missing) or unavailable (private browsing modes that disable localStorage).
The fallback means visitors who reject cookies still don’t see the same popup five times in one session — the server-side session ensures session-frequency works regardless of GDPR mode.
The trade-off: server-side state is lost when the PHP session expires (typically when the browser closes), so longer-than-session frequencies (days, permanent) degrade for visitors who never consent.
Migration on consent change
Section titled “Migration on consent change”When gdprMode = consent and the visitor accepts cookies after having dismissed a popup:
- The client picks up the
cookieAcceptedAndCacheableevent. - Calls
GET /p2lab-stage/dismissedto fetch every popup ID currently suppressed in PHP session. - Migrates them into
sessionStorage/localStorage(with the original frequency type’s expiry semantics).
After this migration, the PHP session no longer needs to carry the suppression — it stays as a redundant backup but client storage is now authoritative.
What gets recorded vs not recorded
Section titled “What gets recorded vs not recorded”Dismissal state is the only persistent storage the plugin owns:
- One entry per popup the visitor has dismissed, with frequency type + (optional) expiry.
- Distinct-popup-shown counter for the per-session cap.
The plugin does not store visitor identity, personal data, or behavior beyond these dismissals. Statistics events (impression / CTA-click / close / permanent_dismiss) are recorded server-side in p2lab_stage_event and may include customer ID if the visitor was logged in — see Analytics → Events.
Cookie banner pattern
Section titled “Cookie banner pattern”A common use is the cookie banner itself: a popup with Always show frequency (so it shows until acknowledged) + a button whose Click action = Don’t show again records a permanent_dismiss event and writes the permanent flag.
For this pattern, pick GDPR mode = Use browser storage or Use cookies so the dismissal sticks beyond the session — otherwise the visitor sees the banner every time they reopen the browser, which defeats its purpose.
Where to go next
Section titled “Where to go next”- Targeting → Frequency — how each frequency interacts with storage.
- Storefront → How stages render — the resolve / dismiss endpoints.
- Analytics → Events — what’s recorded server-side independently of GDPR mode.