I'm using this one which is great too.

https://github.com/whitecube/laravel-cookie-consent

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!

I always use this package.

https://vue-i18n.intlify.dev/

Any packages which is better and easy to setup and used. Which is maintained time to time and support laravel 13.

I want a localization package to use the languages changes in the laravel monolith website SPA with the Vue js.

it's not clear:

1. what are your requirements?
2. what do you expect a package to do?
3. why you can't just implement locale yourself?

I really recommend you the paid subscription too.

You will have access to all series and all great quality series.

Hi,

I'm thinking about purchasing a paid Laracasts subscription, but I noticed that the instructor doesn't seem to answer questions in the comments.

For example, I've seen people ask questions under some videos, but they don't receive a reply from the instructor.

So, if someone doesn't get an answer to their question or confusion, does that mean the paid subscription only includes access to the video lessons and not any direct support?

I understand that users can post questions in the community and other members may help them. If that's the case, then is the paid subscription essentially just for access to the video content?

I highly recommend the paid subscription. The content quality if superb, help me get hired a decade ago and stay up-to-date today.

Quality content production and maintaining this website are very time-consuming. I believe they mostly don't have time to answer your questions directly.

But that should not be a problem, you can always ask AI or post your question in this forum. There are like 50 Laravel veterans always happy to help.

You probably know by now that it is the top right corner of a post.

This confusion makes me realise that some items in this dark mode could be super blurry for new members.

Unclear how to mark one of my questions as Solved

Click the 3 dots and it's in the dropdown.

Unable to see 'Mark as Best Answer' or anything else in the My Question thread

@glukinho @merklin

Sure never migrate in production without doing a database backup.

Using Eloquent models inside migrations generally works, but it's considered risky for a few reasons: if the model's schema changes later (new casts, appended attributes, relationships that expect newer columns), old migrations using that model can break when run fresh on a new environment. A safer approach for data migrations is to query the table directly with the query builder instead of the model: phpDB::table('packages')->orderBy('id')->chunk(100, function ($packages) { foreach ($packages as $package) { DB::table('packages') ->where('id', $package->id) ->update(['client_id' => /* logic here */]); } }); This keeps the migration self-contained and immune to future changes in your model. If the transformation logic is complex, some teams create a dedicated console command for data backfills instead of putting it in a migration at all.

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

I agree, you can do anything during development even forbidden things :)

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.

second migration may reference the already-created table and need data from it

That's exactly why manipulating data in migrations seems bad to me, I tried to explain it here earlier.

I can do whatever I want

Absolutely! But I'm sure doing things against common practice and framework rules is always bad and leads to fatal complication of developing. You can't imagine right now where and how exactly you get into trouble with such bad solutions but you definitely will.

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.

This is something strange. Migrations are applied in alphabetical order (that's why their filenames should include date/time, to ensure old migrations are applied before recent ones). You shouldn't interfere this process and choose migration processing order by yourself.

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']);

@rogerwick

Here is an example of a line in the documentation.

Tier 1 $ 5 paid $ 100 / month

Why do I have to pay $ 5 AND $ 100 ?

I did understand that $ 5 is a reserve for what I will use and I didn't understand why I have to pay up to $ 100 for what I use while I had already paid $ 5.

It's very confusing for me and probably for other people too.

OpenAI should write explicitely what each price is for :

Tier 1

• $ 5 to subscribe to the tier
• up to $ 100 for what I use
• if I use more than $ 100, I have to switch to tier 2

It can be a bit confusing at first. The OpenAI API billing is generally based on how much you use the models, and you can manage your payment method and view your usage from your account's billing section. If there's something specific that's unclear, let us know what you're trying to do, and someone can help explain it step by step.... www.playfyhd.app

Are you sure that this is the best answer related to your question about how Yajra datatable works ? ;)

You can simply add a field to the users table to save the last used store.

Hello everyone! (working for free) (Please notice that this project is just a portfolio, and I don't have any budget for it!) If I sent it in the wrong place, please delete it and help me to put it in the right place.

I want to create a project for my portfolio (Laravel). I am looking for a front-end developer (React or Vue developer) who will work on it together! My idea is a CRM like but we can change the idea completely. I am a junior Laravel developer, so no need to worry about the level. If you are interested or know anyone who is, let's build something together. The back end of the project is Laravel.

Thank you please sending a message to me at linkedin for talking about it: this is linkedin profile: https://linkedin.com/in/hirezadehghani

I'm interested to get's my hands dirty 😊😬

I can help if you want.

What do you need ?

Ok thank you ... if you have solved your problem, it would be nice to close the post ;).

Hi @vincent15000, yes, I'm using the Livewire package I found with a few tweaks of my own.

Thank you very much.

Hmmm ... I'm not convinced ... I just tried the demo, it's not very intuitive.

Furthermore if I need a builder to build an application, I can use WordPress with a builder like Divi.

