DEV Community: devTalk

Laravel Eloquent Serialization: Hidden, Appends, Dates

devTalk — Fri, 23 Oct 2026 16:01:59 +0000

The easiest Laravel API is one line: return User::all();. Eloquent turns the models into JSON for you. That convenience is also where leaks and slow endpoints start: a password hash in the response, a date in a format your frontend does not expect, or an "extra" computed field that quietly fires a query per row. This article walks through how Eloquent serialization works in Laravel 13, using the official documentation as the map and a real database to test the parts that surprise people.

The basics: toArray() and toJson()

$user = User::with('roles')->first();

$user->toArray();             // attributes + loaded relationships, recursively
$user->attributesToArray();   // attributes only, no relationships
$user->toJson();              // JSON string
$user->toJson(JSON_PRETTY_PRINT);

(string) $user;               // same as toJson()

I confirmed that casting a model to a string produced exactly the same text as toJson(). According to the docs, models and collections returned from a route or controller are converted to JSON automatically. I did not run a real route, so that part is from the documentation.

One detail that trips people up: a loaded relationship appears in the output under a snake_case key even though the method is camelCase. My blogPosts() relationship showed up as blog_posts.

Hide sensitive attributes

In Laravel 13 the documentation uses the Hidden attribute (the older $hidden property is the same idea):

use Illuminate\Database\Eloquent\Attributes\Hidden;
use Illuminate\Database\Eloquent\Model;

#[Hidden(['password', 'remember_token'])]
class User extends Model
{
    // ...
}

Test result: toArray() returned id, name, email, birthday, created_at, updated_at and no password or token. Two important limits, both confirmed:

Hidden only affects serialization. $user->password still returned the hash, and getAttributes() still contained it. It stops the leak in JSON output, nothing more.
You can hide a relationship by name too. Hiding blogPosts removed blog_posts from the output.

Or use an allow list with Visible

If you would rather list what is allowed, use #[Visible([...])]. With #[Visible(['name', 'email'])] the output was exactly name and email. An allow list is safer for models that grow over time, because a new column added later stays out of the API until you add it on purpose.

Change visibility at runtime, and the gotcha

$user->makeVisible('password')->toArray();
$user->makeHidden('email')->toArray();
$user->mergeHidden(['name', 'email'])->toArray();
$user->setHidden(['email'])->toArray();   // replaces the whole hidden list

The docs describe these as changes for "one instance", and that is the catch: they modify the model object itself. I called makeVisible('password') and then called toArray() on the same object again, and the password was still there. A fresh query returned a clean model with the password hidden. So never reuse a model after exposing a field for one response, for example by caching it or passing it to other code.

Also note that setHidden(['email']) replaces the list, so the password and token came back, and only the email was hidden. Use mergeHidden() when you want to add to the existing list.

Add computed values with appends

A value that has no column needs an accessor first. Then add it to the output with the Appends attribute, using the snake_case name:

use Illuminate\Database\Eloquent\Attributes\Appends;
use Illuminate\Database\Eloquent\Casts\Attribute;

#[Appends(['is_admin'])]
class User extends Model
{
    protected function isAdmin(): Attribute
    {
        return Attribute::get(fn () => 'yes');
    }
}

The output contained is_admin: "yes". For a single response you can use $user->append('is_admin') (also worked), and $user->withoutAppends() removed the field again. The docs add that appended values still respect your Hidden and Visible settings. In my test the allow-listed model, which listed only name and email, did not show an appended is_admin either.

The hidden cost: appends can create N+1 queries

An appended accessor runs for every model in the result. If it touches the database, you pay for it once per row. I appended a post_count accessor that called $this->blogPosts()->count() and serialized 3 users: 4 queries, one for the users and one per user. With 500 users that is 501 queries. The alternative is to let the database count in the same query:

User::withCount('blogPosts')->get()->toArray();
// 1 query, and the output has a blog_posts_count field

Keep appended accessors cheap and based on data the model already has.

Control date formats

By default, dates are serialized in ISO 8601 form. My created_at came out as 2026-01-01T10:00:00.000000Z. To change it for a single column, give the cast a format:

protected function casts(): array
{
    return [
        'birthday'  => 'date:Y-m-d',
        'joined_at' => 'datetime:Y-m-d H:00',
    ];
}

To change every date on the model, override serializeDate():

use DateTimeInterface;

protected function serializeDate(DateTimeInterface $date): string
{
    return $date->format('Y-m-d');
}

With that override, created_at became 2026-01-01. The stored database value of birthday was unchanged by the cast format: formatting affects only array and JSON output, as the docs say.

When to move to API resources

The documentation itself points to Eloquent API resources for more robust JSON output. Serialization is great for internal tools and simple endpoints. Once your API response needs a stable shape that differs from your table structure, versioning, or conditional fields, a resource class is clearer than a pile of makeHidden() calls.

Quick checklist

Passwords, tokens and internal flags: Hidden, or better, an allow list with Visible.
Remember that hidden does not stop direct access like $user->password.
makeVisible() and makeHidden() change the object, so do not reuse it.
Appended accessors run per row: avoid queries inside them.
Date format: per-column in casts(), or everywhere with serializeDate().

References

Laravel 13.x documentation: Eloquent Serialization

Originally published on DEV Talk.

Laravel Token Guard Auth Bypass: Check and Fix

devTalk — Fri, 23 Oct 2026 14:46:35 +0000

A critical vulnerability in Laravel's built-in token API guard lets an unauthenticated visitor log in as an existing user without knowing that user's token. The Laravel team fixed it in August 2026, but the advisory only went public on 19 October 2026, and details and a public proof of concept followed within days. It is rated CVSS 9.2. Most modern Laravel apps are not exposed, because the guard has to be switched on in your config, but if yours is, this is a same-day update. Below: who is affected, a 2-minute check, the fix, and why it happens. I confirmed the root cause on a real MariaDB database and compared the code before and after the fix.

The short version

What: authentication bypass in Illuminate\Auth\TokenGuard, tracked as GHSA-f9x3-7vq9-cph6, CVSS v4.0 9.2.
Who: apps that use a guard with 'driver' => 'token' in config/auth.php, with users stored in MySQL or MariaDB.
Fix: update laravel/framework to 13.29.0 or newer (13.x), or 12.68.0 or newer (12.x).
Not listed as affected: Sanctum and Passport, which register their own guards. The session guard is not listed either.
Exploitation: a public proof of concept has been reported. As of the latest report I found (Cyber Kendra, 21 October), no attacks in the wild had been seen.

Step 1: check whether you use the token guard

# 1. Is a guard using the token driver?
grep -n "'driver' => 'token'" config/auth.php

# 2. Which framework version is installed?
composer show laravel/framework | grep versions

# 3. Does Composer already know about this advisory?
composer audit

If the first command prints nothing, you are not using the vulnerable guard. Also check routes protected with something like auth:api and make sure that guard is not the token driver. Older Laravel skeletons (up to about Laravel 7) shipped an api guard with the token driver, so long-lived apps are the most likely to still have it. If composer audit lists GHSA-f9x3-7vq9-cph6, you have the confirmation.

Step 2: update

composer update laravel/framework
composer show laravel/framework | grep versions

You want 13.29.0+ on Laravel 13 or 12.68.0+ on Laravel 12. Then deploy and restart your PHP workers. The advisory offers no other workaround, so do not treat a rule in a firewall as a replacement.

Versions: what I verified in the source

Sources disagree on version details, so I compared the actual code in the tagged releases. The fix is a type check in TokenGuard.php:

Release	Has the `is_string()` check?
13.26.1 and older	No
13.27.0, 13.28.0, 13.29.0	Yes
12.67.0	No
12.68.0	Yes
11.56.0	No
11.56.1	Yes
10.49.0	No

