No problem ;) ... I had written a datatable with Livewire in a project in the past.

Old code now.

If I'd have to write one again, I would try with VueJS or with AlpineJS.

No problem ;) ... I had written a datatable with Livewire in a project in the past.

Old code now.

If I'd have to write one again, I would try with VueJS or with AlpineJS.

Hi Vincent, Thank you very much, I didn't try it yet, I was busy with the Livewire package I found.

If you don't mind me asking, do you build your own datatables with Javascript? Livewire? Or anything else?

Curiousity killed the cat, thankfully, I'm not a cat... ;)

Hmm.. when I make that change it won't update as some other packages (like mailgun) require "dev".

That's not right. If we're talking about the mailer package, it definitely has stable releases.

What may have happened: since your composer file allowed dev versions, while installing the mailer you may have added a version constraint that doesn't yet exist as a stable release.

If you're worried about unstable versions, setting the constraint on a single package doesn't make the problem go away. Your project and all its dependencies can still install unstable versions. Even if laravel/framework itself is stable, dependency installed by it are not.

I'd switch to stable and fix the conflicting version constraints one by one.

What is minimum-stability set to in your composer.json file?

Hi All,

I did my daily "composer update" today and something caught my eye:

Upgrading laravel/framework (v13.16.1 => 13.x-dev 2107d3d): Extracting archive

Usually it will go from a version to a [higher] version not some weird dev branch.

To my knowledge I have not changed anything in my environment that would cause me to grab a developer branch and was wondering what's up.

Is anyone else seeing this?

(I am going to refrain from deploying this)

Thanks!

-Rob

Interesting:

"minimum-stability": "dev", "prefer-stable": true,

That's probably the issue, it's been like this for years from back to Laravel 6.

I have just never seen a dev branch come down before (maybe I never noticed).

Thanks, I will change to "stable".

Hmm.. when I make that change it won't update as some other packages (like mailgun) require "dev".

I did this and it seems to work:

"laravel/framework": "^13.2.0@stable",

@sigalz Have you tried my solution ? Does it work for you ?

Thanks @anishdhanka

@anishdhanka Thanks brother i was stuck from the past 3 months and could not find a solution.

@anishdhanka Hey again you saved us , i was working on this for about a week but could not figure it out finally after applying your way it worked ,thanks a lot

@Anishdhanka thanks brother worked for me

I spent 2 days trying to fix the issue, thank you very much man .. really

@Anishdhanka Thank you so much.

@Anishdhanka Thanks a lot it has helped to solve this problem!!

@Anishdhanka You have my thanks.

@Anishdhanka And me too! This was a problem in one application when I switched to Laravel Herd, and now it is fixed, thank you!

@Anishdhanka Thanks buddy

@Anishdhanka you saved me. After wasting a lot of time, finally, it worked. Though I need to set a value bit higher. But it worked.

@Anishdhanka Thank you very much!!!!!!!!

@Anishdhanka Saved the day!

@Anishdhanka your solution worked for me after wasting 4-5 hours i just found cookie is not generated and came across your solution and its worked thank you

@Anishdhanka Thank you so much, you saved my last nerves. Your comment really helped in my issue. All the best my friend i even registered just to say you my thanks. All the best

I have also faced the same issue. it took me several days to debug the problem . so its output buffer limit issue in php.ini. technically PHP sends output as bytes which missing Set-cookie header in the request due to limit. I updated output_buffering = 16384 in php.ini which worked for me.

I know this is an old conversation, but I just wanted to bring up @cronix mentioning being behind a load balancer or some other service in front of the server. This same issue just happened to me and we are using AWS Cloudfront in front our our ECS setup. We needed to setup Cloudfront to allow cookies to be forwarded. After we fixed that, we were good to go. Thanks for bringing that up @cronix !

I'm sorry, I really don't have any other ideas. :/

@Cronix

I only create an EC2 instance in AWS. I didn't use any load balancers or other services in front of the aws server.

That doesn't answer the question though. You can use load balancers and cloudfare and a number of other services in front of the aws server.

@Cronix

I am using AWS.

Are you behind a load balancer or another service like cloudfare? Is there anything between your server and the public internet?

@Cronix

Are sessions being generated in the db then? YES

Did you check the cookie domain? YES and set it as ".mywebsite.com"

Are any cookies being generated at all (check browser tools)? NO Cookies being generated. This is the problem.

