Upgrading to PHP 8.4 with Laravel Forge
This week I decided to upgrade the SaaS product I'm helping build from PHP8.3 to PHP8.4. I'm not a huge fan of upgrading straight away, but I also didn't want to fall behind and given it's been out since November last year, I figured enough time had passed for any major issues to have been spotted and fixed.
First thing I did was made sure I had it running on my machine perfectly with 8.4. Thanks to Laravel Herd, switching locally to 8.4 was an absolute breeze. Once I was running the right version, I decided to run my test suite to see what I was dealing with and thankfully, it wasn't much. There was 2 issues to deal with, both of them were deprecations though, so I could've left them but I decided to get them sorted.
Firstly, I said goodbye to the worksome/envy
package. It's a great package to ensure that your .env.example file is up to date with what your codebase references, but that package depends on thecodingmachine/safe
, which when running on 8.4 spits out an absolute ton of deprecation warnings, such as:
Deprecation Notice: Safe\gmdate(): Implicitly marking parameter $timestamp as nullable is deprecated,
Deprecation Notice: Safe\mktime(): Implicitly marking parameter $minute as nullable is deprecated, the explicit nullable type must be used instead
Deprecation Notice: Safe\preg_replace(): Implicitly marking parameter $count as nullable is deprecated, the explicit nullable type must be used instead
Imagine that, but a couple of 100 warnings whenever you run anything in terminal for the application, pretty annoying! Getting rid of worksome/envy
stopped those from showing. It's a useful package and if the deprecations are ever fixed, I'll probably re-install it.
Secondly, the spatie/laravel-sitemap
package was giving a deprecation warning too:
{closure:Spatie\Sitemap\SitemapGenerator::__construct():48}(): Implicitly marking parameter $response as nullable is deprecated, the explicit nullable type must be used instead
This is a package I did need to keep, so I set about getting rid of that warning and submitted the following PR:
Freek accepted the PR, merged it and then tagged a new release of the package which I then pulled down and just like that, no more deprecation warnings!
I re-ran my test suite and made sure all my tests were passing, I also manually went through my application just to double check everything was working as intended and then created a Pull Request to merge my couple of changes into the main
branch.
On the Laravel Forge side, I had to install 8.4 on the server as it only had 8.3 available. Once that's done, I went through all 3 sites on the server (production, demo and staging) and swapped them to use 8.4 and I then deleted 8.3 completely as there was no need for it. Afterwards, I merged my PR and let Forge auto deploy it for me!
Done!
Or so I thought...
After a short time, our uptime monitor OhDear started alerting me for missed scheduled tasks. I totally forgot that I had a few scheduled jobs set up within Forge, that were referencing 8.3 still. I quickly swapped them over to run on 8.4 and OhDear then stopped sending alerts. I figured it would be good for Forge to be a bit stricter here, ideally I should've not been able to delete 8.3 because it had some dependants. That, or, Forge should have notified me when I tried to delete it that it had some dependants. I reached out to James Brooks at Laravel to ask if it would be possible to add something for this, and he said there's something already in the pipeline for it, which is great as I can definitely see myself doing this again!
Awesome! Is there an "official" way to suggest a feature?
— Jon Purvis (@JonPurvis_) January 30, 2025
I upgraded PHP the other day to 8.4 and removed 8.3, but I forgot I still had workers running on 8.3 and only realised because OhDear alerted me some time later.
Could we perhaps get an alert for stuff like this? 😀
Overall, upgrading to 8.4 from 8.3 was painless and took no time at all. If you're still running anything older than 8.4, get yourself upgraded!