The code change appears from 13.27.0 on, but the advisory and Laravel News list 13.29.0 as the fixed version for Laravel 13, so move to 13.29.0 or newer and you are covered either way. The fix commit is dated 24 August 2026 and the releases 25 August 2026. On Laravel 11, one report says no patch exists while another lists 11.56.1; the source shows 11.56.1 does contain the check. On 10.x, the release I checked (10.49.0) has no fix, so check the advisory for your branch or upgrade to a supported version.

Why it happens

The explanation below follows the published analysis, and I tested each link in the chain.

Before the fix, the guard only checked that the incoming token was not empty. It did not check that it was a string.
A non-string value, such as a list, passes that check and reaches the user lookup, where it is turned into a database query with a list of values.
MySQL and MariaDB compare text columns with numbers by converting the text to a number, and text that does not start with a digit becomes 0.

Step 3 is easy to confirm yourself without any exploit. On MariaDB, with two users whose tokens start with letters, I ran three queries:

Query	Rows matched
`where api_token = 0`	2 (every user)
`where api_token in (0)`	2 (every user)
`where api_token = '0'`	0

A numeric value matched every row, and the same value as text matched none. So a non-string "token" can match a real user's row, which is why the guard authenticates someone who never knew the real token. According to the analysis, the attacker cannot choose which user they become, but that is little comfort when one of them is an admin. This is also why the advisory is specific to MySQL and MariaDB; I did not test other databases, so I cannot tell you they are safe.

I also compared the guard code before (13.26.1) and after (13.29.0), using a stub user provider that records what reaches the database. Before the fix, a non-string token was passed to the provider and the guard resolved a user. After the fix, validate() returned false, user() returned null, and nothing non-string reached the provider. That is a unit-level check with a stand-in provider, not a test against a running app.

What about hashed tokens?

If your guard has 'hash' => true, an array token makes PHP's hash() throw a TypeError in the user() path (I confirmed that call fails with an array). That produces an error instead of a match, but the advisory does not exempt hashed setups, so update regardless.

If you can't update today

There is no official workaround. The practical steps are to check whether you really use the guard, and if you do not need it, remove the token guard from config/auth.php so no route can use it. In the longer term, consider moving API authentication to Sanctum, which is not listed as affected. Review access logs for unusual successful logins on token-protected routes, and treat accounts that never should have been reachable as suspect.

A second, smaller fix in the same release

Laravel News also reports a medium-severity issue (CVSS 6.5, GHSA-5wcm-3v2w-8362) in the JSON:API resources added in Laravel 12.45, where a read-only request could trigger a destructive operation on a related table. It is fixed in 13.27.0 and 12.68.0, so the same update covers it. I did not test this one.

Sources

Originally published on DEV Talk.

PHP file_exists() vs is_file(): Directory Bug Explained

devTalk — Fri, 23 Oct 2026 02:18:42 +0000

Here is a bug that passes every test until a user without a profile picture shows up. You build an image path from a folder and a filename, check file_exists(), and serve the image. For users with no filename saved, the filename is empty, so the path points at the folder itself. The folder exists, so the check passes, and your code tries to serve a directory as if it were an image. The fix is one word: is_file(). I reproduced the bug on PHP 8.3.6 so you can see exactly what happens next.

The bug in four lines

$dir    = __DIR__ . '/uploads/avatars/';
$avatar = '';   // this user never uploaded one

if (file_exists($dir . $avatar)) {
    // we get here, even though there is no image
}

This is not a PHP quirk, it is what the function is documented to do. The PHP manual describes file_exists() as checking "whether a file or directory exists." The name says file, but the behavior is "anything at this path."

One detail the tip leaves out

An empty string by itself does not pass: file_exists('') returned false in my test. The trouble starts when the empty value is joined to a directory path. 'uploads/avatars/' . '' is just 'uploads/avatars/', and that is a real folder. The same happens when the filename is null: (string) null is an empty string, so the join gives the same result. Real code hits this with things like public_path('images/' . $user->avatar) when avatar is empty.

What each function says about the same paths

I ran four checks on a set of paths. This is the real output:

Path	file_exists	is_file	is_dir	is_readable
`uploads/avatars/` (folder + empty name)	true	false	true	true
`uploads/avatars/ada.png` (real file)	true	true	false	true
`uploads/avatars/nope.png` (missing)	false	false	false	false
`''` (empty string)	false	false	false	false
`.` and `..`	true	false	true	true
Symlink to a file	true	true	false	true
Symlink to a folder	true	false	true	true
Broken symlink	false	false	false	false

Two things to notice. First, is_readable() is not a fix: it is also true for the folder. Second, is_file() follows symlinks, as the manual says, so a symlink to a real file still counts as a file. A broken symlink is false for everything.

What happens when the check wrongly passes

The bug is not just a wrong boolean. I took the passing directory path and ran the usual next steps:

file_get_contents($dir) returned an empty string and emitted a warning: "Read of 12288 bytes failed with errno=21 Is a directory". Your page gets an empty image with a 200 status.
getimagesize($dir) returned false, which can break code that expects an array.
readfile($dir) returned -1 and printed nothing.
unlink($dir) failed with "Is a directory". That is safe here, but a "delete the old file" step that quietly does nothing is its own bug.

In a download or image endpoint, this means broken images, empty responses, or log files full of warnings, all from a check that looked correct.

The fix

$path = $dir . $avatar;

if ($avatar !== '' && is_file($path)) {
    // safe: a real file with a name
} else {
    // show the default avatar
}

is_file() returns true only for a regular file, so the folder case now correctly gives false. I added the explicit empty-name check as well, because it states the intent and avoids a pointless disk lookup, but is_file() alone already fixes the bug. Use is_dir() when you actually mean a folder, and keep file_exists() for the rare case where either is acceptable.

Laravel: same trap, same fix

Laravel's helpers map straight onto these functions. In the framework source, File::exists() calls file_exists() and File::isFile() calls is_file(), so the same rule applies:

use Illuminate\Support\Facades\File;

File::exists(public_path('images/' . $user->avatar));   // true for the folder when avatar is empty
File::isFile(public_path('images/' . $user->avatar));   // false

The storage layer has a similar split. In the source, Storage::exists() is documented as "Determine if a file or directory exists," and there are separate fileExists() and directoryExists() methods. I read this in the source and did not run it, because that needs the full Flysystem setup. If your path may be empty, use fileExists() for files.

Two more things worth knowing

Results are cached. The manual notes that both functions cache their results within a request. If your script creates or deletes a file and checks again, call clearstatcache() first.
nullis deprecated. On PHP 8.3, file_exists(null) and is_file(null) both returned false and raised a deprecation notice: "Passing null to parameter #1 ($filename) of type string is deprecated". Make sure your filename variable is a string.

References

Originally published on DEV Talk.

structuredClone vs JSON.stringify vs Spread: Deep Copy Guide

devTalk — Thu, 22 Oct 2026 15:41:08 +0000

Sooner or later every JavaScript developer copies an object, changes the copy, and finds the original changed too. The usual fixes are the spread operator, the old JSON.parse(JSON.stringify(obj)) trick, and the newer structuredClone(). They look interchangeable. They are not, and the differences show up as bugs only when your data contains dates, sets, undefined, or a circular reference. I ran all three on Node 22 and in Chromium, and checked the behavior against MDN, so you can see what each one really does.

Why a plain copy is not enough

Spread ({...obj}) and Object.assign make a shallow copy: top-level values are copied, but nested objects are shared. I copied an object with spread and pushed to a nested array on the copy:

const original = { nested: { list: [1, 2] } };
const copy = { ...original };

copy.nested.list.push(3);

