I've done it on fresh Laravel + Fortify installation, out of curiosity. fortify.prefix config prepends URLs, not route names (which may be even more suitable for you):

Default Fortify routes:

PS C:\test> php artisan route:list

GET|HEAD  forgot-password
POST      forgot-password
GET|HEAD  login .........
POST      login .........
POST      logout ........
GET|HEAD  register ......
POST      register ......

Routes with 'prefix' => 'fortify/', in config/fortify.php:

PS C:\test> php artisan route:list

GET|HEAD  fortify/forgot-password
POST      fortify/forgot-password
GET|HEAD  fortify/login .........
POST      fortify/login .........
POST      fortify/logout ........
GET|HEAD  fortify/register ......
POST      fortify/register ......

https://laravel.com/docs/13.x/fortify#introduction

After installing Fortify, you may run the route:list Artisan command to see the routes that Fortify has registered.

Can you run route:list and point which routes you want to select?

update 1: Also you can see here which routes Fortify registers and select them by part of name or URL: https://github.com/laravel/fortify/blob/1.x/routes/routes.php

$fortifyRouteNames = ['login', 'logout', 'password', 'register', 'verification', 'user-profile-information', 'user-password', 'two-factor', 'passkey'];

// If route name starts with $fortifyRouteNames...

update 2: And more, here you can see Fortify registers it's routes with a prefix from config: https://github.com/laravel/fortify/blob/1.x/src/FortifyServiceProvider.php

protected function configureRoutes()
    {
        if (Fortify::$registersRoutes) {
            Route::group([
                // ...
                'prefix' => config('fortify.prefix'),

So I think you can publish Fortify config and set in config/fortify.php:

'prefix' => 'fortify.',

And all your Fortify routes names will start from fortify. and will be easy to catch.

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.

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.

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

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

I think you need sometimes rule instead of required. It applies only if the field under the rule is present in validated data.

https://laravel.com/docs/13.x/validation#validating-when-present

The process is more or less the same as described in Upgrade guide: https://laravel.com/docs/13.x/upgrade

First try composer require --dry-run and see errors. If there aren't, you're good. Otherwise deal with packages versions.

Of course it is always a good idea to backup code/data and run the whole process on some staging environment (copied from production maybe) first.

@jussimannisto How about suggest it to Laravel developers to make it built-in feature?

@glukinho I always add this to the createApplication() method of the base test case class:

if(!app()->environment('testing'))
	throw new \Exception('Tests are only allowed in the testing environment.');

That way you're never able to run tests in the wrong environment.

@kylef-fotf Interesting thing, Laravel's default composer.json already does it by default:

// composer.json

"scripts": {
        // ....
        "test": [
            "@php artisan config:clear --ansi",
            "@php artisan test"
        ],

I didn't know that.

So you should just launch tests with composer run test command and this caching problem is gone.

@kylef-fotf you can also create your own test Artisan command which executes config:clear beforehand. Or tune composer run test command to do so (see composer.json / scripts section). This way you never forget to clear cache before tests.

But why your config is cached in dev environment in the first place? It shouldn't be normally.

If that first command is forgotten, the database is gone.

Which database? Testing, dev or production? Purging testing database is normal behavior in standard Laravel workflow, it can be tuned to your wish of course.

First of all, try php artisan optimize:clear

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.