Laravel on PHP 8.5: what actually breaks

Laravel’s support table lists PHP 8.5 for Laravel 12 and 13 only. A cabinet manufacturer’s system we upgraded runs on Laravel 13 and PHP 8.5, so this isn’t a theoretical combination.

Watch out for what Composer allows. The framework’s PHP requirement is open-ended (^8.2 on Laravel 11), so Composer will install Laravel 11 on PHP 8.5 even though Laravel doesn’t list that pairing. A clean install tells you nothing here.

Laravel sends PHP deprecations to its own log channel, and in the current skeleton that channel defaults to null. Unless you’ve set it, they go nowhere. On staging, add this to your .env:

LOG_DEPRECATIONS_CHANNEL=single
LOG_DEPRECATIONS_TRACE=true

The trace matters, as it tells you whether the caller is your code or a package in vendor. Run your tests and click through your main flows, then read the log. Deprecated code keeps working today, but PHP’s pattern is to remove deprecated features in a later major version, so you’re clearing tomorrow’s fatal errors.

PHP 8.5 deprecates the driver-specific PDO constants, and that reaches the framework’s own config file. Laravel’s skeletons show the change clearly: the 11.x file uses PDO::MYSQL_ATTR_SSL_CA, the 12.x file checks the PHP version, and the 13.x file uses the new name alone. Upgraded applications keep their old config unless someone changes it, so yours may still have the 11.x line even on Laravel 13.

While you still need to run on older PHP, use the form from the 12.x skeleton, in both the MySQL and MariaDB blocks:

use Pdo\Mysql;

// In the 'options' array of each connection:
(PHP_VERSION_ID >= 80500 ? Mysql::ATTR_SSL_CA : PDO::MYSQL_ATTR_SSL_CA) => env('MYSQL_ATTR_SSL_CA'),

The other PDO names follow the same pattern. If your code sets PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, PDO::MYSQL_ATTR_INIT_COMMAND or an SSL option, search for MYSQL_ATTR_ across the project. Older calls on the PDO object itself, such as sqliteCreateFunction() and pgsqlCopyFromArray(), are deprecated too.

This is our selection from php.net’s list, chosen for how often these patterns appear in application code.

Most of these are quick to fix once you’ve found them. The null array offset is the exception. It usually points at a value that was never meant to be null, so fixing it properly means working out why it is.

These come from php.net’s backward-incompatible changes. They’re the items more likely to show up as a real difference rather than a log line.

• Float to integer casts. Casting a float that can’t be represented as an integer now raises a warning. With Laravel’s error handler, a warning in the wrong place becomes an exception, so check imports and calculations that handle very large numbers.
• Destructuring non-arrays. [$a, $b] = $value raises a warning when $value isn’t an array, except for null.
• Session keys. A $_SESSION key containing | now raises a warning. Laravel manages its own sessions, so this mainly affects older code that uses native PHP sessions directly.
• PDO fetch modes. Using PDO::FETCH_PROPS_LATE without PDO::FETCH_CLASS, or PDO::FETCH_INTO in fetchAll(), now throws a ValueError. Eloquent doesn’t need you to set these, so only hand-written PDO code is affected.
• OPcache config. OPcache is now always built in, so a leftover zend_extension=opcache.so line in your PHP config emits a warning. Fix it in the server image.

Run composer why-not php 8.5 to see any package with a PHP ceiling. Few have one: inertiajs/inertia-laravel 1.x is an example, as its constraint stops at 8.4. A package with an open-ended constraint will install either way, whether or not its maintainer has tried PHP 8.5. That’s why the deprecation log is a better test than Composer. Our package compatibility matrix shows each constraint, and the PHP matrix covers the framework side.

If you’re moving off PHP 8.2 before its deadline and want the simplest route, PHP 8.4 means fewer changes and still has support until the end of 2028. PHP 8.5 buys another year, to the end of 2029. It makes sense if you’re already doing a larger upgrade and would rather clear the deprecations once, while someone is already reading the code.