console.log(original.nested.list);   // [ 1, 2, 3 ]  - the original changed

If your object has nested data and you plan to change it, you need a deep copy.

The JSON trick, and what it quietly destroys

JSON.parse(JSON.stringify(obj)) works by turning your data into text and back. That means anything JSON cannot represent is changed or lost. These are real outputs from Node 22:

Value	JSON round-trip	structuredClone()
`Date`	Becomes an ISO string	Stays a real `Date`
`undefined` property	Key disappears	Kept
`NaN`, `Infinity`	Become `null`	Kept
`Set`, `Map`	Become `{}`	Cloned correctly
`RegExp`	Becomes `{}`	Cloned, flags kept
`BigInt`	Throws a TypeError	Cloned
Circular reference	Throws a TypeError	Cloned, cycle preserved
Function property	Silently dropped	Throws `DataCloneError`
`-0`	Becomes `0`	Kept

The dangerous rows are the silent ones. A Date turning into a string, or a Set turning into {}, does not throw anything. Your code just breaks later, somewhere else.

structuredClone(): the built-in deep copy

const order = {
  id: 7,
  createdAt: new Date('2026-01-01T00:00:00Z'),
  tags: new Set(['paid', 'gift']),
  note: undefined,
};

const copy = structuredClone(order);

copy.createdAt instanceof Date;   // true
copy.tags instanceof Set;         // true
'note' in copy;                   // true

It handles circular references too, and keeps shared references shared. When I cloned { a: shared, b: shared }, the clone's a and b were the same object, but a different object from the original shared. MDN lists it as widely available in browsers since March 2022, and I confirmed it exists in Node 22 and in Chromium 141.

What structuredClone() cannot do

Functions throw. structuredClone({ fn() {} }) raised a DataCloneError (a DOMException). The same happened for a Promise and a WeakMap. A Symbol value throws too, though a Symbol used as a key is silently skipped. In a browser, DOM nodes throw as well, which I confirmed with document.body.
Class instances lose their class. I cloned new User('ada') and got a plain object with name only. It was not an instanceof User, and the greet() method was gone. MDN says the prototype chain is not walked or duplicated.
Getters become plain values. An object with get x() { return 5 } was cloned as { x: 5 }, a normal writable property. Property descriptors are not copied.
Non-enumerable properties are dropped.

If you need to copy class instances, write a clone() method on the class, or rebuild the instance from the cloned data with new User(...).

Is it faster? Not in my tests

You may read that structuredClone is the fast option. On plain JSON-like data, it was not. Median of 5 runs, Node 22 on a small container:

Data	structuredClone	JSON round-trip
Small object (about 10 values)	4.0 µs	1.9 µs
5,000 user objects	14.6 ms	10.2 ms

Chromium 141 showed the same ordering (4.9 vs 1.6 µs, and 16.7 vs 10.9 ms). So the JSON trick was faster on plain data in both. The numbers are from one machine and one data shape, so use them for direction, not as exact figures. The point: choose structuredClone for correctness, not speed. If you are cloning in a hot loop, ask whether you need a deep copy at all.

Which one should you use?

Situation	Use
Flat object, or you only change top-level values	Spread: `{ ...obj }`
Nested data, may contain dates, Sets, Maps, undefined or cycles	`structuredClone()`
Plain JSON-safe data and you want the fastest option	JSON round-trip works, if you are sure of the data
Contains functions or class instances you need to keep	A custom clone, or a library such as lodash's `cloneDeep` (not tested here)
Copying state in React or similar	Usually avoid deep copies: spread only the path you change

A bonus: moving large data without copying

structuredClone has a second argument for transferring data instead of copying it. I created an 8-byte ArrayBuffer and cloned it with { transfer: [buffer] }. The clone had 8 bytes, and the original dropped to 0 bytes. It is useful for big binary data, but the original becomes unusable.

References

Originally published on DEV Talk.

PHP Critical RCE Fix: Update to 8.5.12, 8.4.27, 8.3.36

devTalk — Thu, 22 Oct 2026 12:51:23 +0000

On 21 October 2026 the PHP project released security updates for every supported branch, and the front page of php.net carries a banner that reads "Critical remote code execution vulnerabilities, update now." Two flaws can allow unauthenticated remote code execution, and both are rated CVSS v4.0 9.2. If you run PHP behind a web server, this is a patch-today item. This article covers what was announced, how to tell whether your server is covered (the version number can mislead you), how to update, and what to do if you truly cannot update right now. I stick to the official advisory and avoid anything that would help an attacker.

The short version

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Vulnerabilities: CVE-2026-109618 and CVE-2026-109619, both unauthenticated remote code execution.
Who is at risk: per php.net, all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php.
Complete fix: update. php.net says there are no complete mitigations.
PHP 8.1 and older get no updates from the PHP project. PHP 8.2 reaches end of life on 31 December 2026.

What the two vulnerabilities are

This is how php.net describes them, in its own words:

CVE-2026-109618, RCE via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat the invalid data as valid.
CVE-2026-109619, RCE via stale global state. Request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it.

The practical meaning: these bugs live in the PHP engine, not in your application. Laravel, WordPress, Symfony or hand-written code does not matter. The PHP team says that for mod_php there is a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs, so a web application firewall or tight application code does not save you.

Step 1: find out what you actually run

Do not trust one command. The CLI and the web server can use different PHP builds on the same machine.

# the CLI
php -v

# PHP-FPM (adjust for your version)
php-fpm -v          # or: php-fpm8.3 -v

# Apache: is mod_php loaded?
apachectl -M | grep -i php

If you run containers, check inside the container (docker exec <container> php -v), because the host's PHP is irrelevant to the image.

The version number trap

Linux distributions patch security bugs without changing the upstream version number. On the Ubuntu 24.04 machine I used for testing, php -v reports 8.3.6, but the installed package is 8.3.6-0ubuntu0.24.04.11 and its changelog lists security fixes from 2026. If you compare 8.3.6 to 8.3.36 you will think the server is ancient when it may be fully patched, or the reverse. For distro packages, the changelog is the real answer:

# Debian / Ubuntu
zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | grep -E "CVE-2026-109618|CVE-2026-109619"

On my test machine this printed nothing (count 0), which means that package had not received the fix yet. For RPM-based systems, rpm -q --changelog php | grep CVE-2026-109618 is the equivalent, but I did not run it. If the grep shows both CVEs, the package has the fix, whatever the version string says.

For builds taken straight from php.net, the version is reliable. Here is a small helper that applies the fixed versions from the advisory (I ran it against a list of sample versions):

<?php
function php_upstream_status(string $v): string {
    $fixed = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
    $branch = implode('.', array_slice(explode('.', $v), 0, 2));

    if (!isset($fixed[$branch])) {
        return 'no upstream release for this branch: use a vendor backport or upgrade';
    }

    return version_compare($v, $fixed[$branch], '>=')
        ? 'upstream version includes the fix'
        : "older than {$fixed[$branch]}: update (or confirm a vendor backport)";
}

echo php_upstream_status(PHP_VERSION), PHP_EOL;

It reported 8.3.35 and 8.4.26 as needing the update, and 8.3.36 and 8.4.27 as fixed. Treat it as a first filter for upstream builds, not proof for distro packages.

Step 2: update, then restart

How you update depends on where PHP comes from:

Distribution packages: run your normal package update and check your vendor's notice. php.net says distributions and LTS vendors received the patches in advance.
Docker: rebuild your image from a patched base tag, not just restart the container. Confirm with php -v inside it.
Built from source: get the fixed release from php.net and rebuild.
PHP 7.4, 8.0 and 8.1: the PHP team provided minimal source backports, and some vendors ship backports of their own. Better: move to a supported branch.

