CookiezyCookiezy
ProdottoPiattaformeDocumentazionePrezziBlogContatto
  1. Home/
  2. DatoCMS adapter | Documentazione tecnica Cookiezy

Documentazione aggiornata l'ultima volta il 29 maggio 2026

Cookiezy

Piattaforma leggera per la gestione del consenso ai cookie su siti web moderni.

Prodotto

FunzionalitàPiattaformePrezziDocumentazioneBlogContatto

Legale

Informativa sui cookieInformativa sulla privacyTermini di servizio

Lingua

Italiano
EnglishenSlovenščinaslHrvatskihrItalianoit

Gestione dei cookie

© 2026 Cookiezy. Tutti i diritti riservati.
Panoramica

DatoCMS adapter: modello diviso tra plugin e runtime frontend

Usa questa guida quando DatoCMS è la fonte di contenuto o configurazione ma non il layer runtime in cui il banner del consenso viene realmente renderizzato.

  • • Tratta DatoCMS come CMS headless con una lane plugin lato editor opzionale.
  • • Usa Platform Core per il runtime visitor-facing nell’app frontend che rende i contenuti di DatoCMS.
  • • Usa il plugin DatoCMS standalone per generated config preview e guida di rollout lato editor.
  • • Registra ogni hostname frontend live prima della pubblicazione.
Passo 1

Mantieni il runtime nell’app frontend

Banner del consenso, riapertura delle impostazioni, audit e runtime verification devono continuare a girare nell’app frontend che consuma i contenuti di DatoCMS.

  • • Genera `cookiezy-platform-core.zip` per il runtime frontend.
  • • Usa lo scaffold headless DatoCMS insieme agli asset del runtime condiviso.
  • • Porta `siteKey`, `verifyUrl` e `billingUrl` nel runtime frontend invece di cercare di eseguire la logica di consenso dei visitatori dentro DatoCMS.
Passo 2

Usa il plugin DatoCMS solo per impostazioni lato editor

Se gli editor hanno bisogno di impostazioni Cookiezy dentro DatoCMS, aggiungi la lane plugin DatoCMS standalone e usala come superficie di configurazione, non come runtime storefront.

  • • Mantieni il plugin focalizzato su impostazioni lato editor e generated frontend config preview.
  • • Non posizionare il plugin come luogo in cui gira davvero il banner storefront.
  • • Usa il generated config preview per allineare policy URL, locale routes e identificatori delle integrazioni opzionali con l’app frontend.
Passo 3

Verifica il frontend live che consuma contenuti DatoCMS

Dopo la pubblicazione verifica il runtime visitor-facing sull’hostname frontend reale.

  • • Il banner appare alla prima visita.
  • • Reject optional mantiene bloccate le categorie opzionali.
  • • Accept all sblocca le categorie configurate.
  • • Il cookie policy audit si rende sulla pagina policy del frontend.
  • • La runtime verification restituisce `allowed: true` per l’hostname frontend registrato.
  • • Il comportamento del frontend resta allineato con l’anteprima delle impostazioni generata da DatoCMS.