I'm not sure that people who use Laravel really need a builder.

I think that a builder to automate some design patterns to be applied in specific cases could be more useful. But even in this case, today the IA can do this for you.

Does this kind of tool make sense in the Laravel ecosystem?

I’m not convinced this type of tool makes sense for the Laravel ecosystem without a very clear problem it is solving. Most Laravel applications I build start from requirements: business logic, workflows, data models, and permissions. I usually build the solution needed rather than start with a visual builder and try to fit the project into it.

Is the positioning clear enough?

The positioning is unclear. I don’t know who this is really for or what pain point caused it to be built. Is it for Laravel developers, agencies, SaaS companies, or non-technical users? A form builder, PDF builder, and email builder are useful features, but together they do not automatically solve a specific problem.

Would you consider using something like this in client projects or SaaS products?

I would be hesitant to use something like this in client projects. A closed-source visual builder adds another dependency and potential maintenance risk. I would need to see a strong reason why it saves more time than simply building the required functionality directly in Laravel/Filament.

What would make you trust or not trust a visual builder inside a Laravel app?

My biggest concerns would be trust, vendor lock-in, and complexity. A visual builder needs to prove that it reduces complexity instead of hiding it. I would want clear documentation, a migration path, good error handling, and confidence that the generated output remains maintainable.

Are there any red flags from a developer experience point of view?

The server crash that happened 10 minutes ago, is a red flag from a developer experience perspective. For a tool that is supposed to become part of a production application, reliability and transparency are critical.

Overall thoughts?

The idea is interesting, but I would need to understand the original problem behind the product. Good developer tools usually come from solving a painful, repeated problem. Without that, it feels more like a collection of features than a necessary part of a Laravel application.

Hey everyone,

I’ve been working during the last year on a project called Tagixo, and I’d really appreciate some honest feedback from other Laravel developers.

The idea behind Tagixo is to bring a more visual editing experience to Laravel applications, without trying to move everything away from the Laravel ecosystem.

In short, it’s a visual builder that lets you create and manage things like pages, forms, sliders and reusable content blocks, while still keeping the developer in control of the application structure.

The reason I started building it is that I often felt there was a gap between two worlds.

On one side, Laravel gives us a very solid backend and developer experience.

On the other side, clients and non-technical users often expect a more visual way to edit content, similar to what they are used to in tools like WordPress page builders.

I wanted to explore whether something like that could exist in a Laravel-native way, without forcing developers to give up control or turn the application into a “black box”.

I’m mainly looking for feedback on a few things:

Does this kind of tool make sense in the Laravel ecosystem? Is the positioning clear enough? Would you consider using something like this in client projects or SaaS products? What would make you trust or not trust a visual builder inside a Laravel app? Are there any red flags from a developer experience point of view?

There is a live demo available, so it can be tested without installing anything locally.

Website: https://tagixo.com

To be clear, I know visual builders are not for every project, and I’m not trying to suggest that every Laravel app should be built this way. I’m mostly interested in understanding where the community sees value, where it sees risks, and what would be needed for this kind of tool to feel trustworthy.

Any honest feedback would be really appreciated.

But what if I need to run a migration, then run a seeder, then run another migration, ... ?

If you are playing around, not a problem. But pls don't do this a real project. Eventually it will slow down CI/CD drastically.

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.

@vincent15000 Yes, that was a typo. I meant to write “horizontally scrollable”.

Show a warning near the table: this is best viewed in landscape mode, please rotate your smartphone.

When you say horizontally scalable, you mean scrollable ?

@vincent15000 Either make the table horizontally scalable, or stack the columns on smaller viewports.

Thank you for the suggestion. Unfortunately, it's not possible, because the table has to be read by column, each column is independant from the others. But it's a good idea for other cases.

You can collapse several columns of a row into one column where data is stacked vertically in one wide column.

See an example here: https://www.tabulator.info/examples/6.x/#responsive-layout-collapse

Ok thank you. Effectively I also generally show more columns on large screens and less columns on small screens.

The problem in my case is that I already have the minimum columns number. I can't show less columns.

The only solutions I have found (for small screens) is to scroll horizontally or to display each column as an independant card.

But there are perhaps other solutions ?

I normally just show the important columns visible, and if needed you have to scroll over. Or only show some columns and have a more detail view of a record if needed.

Hello @sigalz, have you solved your problem ?

Hello,

I have to show a table on a smartphone in portrait orientation.

The table can have from 2 to 5 or 6 columns.

If there are only 2 columns, it easy to do. But with 6 columns, the table is too large to be displayed correctly.

What are the different solutions for a good UX ?

Thanks for your help.

V

This involves to migrate only the first migrations, then a separate script to migrate the data, then continue with the last migrations.

I think that it's relevant if there are big databases with a lot of tables, but not with small projects, except if there are risks.

Looks like I missed general question, my apologies. Please provide more details, what exactly "doesn't work" means. Any errors? At which step?