After the package is updated, restart the processes that serve requests (PHP-FPM, or Apache for mod_php). A running worker keeps the old code in memory until it is restarted.

Hosting platforms and panels

According to Laravel News: Laravel Cloud is patched in place; Forge needs a manual "Update PHP" (or an update over SSH, then confirm with php -v); on Vapor, patched runtimes are live but you must redeploy. It also notes that there is no patch for PHP 8.0 or 8.1 on Forge and Vapor. Plesk lists 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as fixed versions and says the PHP builds arrive through its normal update process. InMotion Hosting says it turned off session.upload_progress.enabled on its managed servers as a precaution while patches roll out. Status changes quickly, so check your own provider's page.

If you cannot update today

php.net is clear that these measures reduce exposure and do not make an installation safe. Use them only to buy a few hours or days. This is the configuration from the advisory:

; php.ini  (apply before request parsing, then restart workers)
memory_limit = -1
post_max_size = 8M          ; 32M only if you need uploads
upload_max_filesize = 8M    ; keep below post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0  ; PHP 8.5 only

Per the advisory, the memory setting is for CVE-2026-109618, together with a container or cgroup memory limit as an availability boundary (and not RLIMIT_AS or RLIMIT_DATA). The upload-progress and backtrace settings are for CVE-2026-109619, and it also asks you to fix fatal errors and execution timeouts that an attacker can reach.

The advisory says to set these "in a way applications can't override." I checked why on PHP 8.3.6, using each setting's access level:

Setting	Who can change it	Result of `ini_set()` in my test
`memory_limit`	Anywhere, including application code	Succeeded (returned the old value)
`post_max_size`	php.ini and server config only	Returned `false`
`session.upload_progress.enabled`	Per-directory level (php.ini, server config, .user.ini)	Returned `false`; value stayed `0`

So application code can raise memory_limit again at runtime. That is why the advisory suggests locking it with php_admin_value in the FPM pool or Apache config. The upload-progress setting cannot be changed with ini_set(), but it is a per-directory setting, which is why the advisory warns against relying on .user.ini and asks for php.ini, the pool or the server configuration. fatal_error_backtraces does not exist in PHP 8.3 (it showed as unavailable), consistent with the "PHP 8.5 only" note.

Is anyone exploiting this?

Sources differ in what they report. php.net says it has a demonstrated exploit for mod_php. The Laravel News article does not report observed attacks in the wild. InMotion says a public exploit appeared before the patch. I could not independently confirm active attacks, and you should not wait for confirmation. If you think a server may already be compromised, update first, then review web server and PHP logs, rotate credentials and keys that were readable by PHP, and restore from a known clean state where you can.

Common questions

Does this affect Laravel specifically?

The flaws are in PHP itself, so every PHP framework and CMS on an unpatched runtime is exposed. There is no Laravel or Composer package update that fixes it.

What about CLI-only scripts and queue workers?

The advisory is about installations serving web requests. The CLI and web server commonly come from the same package, so updating covers both, and I would not leave any server on the old build.

Is PHP 8.2 still OK to run?

8.2.35 contains the fix, but php.net notes PHP 8.2 reaches end of life on 31 December 2026 and gets no security fixes after that. Plan your upgrade now.

Sources

Originally published on DEV Talk.

Laravel integer:strict Validation Rule Explained

devTalk — Thu, 22 Oct 2026 02:43:06 +0000

Here is a small surprise in Laravel validation. The integer rule passes the string "10". For a form that is fine, because browsers send everything as text. For a JSON API it is a quiet contract break: your docs say age is an integer, a client sends "age": "10", and you accept it. Laravel has a one-word fix, integer:strict. I ran both rules against a table of values on Laravel 13.35.0 so you can see exactly what changes, including a few results I did not expect.

The tip in one line

$request->validate([
    'age' => ['required', 'integer:strict'],
]);

The Laravel documentation describes the strict parameter as considering the field valid only if its type is integer, so strings with integer values are invalid. It also notes that plain integer does not check the PHP variable type, only that the input is accepted by PHP's FILTER_VALIDATE_INT. The framework source shows the difference clearly: strict mode is is_int($value), and normal mode is filter_var($value, FILTER_VALIDATE_INT) !== false.

What actually passes

I ran each value through the real validator. Here are the results, with 10.0 meaning a float and "10" a string:

Value	integer	integer:strict
`10` (int)	pass	pass
`0` (int)	pass	pass
`"10"`	pass	fail
`10.0` (float)	pass	fail
`true`	pass	fail
`" 10"` (leading space)	pass	fail
`"+10"`	pass	fail
`"10.0"`	fail	fail
`"010"`	fail	fail
`1.5`	fail	fail
`"abc"`, `false`, `null`	fail	fail

The tip is right: with integer:strict, "10", 10.0 and true all fail, and only a real int passes. The surprise is on the left side. Plain integer accepts true, and also strings with a leading space or plus sign. So a client sending {"quantity": true} gets through the normal rule. That is exactly the kind of input that ends up as 1 in your database.

Where strict mode works, and where it breaks

This is the part that can bite you. Strict mode checks the PHP type of the value, so it depends on how the data arrived:

JSON request body: types survive. Decoding {"age":10,"age_s":"10","age_f":10.0,"age_b":true} gave an int, a string, a float and a bool, so strict validation can tell them apart. This is the case it is built for.
HTML forms and query strings (?page=2): every value is text. integer:strict would reject all of them, including a perfectly normal 2. Use plain integer there.

If one endpoint serves both JSON clients and form posts, do not apply strict mode to it blindly. Test it with the real kind of requests your clients send.

The same idea for numeric and boolean

The documentation shows a strict parameter for two related rules, and I tested both:

numeric:strict rejects numeric strings. In my run "10" failed, while 10, 10.0 and 1.5 passed. Use it for prices and amounts where you want a JSON number, not text.
boolean:strict accepts only real true and false. Plain boolean also accepted 1, 0, "1" and "0", and all four failed in strict mode. Note that "true" as a string fails both versions.

$request->validate([
    'quantity'  => ['required', 'integer:strict', 'min:1'],
    'price'     => ['required', 'numeric:strict'],
    'gift_wrap' => ['required', 'boolean:strict'],
]);

Missing and null values

Strict mode does not change how required and nullable work. With required|integer:strict, a missing field failed. A null value failed unless the rule list included nullable, and with nullable|integer:strict it passed. Add nullable only on fields that are really optional.

Should you use it?

For a public JSON API with documented types, yes. It gives clients a clear error the first time they send the wrong type, instead of letting sloppy data in and fixing it later. The honest trade-off: stricter rules mean some existing clients that send "10" will start getting 422 errors. If that is a risk, roll it out on new endpoints first, or version the API.

References

Laravel 13.x documentation: Validation, integer rule

Originally published on DEV Talk.

8 Laravel Quick Tips You Can Use Today

devTalk — Wed, 21 Oct 2026 15:49:15 +0000

Some Laravel features are famous, and some sit in the docs for years while people write the same longer code around them. These eight are small, each takes under a minute to try, and each one removes either a chunk of code or a whole class of bug. I ran every example on Laravel 13.35.0 with a real database, so the outputs below are what actually came back.

1. See the real SQL with toRawSql()

You want to know what query a chain of conditions produces. Instead of reading the query log, ask the builder:

Post::where('status', 'draft')
    ->where('reads', '>', 5)
    ->orderBy('id')
    ->limit(10)
    ->toRawSql();

// select * from `posts` where `status` = 'draft' and `reads` > 5 order by `id` asc limit 10

The values are already filled in, so you can paste the result straight into a database client and run EXPLAIN on it. The query builder also has dumpRawSql() and ddRawSql() for printing it in the middle of a chain (I confirmed these exist in the framework source; I ran toRawSql() itself). Treat the output as debugging information only and keep it out of logs on production if the values may be private.

