The Platform API runs Laravel 10 and should be updated to Laravel 11 which was released March 12th 2024: https://laravel.com/docs/11.x/upgrade#main-content
Laravel 10 reached EOL February 4th 2025 (https://laravel.com/docs/11.x/releases)
Steps to do this include:
- read through the official upgrade guide
- update composer packages - see Upgrade Guide Steps section below
- Remember to view the release notes / update guide of any other dependencies that also need updating and update this task description
- address issues in upgrade guide - see Upgrade Guide Steps section below
- adapt the codebase to breaking or deprecated changes
Upgrade Guide Steps
Here are all the headings from https://laravel.com/docs/11.x/upgrade and either what we need to take or what we need to investigate further. We will cross these out as we go.
- Updating Dependencies
- PHP 8.2.0 Required
- No action required - already on latest version
- curl 7.34.0 Required
- No action required - the PHP image we are using currently contains 7.74.0-1.3+deb11u3
- Composer Dependencies
- Action required - update the following:
- Update laravel/framework
- Update laravel/passport - see the more detailed section below
- Action required - update the following:
- PHP 8.2.0 Required
- Application Structure
- No action required - docs recommend not changing the structure if migrating from Laravel 10.x
- Authentication
- Password Rehashing
- No action required - we use the default column name
- The UserProvider Contract
- No action required - we don't use the UserProvider interface
- The Authenticatable Contract
- No action required - we use the default User model
- The AuthenticationException Class
- No action required - we are not using the AuthenticationException::redirectTo() method
- Email Verification Notification on Registration
- No action required - we are manually registering the event in config/app.php#L180
- Possibility for us to open a ticket to work on in the future to do this in a Laravel native way
- Password Rehashing
- Cache
- Cache Key Prefixes
- No action required - we might have some redis cache misses on deployment, but they will warm up again without any manual intervention
- Cache Key Prefixes
- Collections
- The Enumerable Contract
- We don't use the dump() method
- The Enumerable Contract
- Database
- SQLite 3.26.0+
- No action required - we don't use SQLite
- Eloquent Model casts Method
- No action required - we haven't implemented any casts() methods on our models
- Modifying Columns
- Action required:
- Squash previous database migrations using php artisan schema:dump
- We thought about how this impacts the ToU changes and this comment on T407722: 📜 Fix Terms Of Use database migrations
Can we exclude the ToU migration in the schema:dump command, so that we can revert this migration if needed?- We decided that we can drop the ToU DB Table in our next migration (rather than rolling back the previous migration).
- Action required:
- Floating-Point Types
- No action required
- we don't use $total or $places in any of our database migrations
- we don't use unsignedDecimal, unsignedDouble, or unsignedFloat methods in any of our database migrations
- No action required
- Dedicated MariaDB Driver
- Action required
- Use the new mariadb driver
- Nothing required for uuid since we don’t seem to use them
- Action required
- Spatial Types
- No action required - we don't store any spatial data
- Doctrine DBAL Removal
- Action required
- Remove Doctrine DBAL - investigate further steps required
- Action required
- Deprecated Schema Methods
- No action required
- We don't use any of the Schema::getAllTables(), Schema::getAllViews(), or Schema::getAllTypes() methods
- We don't implement our own ConnectionInterface
- No action required
- SQLite 3.26.0+
- Dates
- Carbon 3
- Not required for Laravel 11.x update; will be required for Laravel 12.x update
- Decided to only do after all the other parts
- T426592: ⏫ Audit Carbon 3 behavioral changes in date calculations after Laravel 11 upgrade
- Carbon 3
- Mail
- The Mailer Contract
- No action required - we don't use this interface ourselves; we trust that the packages we depend on will handle this update correctly
- The Mailer Contract
- Packages
- Publishing Service Providers to the Application
- We don't publish any Laravel providers
- UPDATE: however we do create some of our own providers and register them in config/app.php.
- Action required
- Create a ticket to investigate if we can remove some of the manually defined providers from the Autoloaded Service Providers array e.g. Laravel\Tinker\TinkerServiceProvider::class. We should read the docs for each of the service providers to see what they do. T427482: Laravel: Investigate Autoloaded Service Providers
- We tried moving the providers array from config/app.php to bootstrap/providers.php as indicated the Laravel 11.x Service Provider docs, but we had lots of failing PHPUnit tests and couldn't easily figure out why. The providers array in config/app.php is maintained in Laravel for now. We will have to keep an eye out for if this gets deprecated in a future Laravel update.
- We don't publish any Laravel providers
- Publishing Service Providers to the Application
- Queues
- The BatchRepository Interface
- No action required - we don't implement the BatchRepository interface
- Synchronous Jobs in Database Transactions
- Action required
- Investigate further
- There seems to be a sync queue driver defined in config/queue.php#L16
- Is the sync queue driver is actually used?
- Yes, but only in the docker compose setup. In k8s we always pass redis as the queue type.
- Is the after_commit configuration option is used or afterCommit() method is invoked?
- No, we don't use after_commit or afterCommit()
- Investigate further
- Action required
- The BatchRepository Interface
- Rate Limiting
- Per-Second Rate Limiting
- No action required - we don't use the GlobalLimit or Limit classes
- Per-Second Rate Limiting
- Cashier Stripe
- No action required - we don't use Stripe
- Spark (Stripe)
- No action required - we don't use Stripe
- Passport
- Updating Passport
- Action required:
- Publish the database migrations with php artisan vendor:publish --tag=passport-migrations when updating to laravel/passport:12.x
- Investigate if we need to publish the database migrations with php artisan vendor:publish --tag=passport-migrations
- We need to do this when updating to laravel/passport:12.x
- Investigate further if "the password grant type is disabled by default" change will affect us
- We don't use "password grant type", so no action required
- Action required:
- Updating Passport
- Sanctum
- No action required - we don't use Sanctum
- Telescope
- No action required - we don't use Telescope
- Spatie Once Package
- No action required - we don't use Spatie Once
- Miscellaneous
- View the changes in the laravel/laravel GitHub repository
- Will be done as part of T426957: Adjust the Platform API to follow the default application structure
- View the changes in the laravel/laravel GitHub repository
Other changes required when updating to Laravel 11.x
Here are tasks we know we need to do when updating to Laravel 11.x that aren't covered by the upgrade guide:
- Update absszero/laravel-stackdriver-error-reporting configuration (see the README)
- Don't need to update the configration currently. Becuase we are relying on the Laravel 11.x compatability layer we are esentially configuring this dependency as if we are a Laravel 10.x application. When we do T426957: Adjust the Platform API to follow the default application structure we will need to update this absszero/laravel-stackdriver-error-reporting configuration.
How shall we split this task up?
- In the past this has always been a non-parallelizable task
- Some devs could start doing the update of the known steps, while others look at the investigation steps
- Alternatively, as there are only 3 of us working, we could do mob programming (and "pass the development staff"). We will need to be very diligent at pushing changes at the end of sessions.