Laravel Cookie Consent Laravel Package

Getting Started

Start with the package README and the v1.1.0 changelog, then inspect the published config file and the Livewire component registration in the service provider. The release refactored installation/uninstallation commands and added a new config file, so use the current install flow rather than older examples.

Minimal path:

1. Require the package via Composer.
2. Run the package’s install command as documented in the current README. v1.1.0 refactored this command, so verify the command signature before scripting it into deployments.
3. Publish the config file and any assets/views you need to customize.
4. Include the package’s Livewire cookie-consent component in your main Blade layout, typically just before </body>.
5. Configure cookie name, lifetime, categories/text, and asset paths in the published config.

First practical use case: add the consent banner to a Laravel app layout, publish the config, customize the copy and categories, then verify the banner renders and consent choices persist across requests. If you are upgrading from v1.0.0, begin by diffing your published views/config against v1.1.0 before changing application code.

Implementation Patterns

Use the package as a layout-level Livewire component. Keep it in the shared app layout so every page can display the banner and persist consent consistently.

Common patterns:

• Config-first customization: Put banner text, cookie settings, categories, and asset options in the published config. Avoid editing vendor files so future upgrades remain manageable.
• Stable component reference: Include the package component using its documented Livewire tag/alias. Since v1.1.0 updated Livewire component paths, prefer the package’s public component name over hard-coded class paths.
• Consent-gated scripts: Check the package’s persisted consent state before loading analytics, embeds, or marketing scripts. Treat the banner as UI and the stored consent as the source of truth.
• View overrides: Publish and override views only when branding or markup changes are needed. Keep overrides small and re-check them after package upgrades.
• Service usage when extending: v1.1.0 introduced asset management and configuration services. If you need custom behavior, depend on those services rather than duplicating asset/config logic.
• Testing: v1.1.0 migrated to Laravel’s testing framework. Use Livewire component tests to assert rendering, consent actions, persistence, and config-driven behavior. Include a test that the banner appears for new visitors and does not reappear after acceptance/rejection as appropriate.

For deployment, include config/asset publishing and cache clearing in your release process if the package’s install command does not already handle it. For multi-environment apps, confirm that published assets are available in production and that config caching does not hide stale package settings.

Gotchas and Tips

• v1.1.0 is potentially breaking for extenders. The release notes explicitly warn that some files were removed and Livewire component paths changed. If you extended package classes, published views, or referenced internal paths, diff your implementation against v1.1.0 and update references.
• Re-publish or merge config carefully. A new config file was introduced. Do not blindly overwrite an existing app config without reviewing differences; merge new keys into your environment-specific config.
• Clear caches after upgrade. Run php artisan config:clear, php artisan view:clear, and php artisan optimize:clear as appropriate. Stale compiled views or cached config are common causes of “the banner still looks old” after an upgrade.
• Avoid hard-coded Livewire paths. Use the documented component alias/tag. The Livewire component path changes in v1.1.0 are exactly the kind of change that breaks hard-coded references.
• Check asset publishing. The new asset management service may change how assets are resolved or published. Verify the banner styling and any JS assets in production, not only in local development.
• Do not rely on hidden banner state alone. Gate non-essential scripts on the persisted consent value, and handle cases where consent has not yet been given.
• Debug exceptions through the package’s improved handling first. v1.1.0 improved exception handling, so read the package exception messages and logs before overriding behavior. If you catch package exceptions in app code, confirm the exception types still match.
• Use the changelog for upgrade work. The release notes point to the full v1.0.0...v1.1.0 changelog; use it to identify removed files and renamed internals before upgrading a customized installation.