2. Use sole() when exactly one row must exist

first() happily returns the first match, even when you expected only one. sole() insists:

Post::where('title', 'A')->sole();   // returns the model
Post::where('title', 'B')->sole();   // two rows exist
Post::where('title', 'Z')->sole();   // none exist

My results: one match returned the model, two matches threw MultipleRecordsFoundException ("2 records were found."), and zero matches threw the usual ModelNotFoundException. Good for lookups like "the one active subscription for this user" where a duplicate means your data is broken and you want to know now.

3. isDirty() before saving, wasChanged() after

These two get mixed up all the time. The test shows the difference:

$post->title = 'New title';

$post->isDirty('title');      // true  (changed, not saved yet)
$post->wasChanged('title');   // false

$post->save();

$post->isDirty('title');      // false (nothing pending now)
$post->wasChanged('title');   // true  (it changed during the last save)

Use isDirty() in code that runs before the save, and wasChanged() afterwards, for example in an observer's updated method when you only want to send an email if the status changed.

4. Copy a record with replicate()

Need a "duplicate this post" button? replicate() gives you an unsaved copy:

$copy = $post->replicate();   // exists = false, id = null, created_at = null
$copy->title = 'Copy of ' . $post->title;
$copy->save();                // inserted as a new row

$copy = $post->replicate(['status']);   // skip the status attribute

The primary key and timestamps are not copied, and the title came across, as I verified. The array argument lists attributes to leave out. Relationships are not copied, so duplicate child rows yourself if you need them.

5. Update extra columns while incrementing

A page-view counter often also needs a "last viewed" time. One query does both:

$post->increment('reads', 1, ['last_read_at' => now()]);

The row afterwards had reads = 1 and the new last_read_at. Because it is one atomic UPDATE, two requests arriving together do not overwrite each other the way $post->reads++; $post->save(); can. One thing to remember from the timestamps article: increment() also bumps updated_at unless you wrap it in Model::withoutTimestamps().

6. Build optional filters with when()

Instead of a stack of if statements around your query:

$posts = Post::query()
    ->when($filters['status'] ?? null, fn ($q, $status) => $q->where('status', $status))
    ->when($filters['min_reads'] ?? null, fn ($q, $min) => $q->where('reads', '>=', $min))
    ->get();

With a null status and a minimum of 3, the SQL was just select * from posts where reads >= 3. The empty filter added nothing. One catch: when() skips a value that is falsy, so a filter value of 0 or '0' is ignored. If zero is a valid choice, check explicitly with ->when($min !== null, ...).

7. Run something once per object with once()

If a method does expensive work and gets called several times, wrap the body in once():

public function heavy()
{
    return once(function () {
        // expensive work
        return $this->calculate();
    });
}

I called such a method three times on one object and the closure ran once. A second object ran its own closure once, so the cached result belongs to each object and does not leak between them. That also means it lasts only as long as the object does.

8. Turn on strict mode in development

This is the one I would add first to any project. Model::shouldBeStrict() switches on three safety checks together:

// app/Providers/AppServiceProvider.php, in boot()
Model::shouldBeStrict(! $this->app->isProduction());

What each check did in my test:

Lazy loading: looping over Post::get() and touching $post->comments threw LazyLoadingViolationException ("Attempted to lazy load [comments] on model [Post] but lazy loading is disabled."). That is the classic N+1 problem, caught during development. Loading a single model with first() and then its relation did not throw, so the check targets models loaded together.
Silently dropped attributes: new Post(['title' => 'x', 'reads' => 5]) where reads is not fillable threw MassAssignmentException instead of quietly ignoring it.
Missing attributes: selecting only id and then reading $post->title threw MissingAttributeException instead of returning null.

Running it only outside production (as above) is a common choice, because you want these mistakes to fail loudly while you build, not break a live page. After I turned strict mode off, Post::with('comments') loaded the same data without any errors, which is the usual fix for a lazy loading violation.

Originally published on DEV Talk.

Laravel #[Refreshes]: Refresh Attributes After Writes

devTalk — Wed, 21 Oct 2026 02:30:51 +0000

You create a model, and one of its columns is calculated by the database: a full name built from two fields, a slug, a total. You save it and read the value back. You get null, even though the row in the database is correct. The model only knows what you gave it, and the database never told it what it computed. The Laravel 13 documentation has a small feature for exactly this: the #[Refreshes] attribute. I ran it against a real MariaDB database to see what it does and what it costs.

The problem, reproduced

Here is a table with generated columns. full_name is stored, and slug is computed when read:

Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->string('first_name');
    $table->string('last_name');
    $table->string('full_name')
        ->storedAs("concat(first_name, ' ', last_name)");
    $table->string('slug')
        ->virtualAs("lower(replace(concat(first_name, '-', last_name), ' ', '-'))");
});

With a normal model, this happened:

$user = User::create(['first_name' => 'Ada', 'last_name' => 'Lovelace']);

$user->full_name;   // null  (the database has "Ada Lovelace")
$user->slug;        // null

Eloquent ran one query, the INSERT, and did not read anything back. After an update it was the same: I changed the first name to Grace and saved, the database now said "Grace Lovelace", and the model still held null.

The fix: #[Refreshes]

Tell the model which attributes to reload after a write. This is straight from the documentation:

use Illuminate\Database\Eloquent\Attributes\Refreshes;
use Illuminate\Database\Eloquent\Model;

#[Refreshes('full_name')]
class User extends Model
{
    // ...
}

For more than one, pass an array:

#[Refreshes(['full_name', 'slug'])]
class User extends Model {}

Results with the attribute in place:

After User::create(...), full_name was "Ada Lovelace".
After changing first_name to Grace and saving, full_name was "Grace Lovelace".
With ['full_name', 'slug'], both values came back (Alan Turing and alan-turing).
Only the columns you list are loaded. In the single-column example, slug was still null.
The refreshed values do not leave the model marked as changed: isDirty() returned false afterwards.

What it costs: one extra query per write

This is the trade-off to know before you use it. I logged the SQL:

insert into `users` (`first_name`, `last_name`) values (?, ?)
select `full_name` from `users` where `id` = ? limit 1

An update behaves the same way: the UPDATE, then a SELECT for just the listed columns. Reading the framework source, that SELECT uses the write connection, which is the safe choice when you have read replicas, because a replica may not have your new row yet. If nothing changed, save() ran no queries at all, so the refresh did not add any either.

The refresh also works with increment(). I used a stored column logins_x2 defined as logins * 2 and listed it in the attribute. After $user->increment('logins', 5), the model showed logins = 5 and logins_x2 = 10 using two queries (the UPDATE and the SELECT).

Refreshes vs. refresh()

You could call $user->refresh() after saving. It reloads every column, not just the ones you care about, and you have to remember to call it at every write. #[Refreshes] does it automatically for the columns you name, wherever the model is saved. Choose refresh() if you only need the value in one place, and the attribute if the model should always be correct after writing.

When to use it, and when to skip it

Use it when your code or API response reads a generated column right after a write.
Skip it when nobody reads that column straight after saving. You would pay for a SELECT that nothing uses.
Be careful on bulk jobs. Creating 10,000 models one by one now means 20,000 queries. Bulk insert() does not create model instances, so it is unaffected, but it also gives you no refreshed values.

Common questions

Does it work for columns set by triggers or database defaults?

The docs describe it for generated columns. The mechanism reloads whatever columns you list, so it should work for any column the database fills in, but I only tested generated columns (stored and virtual).

Which Laravel version has it?

It is in the Laravel 13.x documentation and in the 13.35.0 source I tested. I did not check older releases, so on an older version use refresh() instead.