Are you using php end tags in any of your files (you shouldn't)? NO

Are there any spaces or blank lines before the php open tag in your files? NO

Have you tried switching to the session file driver to see if that works? Tried before, but also not working.

Are sessions being generated in the db then? Did you check the cookie domain? Does it actually match your host name? Any errors in the logs, or in your browser console? Are any cookies being generated at all (check browser tools)? Are you using php end tags in any of your files (you shouldn't)? Are there any spaces or blank lines before the php open tag in your files? That could create output which could break cookie generation. Have you tried switching to the session file driver to see if that works?

@Cronix I am using database for the Session.

'driver' => env('SESSION_DRIVER', 'database'),

Are sessions being generated in /app/Storage/Framework/Sessions (assuming you're using the file driver)? Perhaps it's not able to create them (folder permissions?) so it can't generate the cookie? Is the cookie domain set properly in /config/Session.php?

As the title, the 'laravel_session' cookie is not set on the production server, and the form is failed to process.

I'm running Laravel version 5.6, PHP 7.2.4-1 and ubuntu16.04.1 on the production server.

However, I run the same code and setting locally in MAMP. it's working fine. The 'laravel_session' cookie is created automatically, and I can view it inside the browser.

I don't understand the objection. If you change something in the DB and need to convert data, it's better to run it chronologically in a migration rather than accumulate one-off Artisan commands. Relying on manual commands is bad if you have any kind of CI/CD pipeline or zero-downtime update process.

As for re-running migrations in dev and testing, what's the issue? You run schema changes and data changes together. Except with migrate:fresh there are usually no rows to modify.

Regarding seeding / data migrations, here's the opinion of one Laravel core developer: https://youtu.be/HNgDhZYg3VI?si=DVnuh4USmoL-pYEX&t=91

Thanks! I'll think about it. However for now I prefer to have code, data structure and data itself as separated as possible.

Manipulating data in migrations makes sense on production only.

I'm ok with this and it's exactly the case for me : no need to manipulate datas if the application is not in production.

But my question is about an application in production.

However my post was about understanding why it doesn't work and not about the relevance of manipulation datas inside a migration.

I have some thoughts against that.

Manipulating data in migrations makes sense on production only.

Migrations are "replayable" - they are applied one after another many times during development and testing. You can launch php artisan migrate:fresh hundred times while developing on your local dev machine. If you have data manipulation inside one of your migrations which data is actually manipulated on dev machine? And why? Testing/dev data is seeded many times (and AFTER all migrations, not among them), it doesn't need to "evolve" along with migrations.

To have "data migration" properly tested I have to seed database with various sets of data instead of only latest version. I have to track different data sets to always match with different DB schemas/migrations. I don't think this is worthwhile.

Therefore, I wouldn't place data manipulation inside migration. Instead I would use Artisan command which is launched manually on production only and one time only, after a corresponding migration is applied.

This package offers something similar: https://github.com/TimoKoerber/laravel-one-time-operations

Quote from description:

This package is for you if... ... you often seed or process data in a migration file (which is a big no-no!)

The way we described above - by using DB facade in migration - is the only way I know. So, we have no choice =)

@silencebringer @jussimannisto What could be the best way to migrate data when migrating database ?

As was mentioned before, migrations are about changing database SCHEMA, not the DATA. https://laravel.com/docs/13.x/migrations

Migrations are like version control for your database, allowing your team to define and share the application's database schema definition.

That's why I don't like the data changing in migration. But looks like Laravel do not suggest anything to archive the goals like in OP, that's why we do that in migration

Schema changes are the main use case, but there's nothing wrong with migrating data too. It's the easiest way to keep the application state consistent. The feature is called database migration, not schema migration.

@vincent15000

I used DB facade instead of Eloquent

That's the main point. Package::get() can fail in migration file unpredictably: imagine your Package model uses different table since some moment; but your old migration doesn't know about it. So, migrations chain fails (during tests or further development) or you have inconsistent data, both are bad.

DB::table('packages')->get() in migrations is more or less reliable, you operate on the same DB level at least.

Still, there is a thought you shouldn't operate with data in migrations at all, only tables structure.

I had similar task years ago: need to add not null column to existing prod db and fill it with (computed) value from related tables. While I don't like this approach, passing years I still can't imagine better solution

1. Add new nullable column
2. Run the query (I used DB facade instead of Eloquent, but actually that's no difference) which fills the column with the data
3. Make column "not null"

All of this inside one migration file.

I was not proud of this solution, but - as I told - I still do not not have better one.

It's exactly my case.

So why do you tell me that it's not a good idea ?

That sound completely normal to me. I've done it many times.

I'm ok with this.

But for an application in production, if I need to add some fields in a table in the database, there is sometimes datas to change inside the database.

Why in this case wouldn't it be a bad idea to add this code inside the migration ?

Where should I place it ?