There are custom cases when Laravel server has direct access to network printers (connected to LAN). In that case you can send data directly to them which is tricky but doable.

I think it's impossible. Neither Laravel nor Javascript has access to user's local printers. You can only show printing dialog with JS window.print(), then user sees preview, picks desired printer, pages, copies etc and starts actual printing.

You can open different sections in separate tabs (beware user's browser can prevent opening pop-ups and new tabs) and even launch printing dialog automatically on page load:

<script>
    window.onload = function() {
        window.print();
    }
</script>

But only user himself should pick a printer and press "Print" button.

I think it depends on how often you end up doing this, and for the given case this is fine. Manipulating data in migrations is fine depending on the complexity and occurrence but I have seen this go wrong when you overdo it, now the new team member can't setup their local db bc the migrations are a mess.

The data you updated turned out to have a bug so now you either need to revert the migration on prod to run it again or create a new migration with no schema changes and just data updates.

Data updates are much more likely to fail midway due to data complexity of production and edge cases than predictable schema changes and now your production is down with half ran migrations.

A safer way would be a multi step migration/deployment (where possible assuming you have the time and resources)

First you change the schema to support both options, (like having the col nullable, adding a secondary column without removing the original, etc) and the business logic to fill new entries, while supporting old entries for now.

The second step would be to create a command to migrate the old data to the new structure.

And the third step, after you verify all data follows the new requirements, make the schema change the only option and fully deprecate the old logic, (like making the col non nullable, remove the command of step 2, deprecate old logic, etc)

It works already, see comments at the very top. However nothing wrong to chat a bit about some related things.

Laravel already has last_activity timestamp column in sessions table by default; I believe it updates on every request. Is that what you need?

Keep in mind old style Kernel scheduling may be dropped in one of upcoming versions and you will have problems with Laravel upgrades. Better settle it now, before big trouble comes.

Yes it would. Don't "fix" Laravel internal mechanisms, they work fine. Just use them.

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

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

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!)

You're right to update the data in the migration. The issue is the use of Eloquent model classes. You should instead use a query builder with hard-coded table and column names, e.g.:

$results = DB::table('packages')	
	->join('sites', 'packages.site_id', '=', 'sites.id')
	->selectRaw('packages.id as package_id, sites.client_id as client_id')
	->get();

(...)

DB::table('packages')->where('id', $result->package_id)->update([
	'client_id' => $result->client_id
]);

I wrote that off the cuff, so it may contain errors.

You don't know what's going to happen with the schema years later. The model will always try to use columns and relations from the latest schema, which may not match the database structure at this migration step.

If something changes about the Package -> Site relation, for example, then this migration step will fail: the Package model will try to use columns or tables that don't exist (yet).

@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.

Writing to the DB on every single request will definitely crush your database once you start seeing real traffic.

That's a massive hyperbole, unless your definiton of "real traffic" is thousands of requests per second. And then you're hitting other bottle necks first.

If Laravel accesses the DB during each request, e.g. by pulling a user model, the additional cost of updating a single timestamp is minimal. Most of the overhead comes from establishing a database connection.

Error text?..

Are you sure Eloquent in migrations is good? Migrations are about raw database tables/columns, Eloquent is about models which are "next level" compared to DB calls. Sometimes they align, sometimes not. You cannot guarantee your migrations chain is consistent and always replayed with this approach.

I believe you need something like this: https://github.com/TimoKoerber/laravel-one-time-operations

It's like migrations for data, not structure.

Laravel already has last_activity timestamp column in sessions table by default; I believe it updates on every request. Is that what you need?

Chrome - Development tools (F12) - Network shows all requests and payload types/sizes.

Removed the composite index $table->index(['connection', 'queue', 'failed_at']) from the failed_jobs table

This is strange. Removing this should bypass the error without much harm:

// database/migrations/0001_01_01_000002_create_jobs_table.php