References

Laravel 13.x documentation: Refreshing Attributes After Writes

Originally published on DEV Talk.

Laravel 13 #[Connection] Attribute: Per-Model Database

devTalk — Tue, 20 Oct 2026 14:05:07 +0000

Most Laravel apps talk to one database and never think about connections. Then a reporting database shows up, or a legacy system, or a read-only analytics replica, and suddenly a few models need to talk somewhere else. Laravel 13's Eloquent documentation shows a clean way to do it: a #[Connection] attribute on the model class. I tested how it behaves with two real databases, including a few details the docs do not mention.

The basic example

First, define the extra connection in config/database.php as you normally would, for example one called reporting. Then point a model at it:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Attributes\Connection;
use Illuminate\Database\Eloquent\Model;

#[Connection('reporting')]
class SalesSummary extends Model
{
    // ...
}

That is the whole change. Every query this model runs, reads and writes, goes to the reporting connection. Without the attribute, a model uses your application's default connection. The documentation example uses the same pattern with #[Connection('mysql')] on a Flight model.

What I tested

I set up two MariaDB databases, one as the default and one as reporting, each holding a table with the same name but different data, so any query that went to the wrong place was obvious. Results from the real Laravel 13.35.0 Eloquent classes:

Case	Result
Model with `#[Connection('reporting')]`	Reads came from the reporting database
Model with no attribute	Used the default database
Saving a new record on the attributed model	Row landed in the reporting database, default untouched
Attribute on a base class, child extends it	Child used the reporting connection
Attribute plus `protected $connection = 'default'`	The property won
`Model::on('default')` on an attributed model	Overrode the attribute for that query

Three details worth knowing

1. You can use an enum instead of a string

The attribute's constructor in the framework source accepts either a string or a PHP enum. I confirmed that a string-backed enum case resolves to the right connection:

enum Db: string
{
    case Main = 'mysql';
    case Reporting = 'reporting';
}

#[Connection(Db::Reporting)]
class SalesSummary extends Model {}

SalesSummary::on(Db::Reporting)->first();

This is not shown on the docs page, so it comes from the source and my test, not the documentation. It saves you from typos in connection names scattered across models. Using it needs an enum you maintain yourself.

2. Set it once on a base class

If ten models live in the reporting database, do not repeat the attribute ten times. Put it on an abstract base class and extend that. My child model picked up the connection from its parent.

#[Connection('reporting')]
abstract class ReportingModel extends Model {}

class SalesSummary extends ReportingModel {}
class DailyRevenue extends ReportingModel {}

3. Relationships follow the parent unless the related model says otherwise

This is the one that bites. I tested three setups:

A parent on the default connection with a hasMany to a plain child: the children came from the default database.
The same parent loaded with Parent::on('reporting'): the plain child came from reporting. The relation inherits the parent's connection.
A related model with its own #[Connection('reporting')], loaded from a default-connection parent: it used its own connection.

So a child without an attribute follows whichever connection its parent was loaded from. If you want a related model to always use a specific database, give that model its own attribute. Also keep in mind that a single SQL query cannot span two separate database servers, so a relationship across connections is loaded with separate queries rather than a join. Avoid whereHas and similar across models on different connections unless the tables really live in the same database server.

When this is actually useful

Reporting or analytics database. Heavy queries stay away from your main database. A good production setup is a read-only database user on that connection, so a bug cannot write to it.
Legacy or third-party database. Wrap the old tables in models without moving data.
Multi-database setups. Different parts of the app, such as a billing database and a main database.

Common mistakes

The connection name is not inconfig/database.php. The attribute only names a connection, it does not create one.
Expecting transactions to span connections. A transaction belongs to one connection, so work on two connections is not covered by one DB::transaction().
Forgetting that the property wins. If an old model still has protected $connection, it overrides the attribute.

References

Laravel 13.x documentation: Database Connections

Originally published on DEV Talk.

Laravel Query Optimization: 4 Simple Fixes for Faster Apps

devTalk — Tue, 20 Oct 2026 02:02:20 +0000

When a Laravel page or job feels slow, the database is the first suspect, and usually the right one. The good news is that you rarely need clever tricks. Most slowness comes from a few everyday habits: wrapping a column in a function so the database cannot use its index, doing arithmetic in PHP that the database does in milliseconds, writing rows one at a time, and loading a huge pile of rows into memory at once. I tested four of these on a table with one million orders (Laravel 13, MariaDB 10.11), so you can see how big the difference really is. (Selecting fewer columns, indexes and eager loading are covered in separate articles, so they are not repeated here.)

1. Do not wrap an indexed column in a function

This one catches many people because the code looks perfectly reasonable. whereDate() is convenient, but it wraps the column in a function, and the database can no longer use the index to jump to the right rows:

// Looks nice, scans the whole index
Order::whereDate('created_at', '2024-03-15')->count();
// select ... where date(`created_at`) = ?

// Same result, uses the index to jump to one day
Order::where('created_at', '>=', '2024-03-15 00:00:00')
     ->where('created_at', '<', '2024-03-16 00:00:00')
     ->count();

Both returned 2,880 orders, with an index on created_at in place. The whereDate version took about 172 ms and examined roughly 996,000 index entries. The range version took 1.3 ms and examined 2,880. The range also has a side benefit: it handles the end of the day correctly, with no confusion about midnight.

2. Let the database do the math

It is tempting to fetch rows and then total them up in PHP, because Laravel collections make it so easy: get()->sum('total_cents'). The catch is that get() builds a full model object for every row first, just so you can add up one number. The database can add the numbers itself and send back a single value.

// Builds 250,000 models, then adds them up in PHP
$total = Order::where('status', 'paid')->get()->sum('total_cents');

// The database does the addition, PHP gets one number
$total = Order::where('status', 'paid')->sum('total_cents');

Over 250,000 paid orders, both returned 12,500,250,000. The collection version took 5.8 seconds and peaked at 302 MB of memory. The database version took 0.15 seconds and 6 MB. The same applies to count(), avg(), min() and max().

Grouping is where it gets dramatic. Here is the total per status across all one million orders:

// Loads 1,000,000 rows, then groups them in PHP
$totals = Order::select('id', 'status', 'total_cents')->get()
    ->groupBy('status')
    ->map(fn ($rows) => $rows->sum('total_cents'));

// One query, four rows come back
$totals = Order::selectRaw('status, sum(total_cents) as total')
    ->groupBy('status')
    ->pluck('total', 'status');

The PHP version took about 25.8 seconds and peaked above 1.1 GB. The database version took 1.1 seconds and 6 MB. Rule of thumb: if you only want a number or a summary, ask for the number or the summary, not the rows. One small thing to watch: the database can return sums as strings (my pluck result came back as "12500250000"), so cast to int if you need a number.

3. Write in bulk, not one row at a time

Every create() or save() is its own trip to the database. A few is fine. Thousands in a loop add up fast, because each one pays the full round trip and commit cost. I inserted 5,000 rows three ways:

// 5,000 separate queries, each committed on its own
foreach ($rows as $row) {
    Order::create($row);
}

// Same 5,000 queries, but one commit at the end
DB::transaction(function () use ($rows) {
    foreach ($rows as $row) {
        Order::create($row);
    }
});

// 5 queries of 1,000 rows each
foreach (array_chunk($rows, 1000) as $batch) {
    Order::insert($batch);
}

Approach	Queries	Time for 5,000 rows
`create()` in a loop	5,000	1.9 s
`create()` in one transaction	5,000	1.2 s
`insert()` in chunks of 1,000	5	0.06 s

Updates work the same way. I had 10,000 pending rows to mark as done. Looping over them and calling save() took 5.0 seconds and ran 10,001 queries (one to read, 10,000 to write). A single mass update did the same job in 0.06 seconds with one query:

