- How do I install livewire-cookie-consent in a Laravel application?
- Run composer require christopheraseidl/livewire-cookie-consent, then publish the config file and Blade views using the package's install command. Place the Livewire component in your main layout so it renders on every page, and wire up gating for the scripts you want to hold back until consent is given. The integration surface is small, so a Laravel developer can typically spike it in under a day. The real effort is inventorying every tag and script that must be gated and deciding where consent state is persisted.
- Which Laravel, Livewire, and PHP versions does this package support?
- The package is built for Laravel applications already running Livewire 3 and rendering server-side Blade views, with Alpine.js and Tailwind-friendly markup. The technical evaluation does not show a published, tested compatibility matrix for Laravel, Livewire, and PHP versions. Check the composer.json constraints against your pinned versions before adopting, and run the component on a staging branch first. If you are on an older Livewire major or a non-Blade front end, treat it as unsupported until proven otherwise.
- Does livewire-cookie-consent actually block tracking scripts before consent, or only hide the banner UI?
- That is the key question to verify in your own spike, because consent is a client-side, pre-hydration requirement while this package is a server-rendered Livewire component. The evaluation notes you must confirm whether script execution is genuinely blocked before consent or whether the package only renders the notice UI. Inspect the published views and any included JavaScript to see what gating, if any, is enforced. If blocking is not built in, add your own pre-consent script gate rather than assuming the banner handles it.
- Does it save consent server-side with a timestamp, policy version, and user identifier?
- The package describes persistence through config options, which in practice means a client-side cookie or localStorage flag rather than a durable, auditable server-side record. A compliance review will usually ask for timestamped consent tied to a policy version and, where possible, a user identifier. Plan to add your own consent-log table and write to it when the visitor accepts, rejects, or later withdraws consent. Also confirm whether the package supports re-prompting when your policy version changes.
- Does the banner support granular consent categories like necessary, analytics, marketing, and preferences?
- The package overview describes collecting visitor approval, not a granular category model, so assume a single accept/reject pattern until you confirm otherwise in the source. If your jurisdiction or your tag setup needs per-category toggles, verify this before committing, because retrofitting categories into a published Blade view is real work. For most analytics and marketing stacks you also need the category choices to map to actual script gating. If granular consent is a hard requirement, a thin custom banner plus a consent-log table may be the lower-risk build.
- Can I customize the banner message, button labels, and markup?
- Yes, the package exposes config options for the message and button labels and ships publishable views you can override. Treat published views as forked code once you edit them, because after publishing you own them and package updates will not merge cleanly. Do not blindly re-publish with force if your views are customized. Diff the shipped views against yours on every upgrade.
- Is upgrading from v1.0.0 to v1.1.0 a breaking change?
- For anyone extending or overriding the package, yes. The v1.1.0 notes describe refactored install and uninstall commands, removed files, new services for asset and config management, changed Livewire component paths, and a new config file, all shipped as a minor release. Pin 1.1.0 in a scratch branch, re-run the refactored install command, and diff the published artifacts against what is already in your repository. Be prepared to manually update overrides that reference the old component paths.
- Can I use this package in a headless API backend or a Vue, React, or Next.js SPA?
- No, that is a structural mismatch. The package is a Livewire component with Blade views designed for a server-rendered Laravel monolith already running Livewire 3, so an API-first backend or a separate JavaScript front end cannot consume it directly. The same applies to multi-tenant setups where the consent UI must be themed and versioned per brand. In those cases, build a thin custom banner plus a consent-log table instead.
- How does livewire-cookie-consent compare to OneTrust, Cookiebot, or Osano?
- This is a small, self-hosted Livewire component rather than a full consent management platform, so it will not give you the audit reporting, jurisdiction rules, or tag-blocking integrations a commercial CMP provides. If your product already ships OneTrust, Cookiebot, Osano, or similar, reject this package on duplicate-of-function grounds and never run two consent sources of truth. If you want a lightweight banner without a vendor and you are willing to own the gating and the consent records, it can be a reasonable starting point. Weigh that against the single-maintainer risk.
- Can I rely on this package for GDPR, ePrivacy, or CCPA compliance?
- Compliance correctness cannot be inferred from release notes or a banner screenshot and must be validated against your jurisdiction's requirements, including consent semantics, withdrawal, and Google Consent Mode v2 if you run Google tags. The package has a single maintainer and a low community surface, and in this domain a silent rendering failure has legal rather than merely functional consequences. Add server-side consent records, test the gating yourself, and have counsel or your DPO review the resulting flow. Treat the package as UI, not as your compliance system of record.