Hi everyone 👋

I’ve just released the first Release Candidate of my Laravel package: LaraGDPR — A Laravel GDPR Cookie Consent Manager

Packagist: https://packagist.org/packages/minkovdev/laragdpr

The goal of this package is to provide a simple, Laravel-native way to manage cookie consent, cookie categories, and third-party scripts while keeping the implementation clean and developer-friendly.

What does it provide?

The package currently includes:

• Cookie consent management
• Cookie categories and cookie definitions
• Consent storage and tracking
• Support for anonymous and authenticated users
• Consent withdrawal
• Cookie preference management
• Automatic script handling based on consent
• Script risk analysis
• Blade-based rendering
• Optional Livewire integration
• Configurable assets and middleware
• Cache support for performance
• Database migrations and models
• Laravel-friendly services, actions, DTOs, and enums

The package was built with Laravel conventions in mind and tries to avoid forcing a specific frontend stack.

Installation

composer require minkovdev/laragdpr

After installation:

php artisan vendor:publish --tag=laragdpr-config php artisan migrate

Then you can configure the package according to your application needs.

Why another GDPR package?

There are already some great solutions available, but I wanted something that:

• feels natural inside a Laravel application
• provides proper backend handling of consent
• supports both Blade and Livewire
• gives developers control over rendering and behaviour
• avoids depending on external SaaS services

The package is designed primarily for Laravel developers who need GDPR cookie consent functionality without adding a large external dependency.

This is an RC release — I need your feedback

Before tagging the stable release, I would really appreciate feedback from the Laravel community.

I am especially interested in:

• Configuration structure
• Blade/Livewire integration
• Developer experience
• Missing features
• Possible breaking changes before stable release
• Security concerns or edge cases

If you try it, please let me know:

• What worked well?
• What felt confusing?
• What would you change?
• What features would you expect from a package like this?

Any feedback, even small things, would be extremely valuable.

Roadmap ideas

Some features I am considering for future versions:

• Extended audit capabilities (audit trail)
• Anonymisation feature (Right to be forgotten)
• User data export
• Audit export/reporting options
• Admin dashboard to manage categories and cookies
• Consent reports
• Consent analytics (like how many users % accept all vs. essential)

Links

• Packagist: https://packagist.org/packages/minkovdev/laragdpr

• GitHub: https://github.com/minkovdev/laragdpr

Thanks to everyone who takes the time to test it and share feedback. 🙏

Looking forward to hearing your thoughts!

Oh NO!!! You deleted a prod DB while local!? 😱

I am not talking about delivering like this. Yes, usually I just add a migration to alter an existing database, or an additional seeder.

But during development, when you just want to try something that you are not quite sure about, or you are just tinkering with things, using something like the above is a good fix/fast track.

Later, if satisfied, do it the proper way.

Sometimes you have to create a database table and seed it before running another migration, since that second migration may reference the already-created table and need data from it. Not very often, but it may happen.

You shouldn't interfere this process and choose migration processing order by yourself.

Why not? I am trying or testing something. I can do whatever I want and run whatever I want in whatever order I want.

Create a Console command. Inside, using Artisan::call(), you can order the elements as you see fit, since both migrate and seed commands accept parameters:

Artisan::call('migrate', ['path' => '/database/migration/xxx.php']);

Artisan::call('db:seed', ['class' => 'SeederClass']);

Artisan::call('migrate', ['path' => '/database/migration/yyy.php']);

Artisan::call('migrate', ['path' => '/database/migration/zzz.php']);

Artisan::call('db:seed', ['class' => 'YetAnotherSeederClass']);

That is what the seeders are for. The difference will be that instead of php artisan migrate or php artisan migrate:fresh you will have to run php artisan migrate --seed or php artisan migrate:fresh --seed. And that is it.

Ahhh ... ZOMBIES!!!

I would say If you don't know what you are doing, then do not use AI or at least minimise its usage.

@randy_johnson You could also just dispense with it all and put everything in a single index.php script.

I accidentally stabbed myself in the foot. Is there any way to unstab my foot? I only have two feet and this one is used to kick the cat so I cant afford to lose it.