// 10,001 queries
foreach (Work::all() as $work) {
    $work->status = 'done';
    $work->save();
}

// 1 query
Work::where('status', 'pending')->update(['status' => 'done']);

There is a trade-off, and it is worth knowing before you switch. Bulk insert() and mass update() skip model events, so observers and listeners do not fire, and insert() does not fill created_at and updated_at for you (I confirmed both when comparing Eloquent and the query builder). If your app depends on those, add the timestamps to your rows yourself or keep the slower path for those tables. For plain data like imports, counters and status flags, bulk is the better choice. For inserts that may already exist, look at upsert().

4. Process big tables in batches: chunkById, lazyById and cursor

Calling get() on a huge table loads every row as an object into memory at once. That is fine for hundreds of rows and dangerous for hundreds of thousands. For exports, cleanups and background jobs, Laravel gives you four ways to work through rows without holding them all at once. They are not equally good, so here is what I measured.

// 1. Batches of rows, you handle each batch
Order::where('id', '<=', 300000)->chunkById(1000, function ($orders) {
    foreach ($orders as $order) {
        // do the work
    }
});

// 2. One row at a time, loaded in batches behind the scenes
foreach (Order::where('id', '<=', 300000)->lazyById(1000) as $order) {
    // do the work
}

// 3. One query, one row at a time
foreach (Order::where('id', '<=', 300000)->cursor() as $order) {
    // do the work
}

// 4. lazy(): like lazyById, but pages with offsets (usually the wrong choice)
foreach (Order::where('id', '<=', 300000)->lazy(1000) as $order) { ... }

Each test below ran in a fresh PHP process. The first set walks 300,000 narrow order rows. The second walks 5,000 articles with a body of roughly 30 KB each:

Method	300,000 narrow rows	5,000 wide rows (memory)
`get()` (everything at once)	5.4 s, 368 MB	324 MB
`chunkById()`	3.3 s, 8 MB	38 MB
`lazyById()`	3.4 s, 10 MB	56 MB
`cursor()`	9.0 s, 28 MB	166 MB
`lazy()`	13.4 s, 10 MB	56 MB

What the numbers say

chunkById()andlazyById()are the good defaults. They were the fastest and kept memory low. They work by asking for rows with an id greater than the last one seen, so each batch costs about the same no matter how deep you are. Pick chunkById() if you want to handle a batch at a time, and lazyById() if you prefer a simple foreach.
cursor()is easy to misjudge. It runs a single query and gives you one model at a time, so it sounds like the lightest option. On narrow rows it used 28 MB, but on the 30 KB articles it peaked at 166 MB, compared with 38 MB for chunkById(). Memory grew with the size of each row, which is consistent with the database driver fetching the whole result into PHP before Laravel hands rows over one by one (I did not dig into the driver to confirm that). It was also slower than the batched methods on the 300,000-row run. Use it for narrow rows, and pair it with select() so each row stays small when your table is wide.
lazy()is the odd one out. It looks like lazyById(), but it pages with offsets, so it re-skips more and more rows as it goes. It took 13.4 s against 3.4 s for lazyById(), and it has a worse problem, shown next.

The trap: changing the rows you are looping over

A very common job is "find everything pending, process it, mark it done". I tested exactly that on 10,000 pending rows, updating each row's status inside the loop:

lazy()      processed 5,000 of 10,000, 5,000 still pending
lazyById()  processed 10,000 of 10,000, 0 still pending
cursor()    processed 10,000 of 10,000, 0 still pending

With lazy(), every row that gets marked done disappears from the filter, so the next page's offset jumps over rows that were never processed. Half the work was silently skipped, with no error. The same offset-based behaviour applies to the plain chunk() method, so use the ById versions whenever your loop changes the column you filter on. cursor() was safe here because the whole result was already fetched when the loop started.

Is this an optimization for web pages?

Not really. These methods save memory for batch jobs: exports, imports, cleanups, queue jobs and artisan commands. For a page or API response, show a limited number of rows with pagination instead, and do not loop over a whole table inside a web request.

How to find the slow queries in the first place

Guessing is slow. Three tools you already have:

toSql() shows the SQL a query builder will run, so you can see what you actually asked for.
explain() asks the database how it plans to run the query. Look for type: ALL and very large rows numbers.
DB::listen() lets you log every query with its bindings and time. In my test, one callback printed select count(*) as aggregate from orders where date(created_at) = ? | ["2024-03-15"] | 252.84 ms for the slow query above.

Quick checklist

Compare dates with a range, not with a function on the column.
Ask the database for totals and groups instead of loading rows to add them up.
Insert and update in bulk, and remember that bulk skips model events.
Use chunkById() or lazyById() for batch jobs over more than a few thousand rows, and avoid lazy() and chunk() when you update the rows you filter on.

Frequently asked questions

Is it safe to skip model events with bulk writes?

It depends on your app. If you use observers for audit logs, search indexing or cache clearing, bulk writes will skip them. In that case, trigger the same work yourself after the bulk operation, or keep the per-row path for that model.

How big should an insert batch be?

I used 1,000 rows per query, which worked well. Very large batches can hit the database's maximum packet size or placeholder limits, so start around 500 to 1,000 and measure.

Is Eloquent the reason my queries are slow?

Usually not. Eloquent adds some overhead for building model objects, which is why large result sets use more memory, but most slow pages are caused by the query itself or by doing in PHP what the database should do.

Will caching fix a slow query?

It can hide one, but the query stays slow every time the cache expires. Fix the query first, then cache what is still expensive.

Originally published on DEV Talk.

Laravel Default Attribute Values: $attributes Explained

devTalk — Mon, 19 Oct 2026 16:28:20 +0000

Create a new Eloquent model, ask for $flight->delayed, and you get null. Not false, even if your database column defaults to false. That gap between "the database knows the default" and "the model knows the default" causes small, annoying bugs. Laravel gives you a one-property fix: $attributes. This article shows how it works, where it stops helping, and the format mistake that throws an error. Everything here was run against Laravel 13.35.0 Eloquent and MariaDB.

The basic example

Add an $attributes array to your model:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Flight extends Model
{
    /**
     * The model's default values for attributes.
     *
     * @var array<string, mixed>
     */
    protected $attributes = [
        'options' => '[]',
        'delayed' => false,
    ];
}

This is the example from the Laravel documentation. A new instance now carries those values from the moment it is created, before anything touches the database:

$flight = new Flight;

$flight->delayed;   // false
$flight->options;   // '[]' (or [] if you cast it, see below)

Why the database default is not enough

Say your migration has $table->boolean('delayed')->default(false) and $table->string('status')->default('scheduled'), but the model has no $attributes. I ran this:

$flight = Flight::create(['name' => 'A']);

$flight->delayed;   // null  (the row in the database has 0)
$flight->status;    // null  (the row in the database has 'scheduled')

$flight->refresh();
$flight->status;    // 'scheduled'

The insert never mentioned those columns, so the database filled them in, and the model object never found out. If you return that model straight from an API controller, your JSON says null while the database says something else. Putting the same defaults in $attributes removes the mismatch, and it also makes the value available on a fresh new Flight for forms and validation.

The one rule: use the raw, storable format

The docs say values in $attributes must be in the raw format, as if just read from the database. That is why the example uses the string '[]', not an empty array. If you cast the column, Laravel converts the raw value when you read it:

class Flight extends Model
{
    protected $attributes = [
        'options' => '[]',
        'delayed' => false,
        'status'  => 'scheduled',
    ];

    protected function casts(): array
    {
        return [
            'options' => 'array',
            'delayed' => 'boolean',
            'status'  => FlightStatus::class,   // a backed enum
        ];
    }
}