Schema::create('failed_jobs', function (Blueprint $table) {
    // ...
    $table->index(['connection', 'queue', 'failed_at']); // <== remove this line
});

Are you sure of that?

Try to create new command from scratch:

php artisan make:command TestCommand --command=app:test

and define a schedule for it. Does it work?

Try to remove ->withSchedule() and define schedule in routes/console.php. Does it work?

Also please format code or command output by wrapping it with three backticks.

It sounds like it should work. Here are some things you could check if you're out of ideas:

1. Do you have anything funky in your app/bootstrap.php file, such as a custom ->withCommands() call?
2. Are you still manually registering a Kernel class somewhere? Search for occurrences of Kernel::class under app/ and bootstrap/.
3. You can always try running composer dump-autoload and php artisan optimize:clear, in case the autoload file or some caches are stale.

Are you registering the commands? In older versions it was done in app/Console/Kernel.php.

I did the same on fresh Laravel 12.62 and it works fine:

> php artisan make:command OverdueInvoicePenalty --command=overdue:invoice-penalty

   INFO  Console command [...\app\Console\Commands\OverdueInvoicePenalty.php] created successfully.


> php artisan list overdue

Available commands for the "overdue" namespace:

  overdue:invoice-penalty  Command description

Scheduling in app.php works too:

->withSchedule(function (Schedule $schedule) {
    $schedule->command('overdue:invoice-penalty')->daily();
})

> php artisan schedule:list

  0 0 * * *  php artisan overdue:invoice-penalty ...

Do you have something unwanted in bootstrap/app.php or app/Providers/AppServiceProvider.php or routes/console.php?

Ok, show command file and path to it. It should be under app/Console/Commands and command class should extend \Illuminate\Console\Command. Or you have to register a closure in routes/console.php.

Can you share the whole command file?

What php artisan list overdue gives you?

i have the signature defined correctly

Show it maybe? Without masked letters. Full command file is better.

This is wrong, localhost pages are considered secure along with https ones, for dev purposes. Clipboard should work locally.

I thought this is wrong solution as you have to have actual realization of methods and properties declared in an interface. Thinking this is not what you want as soon as they are hidden inside Laravel logic...

Look here: https://www.php.net/manual/en/language.oop5.interfaces.php

Properties

As of PHP 8.4.0, interfaces may also declare properties.

I didn't know that; maybe this is your solution? Apply an interface HasStatus to desired models, the interface should declare status property and status() method. There wil be some struggle about types though.

I can't say I like this solution but it's doable.

Sorry nothing comes to mind at the moment. Migrations are living structures, they evolve in time, they can squash into SQL file, so I can't even imagine where such contract may be applied.

What are you trying to achieve exactly? IDE autocompletion or just certainty about your models?

I don't see how interface concept fits here. An Eloquent model doesn't have its own contract, it follows an underlying table columns. Also PHP interfaces define methods, not properties, while Eloquent models operates with both methods and properties.

Maybe you want some sort of migrations contracts so tables all have desired set of columns?

How about that: every bid updates auction's closed_at to 10 seconds in future and pushes this information to clients via Reverb.

On client side you store and update closed_at for each visible auction. You hide an auction (or visually mark it closed) at desired moment if there were no updates for this auction, otherwise you postpone hiding. You may additionally request the backend for auction's current status right before hiding, just to be sure.

There can be issues with time sync between server and clients; to get them around you can send to clients "auction A closes in 10 seconds" instead of "auction A closes at 2026-06-11 12:34:56".

I don't know what exactly should happen on "auction close". But you can use another approach.

Let's say you have Auction model and you want an auction to close after 5 minutes of the last bid.

1. have closed_at timestamp field on auctions table
2. every bid updates auction's closed_at to 300 seconds in future

Then you have any auction closed in 5 minutes exactly after last bid, without queue at all. You can queue some related things like notifications if you need. Or, have a scheduled command every minute which gathers just closed auctions (where closed_at is less than 1 minute past) and does whatever you need.

