When you want to compare two database columns in Laravel, you can’t use where because it treats the argument you’re comparing to as a value.

Instead, Laravel has a whereColumn method you can use to compare a value to another column’s value.

// Retrieve posts that were updated after
// they were published.
 
Post::query()
    ->whereColumn('updated_at', '>', 'published_at')
    ->get();
// Retrieve posts that were updated after
// they were published.

Post::query()
    ->whereColumn('updated_at', '>', 'published_at')
    ->get();

When using whereHas in Laravel, it’s not uncommon to also eager load the relation using with.

$posts = Post::query()
    ->with('author')
    ->whereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();
$posts = Post::query()
    ->with('author')
    ->whereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();

Laravel also has a more succinct method that combines the two: withWhereHas.

$posts = Post::query()
    ->withWhereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();
$posts = Post::query()
    ->withWhereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();

Putting this in a blog post because I always forget.

To view PHP logs from Laravel Valet:

open ~/.config/valet/Log/php-fpm.log
open ~/.config/valet/Log/php-fpm.log

To view NGINX logs from Laravel Valet:

open ~/.config/valet/Log/nginx-error.log
open ~/.config/valet/Log/nginx-error.log

In Laravel, you can register a class as a singleton to always resolve the same object.

However, you might want to build another instance of the class. You could manually construct the class without Laravel’s container, but if it has a bunch of dependencies it can be tedious.

With the build method, Laravel won’t resolve a registered instance of the class, but build a new one with the container.

// AppServiceProvider::register()
$this->app->singleton(MastodonClient::class);
// AppServiceProvider::register()
$this->app->singleton(MastodonClient::class);

// Resolve the singleton instance from the container
$mastodon = resolve(MastodonClient::class);
 
// Build a new instance
$anotherMastodon = app()->build(MastodonClient::class);
// Resolve the singleton instance from the container
$mastodon = resolve(MastodonClient::class);

// Build a new instance
$anotherMastodon = app()->build(MastodonClient::class);

This can be useful when a Laravel package registers a class as a singleton but you need another instance.

Freek shares a few patterns we employ to let developers override behaviour in our packages.

One of the ways we keep maintenance burden low is by making our packages customizable. In this blog post, I’d like to cover some of our best tips to make a Laravel package easy to customize. Some of these tips will apply to regular projects as well.

Laravel 9 is fresh out the door, and it contains a small contribution of mine: a new callOnce method for database seeders.

Read more

An overview on view models in Laravel

Read more

The other day I needed to sort a dataset in MySQL and ensure one value was always at the end. I never fully understood how order by works, so I did some research on how to solve my problem and how order by behaves.

Read more

I use Model::findOrFail a lot in Laravel. Recently, I realized it’s not always the best option.

Read more

Our Blink package is marketed as a caching solution to memoize data for the duration of a web request. Recently, we came upon another use case for the package: to execute something once and only once.

Read more