In my test, a new instance returned [] for options, false for delayed, and the enum case for status, and a plain save() wrote '[]', 0 and 'scheduled' to the row. The mistake to avoid is putting [] (a real array) in $attributes next to an array cast. I tried it, and just reading the attribute threw a TypeError from json_decode() because it received an array instead of a string. Use '[]'.

What defaults do not do

These are the behaviors that surprise people, all confirmed by running them:

Situation	What happens
`Flight::create(['delayed' => true])`	Your value wins over the default
`Flight::create(['status' => null])` on a NOT NULL column	The default is replaced by `null` and the database rejects it (integrity constraint error, column cannot be null)
`Flight::create(['options' => null])` on a nullable column	`null` is stored
`Flight::select('id')->first()`	Defaults are not added. Only `id` is present and `$flight->delayed` is `null`
Loading a row from the database	Database values are used, the defaults do not override them

The second row is the important one. A model default only applies when the attribute is not set. If a request passes an explicit null, it wins. Keep your validation in place and do not treat $attributes as a safety net.

When a default needs to be calculated

The $attributes property holds fixed values only. A token, a reference number or anything based on the current time needs code. A creating event works (I tested the same pattern with a generated code and it was saved on insert):

use Illuminate\Support\Str;

protected static function booted(): void
{
    static::creating(function (Flight $flight) {
        $flight->code ??= 'FL-' . strtoupper(Str::random(6));
    });
}

For UUID or ULID primary keys, Laravel has dedicated traits (HasUuids and HasUlids), so you do not need this pattern for IDs.

Model default or database default?

You can use both, and for important columns I would. They protect different things:

Database default: protects the data from every writer, including raw queries, imports, other apps and bulk insert() calls that skip models.
$attributes: makes the model object correct right away, with no refresh and no extra query.

Just keep the two values identical. If they drift apart, the model and the database will disagree about what "default" means, and that is a very hard bug to spot.

References

Laravel 13.x documentation: Default Attribute Values

Originally published on DEV Talk.

Best Linux Commands for Developers and Sysadmins

devTalk — Mon, 19 Oct 2026 15:59:34 +0000

Most "top Linux commands" lists give you ls, cd and pwd and call it a day. You already know those. This list is organised by the problems you actually hit on a server: the disk is full, something is using your port, one endpoint is slow, a log has a million lines. Every command below was run on Ubuntu 24.04 with GNU coreutils, and the outputs are from those runs, using a small sandbox with a fake Laravel-style folder and a generated access log.

1. "The disk is filling up": du and find

du -h --max-depth=1 app | sort -h
# 12K    app/public
# 792K   app/storage
# 2.9M   app/vendor
# 3.7M   app

find app -type f -size +500k -printf '%s %p\n' | sort -rn
# 3000000 app/vendor/big.bin
# 800000 app/storage/logs/laravel.log

The first command sizes each folder one level deep, and sort -h understands K, M and G suffixes so the biggest is last. The second lists individual large files. Run the first one at /var or your project root and drill down. (--max-depth is the GNU spelling; on macOS use -d 1.)

2. "I deleted the log but the space did not come back": lsof +L1

If a process still has a file open when you delete it, the disk space stays allocated until that process closes it or exits. This is a classic cause of a full disk that du cannot explain. List open files that have been unlinked:

lsof -nP +L1
# tail  260  root  3r  REG  254,0  20000000  0  1001125  /path/to/big.log (deleted)

I created a 20 MB file, kept it open with tail -f, deleted it, and lsof showed it with a link count of 0 and the word (deleted). The fix is to restart or signal the owning process (for a log, ask it to reopen its files). At 20 MB the change was too small to show in df -h, so I am not claiming a number there, but the mechanism is the one that bites on production servers with multi-gigabyte logs.

3. "What is using this port?": ss

ss -ltnp | grep 8765
# LISTEN 0 5 127.0.0.1:8765 0.0.0.0:* users:(("python3",pid=252,fd=3))

lsof -nP -iTCP:8765 -sTCP:LISTEN

-l listening, -t TCP, -n no name lookups, -p show the process. You usually need sudo to see processes owned by other users. ss replaces the older netstat and is installed by default on current Ubuntu.

4. "Who is hitting my server?": awk, sort, uniq

awk '{print $9}' access.log | sort | uniq -c | sort -rn
#   794 200
#   113 404
#    52 301
#    41 500

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -3
#   539 10.0.0.1
#   192 10.0.0.2
#   125 10.0.0.3

awk '$9 ~ /^5/ {print $7}' access.log | sort | uniq -c | sort -rn | head -3
#     8 /p3
#     7 /p1
#     7 /p0

This is the pattern worth memorising: extract a field, sort, uniq -c to count, sort -rn to rank. The field numbers ($9 is the status code, $7 the path, $1 the client IP) are for the standard combined log format, so check your own format first. Always sort before uniq, because uniq only collapses adjacent duplicates.

5. "Where is this string used?": grep

grep -rn "TODO" app --include='*.php'
# app/public/b.php:1:<?php // TODO fix

-r recurses, -n prints line numbers, and --include limits the search to the file types you care about so you do not grep through vendor binaries. If you have ripgrep (rg) installed, it is faster and skips ignored files by default, but plain grep is on every server.

6. "Clean up old files without regret": find with -print first

find app/storage/logs -name '*.log' -mtime +7 -print     # look first
find app/storage/logs -name '*.log' -mtime +7 -delete    # then delete

In the test, the first command listed old1.log and old2.log (back-dated 10 days) and left laravel.log alone; the second removed only those two. Run the exact same expression with -print before you swap in -delete. Put -delete last, because find evaluates the expression left to right.

7. "Do this to 1,000 files, faster": xargs -P

find imgs -name '*.txt' -print0 | xargs -0 -n1 -P4 sh -c 'sleep 0.5'

Eight tasks that each take half a second ran in about 1.0 seconds with -P4 and 4.0 seconds serially. -print0 with -0 keeps filenames with spaces intact, -n1 passes one file per command, and -P4 runs four at a time. Use it for image conversion, compression, or any CPU-bound per-file job, and keep -P near your core count.

8. "Copy this safely": rsync --dry-run

rsync -avh --delete --dry-run src/ dst/
# deleting old
# a
# b
# (DRY RUN)

With --delete, rsync removes files in the destination that are not in the source. The dry run shows exactly that, deleting old, before anything happens. Drop --dry-run only when the list looks right. The trailing slash on src/ matters: it means "the contents of src", not the folder itself.

9. "Why is this endpoint slow?": curl -w

curl -sS -o /dev/null -w 'code=%{http_code} connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/

Against a local test server this printed code=200 connect=0.000518s ttfb=0.005061s total=0.005155s. Against a real site, a large gap between connect and ttfb means the server is slow to respond; a slow connect points at the network. Pipe JSON APIs through jq next:

echo '{"items":[{"name":"a","ok":true},{"name":"b","ok":false}]}' | jq -r '.items[] | select(.ok==false) | .name'
# b

10. "What is eating memory?": ps

ps aux --sort=-%mem | head -5
free -h

--sort=-%mem puts the biggest memory user first. The columns RSS (resident memory in KB) and %MEM are the ones to read.

Frequently asked questions

Should I learn grep or ripgrep?

Learn grep first because it exists on every server. Add rg on your own machine for speed.

Why does uniq -c show the same line twice?

Because the input was not sorted. uniq only merges adjacent duplicates, so put sort in front of it.

Are these commands the same on macOS?

Mostly, but some flags are GNU-specific, such as du --max-depth, find -printf and sort -h on older systems. On macOS use du -d 1 or install GNU coreutils.

Originally published on DEV Talk.