2023 Laravel tip roundup – an incomplete list

Dozens of miscellaneous tips: https://laraveldaily.com/tips

Tighten’s Technical Debt Self-Assessment for Developers

Use Laravel Pint or Tighten Duster – they’re so easy to use (versus doing lots of manual PhpStorm configuration, for example) and you can add them as git pre-commit hooks which will only scan files that have changed, so they’ll be fast.

Pint is also useful for cleaning up things that used to be best practice, such as adding parameters to function DocBlocks, but which should now only be written directly in the code of the method itself.

The new Laravel Prompts are great. They are prettier (nice colours, borders and icons) and they neatly handle all the edge cases, including keeping the screen tidy if input validation fails and you need the user to enter an answer again, or if the script is aborted. There are placeholders and default options, and single and multi-select which support Vim keybindings. Each component is a namespaced function that is easy to insert.

If your app has no tests at all, start by doing some “smoke” tests to check all your main routes are functioning. These can be quite brittle.

Turn preventAccessingMissingAttributes on for your Eloquent models. (In dev only.)

Move from Laravel Collective to spatie/laravel-html if you haven’t already (in my experience you can convert <form> tags to plain HTML but you’ll probably still want the package for the convenience of coding select dropdowns and certain radio buttons and checkboxes.

In particular, check that you have @csrf on all your forms and directives like @method('PATCH') where you need them. If you can, write tests that your forms can be submitted. Use this automated Laravel Shift, it’ll save a lot of time but it definitely won’t do everything. You do need to test every form, unfortunately.

When writing tests in general, prioritise Feature tests over Unit tests. Save yourself time and increase accuracy by examining the view data you get back rather than using assertSee (which blindly scrapes the output). Laravel Dusk is handy for things you can only really check in a browser.

Using old hardware: if a Mac is no longer receiving software updates and consequently Homebrew is unreliable or takes ages to compile, consider using Macports instead, which, for example, still has the very latest PHP versions. (I found those were very quick to install and only MariaDB took 20 minutes+ to build from source.) You can also use artisan serve or even just PHP’s built in server (php -S). And for editing you have Nvim. I certainly wouldn’t do “serious development” an old machine, but it makes a great backup.

A short verbatim quote I enjoyed from Matt Stauffer’s “Laravel and in the enterprise” talk at this year’s Laracon (there’s plenty of other good stuff in the full thing):

“People imagine that if they do “API-first” they’ll build an API, they’ll build an SPA in front of the API, and later they’ll get a free mobile app API out of it and they’ll build the mobile app and it won’t be any work.

What happens in reality is it takes three times as long to build your web app as it would if you’d just used native technologies, you have to learn SPAs, you end up building an API that’s super, super super tightly integrated with your SPA and then one day if you do eventually maybe have a mobile app it turns out it doesn’t need the same API resources and routes that you built because you didn’t really build a true REST API you built one that served that SPA, and you just have a second API now.

So your web app took longer to build, it’s more complicated and you have two APIs.”

Matt Stauffer (Tighten)

(you can do a nice, simple SPA, including persisting elements like an audio player, with Livewire 3)

Troubleshooting empty Laravel Redis queue (cause: APP_NAME change)

Be aware that if you’re using Redis to handle a queue, don’t rename your APP_NAME environment variable while there are jobs on the queue, as they will all mysteriously disappear.

This is because the APP_NAME is used as a prefix to the Redis key, so Laravel will fail to find any jobs that have already been added.

'redis' => [

'client' => env('REDIS_CLIENT', 'predis'),

'options' => [
'cluster' => env('REDIS_CLUSTER', 'predis'),
'prefix' => Str::slug(env('APP_NAME', 'laravel'), '_').'_database_',

Source: config/database.php:116

Troubleshooting Laravel ‘Class log does not exist’ error

This is a common problem – the error is in Illuminate/Container/Container.php (line 736 or 741).

Forum thread

Common reason: spaces in environment variable values in .env file

Two other fixes that have worked for me:

  • after an apt-get upgrade on Homestead, installing the php7.0-mbstring package fixed it (Laravel needs four PHP extensions: OpenSSL, PDO, Mbstring and Tokenizer)
  • on another installation, changing syntax from:


    'production' === env('APP_ENV')

    in a ternary operator in config/app.php was the solution.


How to upgrade Laravel Homestead to PHP7

I wrote this StackOverflow answer, explaining how you can safely backup  your work, destroy the old PHP 5.6 Vagrant box and download a brand new one that comes with PHP 7 as standard.

In my opinion this will be easier and cleaner for most people than trying to perform an in-place upgrade (the exception is where you’ve extensively customised PHP, MySQL or Nginx, in which case you need to backup the appropriate config files too.)

There are also some notes on the format of Homestead.yaml when you have more than one site, as the documentation on shared folders isn’t terribly clear.