And I should tell I don't see how it all is related to Reverb...

You're right, sleeping in code is not the best approach. Instead you can dispatch a job to some time in future:

CloseAuctionJob::dispatch($auction)->delay(300);

So the job will be actually executed by queue worker after 5 minutes (300 seconds). But you should know this is not guaranteed and the job may be run later, it depends on number of workers and number of jobs in a queue. This may be critical to your app.

https://laravel.com/docs/13.x/queues#delayed-dispatching

why not just unset those two keys in this component and not touch the rest? having to alter the rules to fit everything feels like a hack to me.

you shouldn't need to add 'sometimes' to your global rules, the place where the rules are used can decide what to do with the rules in it's particular case, like how and where to apply them.

Maybe it would be quicker to ask Forge support directly.

@kokoshneta can you provide actual data which is incorrectly validated?

@vincent15000

...unless a repository is placed on the same computer locally :)

Installer does some additional tuning for new app, such as disabling Pail on Windows installation. Since it's recommended and documented way to install Laravel it should work.

Did you try to uninstall / install laravel installer instead of updating?

It seems you just put in before logic that should be in actual create, viewAny, ...etc policies (you literally refer to them in your code), so I don't see the point here.

before is for cases that are completely out of a regular policy, for example "if a user is main admin then everything is allowed".

I'm also not sure if accessing route models directly through request() inside policies is considered good practice.

No, it's bad practice. Policies shouldn't know about your HTTP request, they just answer a question: can specific user do specific action or not?

Imagine your app is accessed other than via HTTP, let's say from console command. In that case calling request() in a policy is pointless.

Instead, you should apply a policy to a route with a middleware: https://laravel.com/docs/13.x/authorization#via-middleware

Laravel will take a user from a request and apply a policy to it.

Also I suggest comparing models using built-in method is():

if ($user->is($actualTrainer)) { ... }

Comparing integer ids is less readable and can be wrong when using multiple database connections. is() method handles it right way.

You are welcome.

Yes, something like this looks fine for me. You should agree this is clean and simple.

is it okay even if i repeat the code in most of policies?

If you extract code which defines actualTrainer to a private method (or public method of a model maybe) and refer to it in each policy - yes, it's fine. Just don't repeat complicated logic, extract it somewhere and reuse where you need it.

so, they should receive the extra information from the controller (or requests)?

Sorry I don't get what you mean.

It seems you just put in before logic that should be in actual create, viewAny, ...etc policies (you literally refer to them in your code), so I don't see the point here.

before is for cases that are completely out of a regular policy, for example "if a user is main admin then everything is allowed".

I'm also not sure if accessing route models directly through request() inside policies is considered good practice.

No, it's bad practice. Policies shouldn't know about your HTTP request, they just answer a question: can specific user do specific action or not?

Imagine your app is accessed other than via HTTP, let's say from console command. In that case calling request() in a policy is pointless.

Instead, you should apply a policy to a route with a middleware: https://laravel.com/docs/13.x/authorization#via-middleware

Laravel will take a user from a request and apply a policy to it.

Also I suggest comparing models using built-in method is():

if ($user->is($actualTrainer)) { ... }

Comparing integer ids is less readable and can be wrong when using multiple database connections. is() method handles it right way.

will have outdated Laravel 12 and packages

So what? Not all apps are required to be up to date and not all are even publicly accessed. Sometimes it's more important to have running app right now rather than playing with forking someone's packages.

What if you need a package which is not tuned for Laravel 13 yet? Then you have to use 12 or even older versions.

Packages dependency issues probably.

No, you can't be sure. The situation needs investigation, at least analyzing logs on all involved nodes.

Google for "499 nginx", it's quite common issue. I think you should ask Forge support.

I don't see why a developer wouldn't do it, properly rewarded especially.