PHP - BlogFlock

Find the slowest PHPUnit tests - Rob Allen

2026-10-20T10:26:02.000Z

We have a PHPUnit test suite that's taking a while, so I wanted to find out the which tests were taking the longest.

With the help of Google, I discovered the --log-junit phpunit-results.xml command line option to phpunit which creates an XML file with the info I need. Running on Slim's codebase, we create the XML file with:

$ ./vendor/bin/phpunit --log-junit phpunit-results.xml
...
Tests: 436, Assertions: 832, PHPUnit Notices: 37.

It looks like this (formatted by me):

$ head -n 7 phpunit-results.xml

Each testcase has a time attribute, so I asked my LLM to create some Python to sort by time and list the top 5:

$ python3 -I -c '
import sys, heapq, xml.etree.ElementTree as ET

cases = ET.parse(sys.argv[1]).iter("testcase")
slowest = heapq.nlargest(5, cases, key=lambda c: float(c.get("time", 0)))

for c in slowest:
    print(f"{float(c.get("time", 0)):8.3f}s  {c.get("class")}::{c.get("name")}")
' phpunit-results.xml

For this test, I get:

$ python3 -I -c 'import sys, heapq, xml.etree.ElementTree as ET; print(*(f"{float(c.get("time", 0)):8.3f}s  {c.get("class")}::{c.get("name")}" for c in heapq.nlargest(5, ET.parse(sys.argv[1]).iter("testcase"), key=lambda c: float(c.get("time", 0)))), sep="\n")' phpunit-results.xml 
0.028275 Slim\Tests\AppTest testAnyRoute
0.026482 Slim\Tests\AppTest testInvokeSequentialProcessAfterAddingAnotherRouteArgument
0.020176 Slim\Tests\AppTest testInvokeSequentialProcessToAPathWithOptionalArgsAndWithoutOptionalArgsAndKeepSetedArgs
0.016482 Slim\Tests\MiddlewareDispatcherTest testExecutesMiddlewareLastInFirstOut
0.013571 Slim\Tests\Factory\AppFactoryTest testCreateAppWithContainerUsesContainerDependenciesWhenPresent

Obviously, Slim's tests are quick, so there's no much to see here, but for my client's project, the numbers are larger!

Every Road Around the Zend Engine - Exakat

2026-10-19T15:39:14.000Z

Every Road Around the Zend Engine

I’ve been using PHP forever, and so I’ve relied on the Zend Engine. After all, it is the core of PHP. The PHP source goes into the Zend Engine, gets parsed into an AST, compiled to opcodes, and executed. One request, one process. That’s just what php does when you run it, and it’s been true in its broad shape since Zend Engine 2 shipped with PHP 5 in 2004. Set in the PHP era, it is roughly the end of antiquity.

Nowadays, as in October 2026, it is no longer the only way to get from a .php file to a run program. Over the last fifteen years, and especially the last three, a whole ecosystem has grown up around the idea that “run this PHP script” doesn’t have to mean “hand it to the C interpreter Rasmus Lerdorf’s successors maintain”. Some projects replace the engine outright. Some keep the real one and put it somewhere unexpected. Some don’t touch it at all and just change what it’s running inside of. They depart from the canonical pipeline at genuinely different points, which turns out to be the more useful way to sort them than by vendor or by benchmark.

None of this is entirely new, either. JPHP has been compiling PHP straight to JVM bytecode since the early 2010s, and picked up 1.7k GitHub stars doing it: sadly, its last real target is PHP 7.1, with only pieces of 7.2–7.4 layered on. It is so old that upgrading to it would be error prone in most 2026 codebases. We won’t include it in this timeline of PHP engines, but acknowledge the tremendous courage it needed, back in these ancient times. The projects that follow are the ones still tracking a current PHP version. This means PHP 8.5, because PHP 8.6 is still a month away.

The panorama

Project	What it replaces	Departs the pipeline at	Output
Zend Engine	nothing, this is the baseline	–	opcodes, interpreted/JIT’d per request
KPHP	the compiler and the runtime	before parsing	native binary, via generated C++
TypePHP	the compiler and the runtime	before parsing	native binary, extension, or shared lib
elephc	the compiler and the runtime	before parsing	native binary, assembly directly, no C++ step
Manticore	the compiler and the runtime	before parsing	native binary, via LLVM IR
Quercus	the compiler and the runtime	before parsing	JVM bytecode
PeachPie	the compiler and the runtime	before parsing	.NET IL
php.rs	the compiler and the runtime	before parsing	its own Rust-native VM
phpr	the compiler and the runtime	before parsing	its own Rust-native bytecode VM
zphp	the compiler and the runtime	before parsing	its own Zig-native runtime
php-wasm / WordPress Playground	nothing, recompiles the real engine	after the engine is built	the same engine, running in WASM
FrankenPHP	nothing, links the real engine	after the engine is built	the same engine, embedded in a Go process
RoadRunner	nothing, supervises the real engine	outside the pipeline entirely	long-lived worker processes, not one-shot

HHVM, one historical ancestor of the “replace the compiler” family, is covered separately below. It no longer belongs on this table, for reasons that are themselves instructive.

The canonical path, briefly

It is worth starting precisely, since everything else in this blog is defined relative to it. php script.php does four things: lex and parse the source into an AST, compile the AST to Zend opcodes, hand those opcodes to the Zend VM, which either interprets them one at a time or, for code the PHP 8.0 JIT decides is worth it, compiles them to machine code on the fly. One process, one request, memory cleaned down at the end. Every alternative below is a departure from some part of that sequence, never all of it invented from nothing; even the projects that discard the C source still have to agree on what array_merge() does.

Replace the compiler and its target

The first one is the most drastic move: write your own front end for PHP syntax, and instead of Zend opcodes, emit something else entirely. Everything in this family shares one constraint: none of them implements all of PHP, because doing so is the whole difficulty of the exercise, and each one draws the line differently.

Straight to native code

KPHP, built at VK.com and open-sourced in 2020, compiles a restricted subset of PHP to C++, then to a native binary that serves HTTP itself: it has no interpreter, no opcode cache, no “slow startup” phase, because there’s no startup to be slow.

TypePHP does the same C++ round-trip but is, charmingly, self-hosting: its own compiler is PHP code, compiled by an earlier version of itself into the tpc binary you run. It’ll also emit a loadable extension or a shared library from the same source, if a full standalone binary is more than you need. It’s GPL-3 licensed, and its current Packagist listing wants PHP 8.4 or 8.5 to build.

elephc skips the C++ intermediate step and goes straight to assembly, that is parse, type-check, lower to native code, assemble, link, with eval() available through an experimental bridge to a statically linked interpreter, for the one thing you genuinely can’t resolve at compile time. The current release, 0.26.2, targets macOS and Linux.

Manticore is a PHP AOT compiler written in PHP, with an LLVM backend: it lowers a large subset of PHP 8.5+ through its own typed intermediate representation to LLVM IR, and produces standalone arm64 or x86_64 binaries that need no interpreter and no php.ini. The compiler compiles itself to a byte-identical fixpoint, and its README reports native binaries beating the Zend interpreter in all 47 comparable benchmark cases. Those are claims worth checking yourself, and the project’s own limitations list, such as integer overflow wraps instead of promoting to float, no extract(), shows exactly where the feature coverage stops.

# TypePHP: same source, three different outputs
tpc build app.php -o app          # standalone native binary
tpc build app.php --ext -o app.so # loadable PHP extension
tpc build app.php --lib -o libapp # shared library, callable from C

Straight to someone else’s VM

Quercus, Caucho’s PHP-on-Java implementation from the Resin application server, compiles PHP source to Java source and lets javac finish the job. PHP scripts becoming .class files that run in whatever JVM your Java stack already has.

PeachPie does the .NET equivalent: PHP compiled through Roslyn to CLR IL, JIT’d by the .NET runtime, with the payoff that a PeachPie-compiled Composer package can be new‘d directly from C#.

And then there’s the newest and most crowded corner of this family: reimplementing PHP wholesale outside C entirely, mostly in Rust but not only. php.rs bills itself as the complete interpreter, compiler, and standard library rebuilt from zero, over 100,000 lines in.

phpr takes the more conservative VM-architecture route: parser, IR, bytecode compiler, dispatch loop. It measures itself against something genuinely hard to fake: whether it can install and serve WordPress.

zphp is the same wholesale-reimplementation bet made in Zig instead: a from-scratch PHP 8.x runtime with its own HTTP server, database drivers, and a --compile flag for standalone binaries. It is still tiny next to the Rust entrants, with single-digit GitHub stars, and openly built as an AI-maintained experiment rather than a community project. The commit history never sleeps, but it also never argues on the mailing list. Indeed, it is attacking exactly the same problem.

There’s enough activity here that “reimplement PHP outside the Zend C source” has quietly become its own genre, alongside smaller entrants like phprs and phpl that haven’t attempted anything close to full-language coverage.

The ancestor of this whole family is Facebook’s HipHop

It was released in 2010: PHP compiled to C++, then to a binary, on the theory that facebook.com’s PHP was CPU-bound and interpretation was the tax. It worked, roughly double the throughput, until it didn’t scale further, so in 2013 Facebook replaced it with HHVM, a JIT bytecode VM that eventually beat HipHop’s own numbers. The instructive part isn’t the speedup, it’s what happened next: by 2018, HHVM’s maintainers concluded that chasing PHP compatibility was slowing down the language features they actually wanted, and cut the cord. Hack today is PHP’s syntax with the serial numbers filed off, running on a VM that no longer promises to run your Laravel app. Every project in this section is implicitly betting it won’t end up there, a bet HHVM itself already lost.

Keep the real Zend engine, change its house

This section is for a breed of engines with a different style: don’t write a new front end at all. Take the actual Zend Engine C source, the one that ships with PHP, and put it somewhere it wasn’t designed to run initially. Embedding is the name of the game.

php-wasm and the WordPress Playground project both do this via Emscripten: compile libphp itself to WebAssembly, and you get PHP running client-side in a browser tab, sandboxed, with SQLite standing in for a filesystem. It’s the reason you can now try WordPress at wordpress.org without a server existing anywhere: the “server” is a WASM module your browser downloaded. Playground now ships a separate php-wasm build for each PHP version from 7.2 to 8.5, and it has dropped support for 7.2 and 7.3.

FrankenPHP does the embedding move instead of the cross-compilation move: it links libphp into a Go binary via cgo, so the actual Zend Engine runs inside the same process as the Caddy web server, one thread per PHP execution (Windows support arrived in 2026), with Go orchestrating the thread pool through a state machine and C handling the SAPI lifecycle. You end up with a single static binary that is your app, your PHP runtime, and your web server, with zero IPC between them. It is one fewer box-and-arrow diagram for the ops team to keep arguing about, but the opcodes running inside it are exactly the ones php-fpm would have produced.

Neither of these projects had to solve PHP-the-language a second time, which is precisely why their compatibility story is so much better than in the first section: they didn’t reimplement anything, they relocated PHP.

Leave the engine alone, change what’s around it

The least drastic and, in production terms, probably the most consequential family: don’t touch the pipeline at all. A normal PHP process runs a normal request exactly as it always has. What moves is everything outside that boundary.

RoadRunner is a Go process manager that starts a pool of long-lived PHP workers and keeps feeding them requests over a binary protocol (Goridge), instead of the PHP-FPM model of spawning and tearing down a process, or at least its framework bootstrap — on every request, which is PHP-FPM’s way of never quite unpacking its suitcase. The Zend Engine inside each worker does exactly what it always did; what disappeared is the reload cost, paid once at worker startup instead of per request.

The diagram

What the panorama shows

The starting point predicts the compatibility story. Everything in lane 1 has to reimplement PHP’s semantics from scratch, in a foreign environment: references, magic methods, the coercion rules, the standard library’s thousand small inconsistencies, which is exactly why KPHP, TypePHP, and elephc all cover a subset of PHP rather than PHP. Lane 2 sidesteps that problem entirely by never rewriting anything: php-wasm and FrankenPHP inherit the real engine’s compatibility, bugs and all, because it is the real engine. Lane 3 doesn’t even ask the question: RoadRunner runs ordinary PHP because nothing about ordinary changed.

Speed and portability pull in different directions. The native-compilation projects in lane 1 exist because interpretation has a cost that JIT alone hasn’t eliminated for every workload. KPHP’s own numbers put it at three to ten times faster than plain PHP, which is the kind of numbers you build a compiler for. The JVM/.NET/WASM branch of lane 1 isn’t chasing speed at all; Quercus and PeachPie exist so a PHP codebase can sit inside a Java or .NET deployment, calling and being called by that ecosystem’s own code. Two different problems, sharing only the shape of “write a new compiler.”

Lane 3 is where most production PHP will actually feel this. Nobody’s rewriting a Laravel app to fit KPHP’s subset, but plenty of teams are already running it inside a RoadRunner worker or a FrankenPHP binary. That is because those get the payoff without rewriting anything at all.

The bigger picture

What ties all twelve of these together, more than any shared codebase or shared goal, is that every single one is still measured against the same yardstick: does it run real PHP. The WordPress install with fifty plugins, the Composer tree with a dependency that leans on eval(), the codebase where someone passed a reference into a closure in 2016 and it’s load-bearing now, and nobody currently employed knows why. phpr’s own benchmark is literally the WordPress torture test, and PeachPie brags about running it. KPHP doesn’t try and says so upfront. That’s a true challenge: it’s the actual hard problem every project on this list is solving a different slice of, and the panorama above is really a map of how much of real PHP each one has chosen to promise.

The yardstick is also moving. PHP 8.6 is due on November 19, 2026, and every project above is chasing a target that keeps moving every year.

Which raises a question: language-level tools already audit a codebase for type coverage, or, as I’ve written about before, for where validation silently doesn’t happen. Nothing audits a codebase for engine coverage: which functions, which reference patterns, which magic-method edge cases a given PHP source tree actually exercises, and therefore which of these eleven routes it could safely take. Until that audit exists, asking if my app run on X stays a question you answer by trying it and watching what breaks.

PHP has a wild new frontier!

The post Every Road Around the Zend Engine appeared first on Exakat.

PHP has a Spoofchecker: A 14-Year-Old Tool You’re Probably Not Using - Exakat

2026-10-17T14:34:38.000Z

PHP has a `Spoofchecker`: A 14-Year-Old Tool You’re Probably Not Using

The Spoofchecker class has shipped with PHP since 5.4, released in March 2012. That’s the same year the iPhone 4S was current, “Gangnam Style” dropped, and PHP 5.3 was still the dominant version on the west. Fourteen years later, most PHP developers, including me, have never heard of it. Yet, it’s still the single best PHP built-in defense against Unicode-based visual spoofing.

Start here: when visual traps aren’t a runtime problem

Before going further, you can read my recent blog When PHP reads something else: Visual traps in source code. It’s about a related yet distinct problem: characters in your source code that look identical to other characters, silently breaking comparisons, identifiers, or function calls. The post focuses on the editor side: the developer’s eye can’t tell the difference between an ASCII hyphen - and a Unicode minus −: can you? Or between a Latin o and a Greek ο; between a regular space and a non-breaking space; … there are so many.

Spoofchecker is the runtime counterpart to that problem. Where Exakat helps you spot visual traps in your codebase, Spoofchecker helps you spot them in user input: the strings your application accepts from forms, APIs, emails, and URLs. It’s the same family of attack: characters that look the same to a human but are different to a machine. The difference is who’s being fooled, aka a developer vs. an end user, and where the trap is set, aka your repo vs. incoming data.

If Exakat’s article is about keeping your own house clean, Spoofchecker is about recognizing when someone else is tracking dirt across your floor. This is often underestimated.

Three configurations worth knowing in detail

Out of the box, Spoofchecker runs a default set of checks. But the real power is in setChecks(), where you configure exactly the checks you want. Here are three configurations I keep coming back to.

1. Mixed-script confusables: the brand-impersonation check

setChecks(Spoofchecker::MIXED_SCRIPT_CONFUSABLE);

var_dump($checker->areConfusable('раypal.com', 'paypal.com'));  // true
var_dump($checker->areConfusable('example.com', 'paypal.com')); // false
?>

The string раypal.com looks identical to paypal.com in almost any font, but the first two characters are Cyrillic: р is U+0440 and а is U+0430, not the Latin p and a. areConfusable() compares two whole strings and tells you whether they look alike, which is the question a brand-impersonation check asks. This is the configuration that catches the classic homograph domain attack.

2. Invisible characters: the password and ID hygiene check

setChecks(Spoofchecker::INVISIBLE);

$spoofed = "ad\xE2\x80\x8Bmin";   // 'ad' + zero-width space + 'min'
var_dump($checker->isSuspicious($spoofed));  // true
?>

Zero-width spaces, zero-width joiners, and certain combining marks are invisible to humans but live in the string. INVISIBLE should catch them. This is the configuration you want for any context where the user might retype or visually verify a string: passwords, 2FA seeds, share codes, short IDs. A zero-width character in a password is a guaranteed support ticket. Copy paste is not your friend.

3. Restriction level: the policy-grade check

setRestrictionLevel(Spoofchecker::ASCII);

var_dump($checker->isSuspicious('café'));   // true  (non-ASCII)
var_dump($checker->isSuspicious('hello'));  // false
?>

The restriction level is the most opinionated setting: it grades the whole string against one of Unicode’s identifier profiles. It’s set with setRestrictionLevel(), not with a check constant, so keep it separate from setChecks(). The levels are:

Level	What it allows
`Spoofchecker::ASCII`	ASCII only
`Spoofchecker::SINGLE_SCRIPT_RESTRICTIVE`	A single script only
`Spoofchecker::HIGHLY_RESTRICTIVE`	ASCII + one other script (e.g., Latin + one CJK)
`Spoofchecker::MODERATELY_RESTRICTIVE`	Allows reasonable mixtures, blocks exotic ones
`Spoofchecker::MINIMALLY_RESTRICTIVE`	All identifier characters
`Spoofchecker::UNRESTRICTIVE`	Anything goes

This is the configuration to reach for when you have a policy about what an identifier should look like, not just a question about spoofing. For machine-generated IDs, URLs, and API tokens, ASCII or HIGHLY_RESTRICTIVE is right. For human-facing display names where multilingual input is legitimate, drop to MODERATELY_RESTRICTIVE.

The rest of the checks

Spoofchecker exposes more checks than the three above. PHP 8.4 added IGNORE_SPACE, CASE_INSENSITIVE, ADD_CASE_MAPPINGS and SIMPLE_CASE_INSENSITIVE, which the manual documents. Here’s the full list, briefly:

SINGLE_SCRIPT_CONFUSABLE: confusable letters within one script (e.g., 0 and uppercase O, l and 1). Useful for short identifiers.
WHOLE_SCRIPT_CONFUSABLE: an entire script that visually mimics another. This is the case of Greek, that resembles Latin. This check is broader than mixed-script.
ANY_CASE: ICU’s “any case” option. It does not make comparisons case-insensitive: on PHP 8.5.11, areConfusable() with it raised an ICU U_INVALID_STATE_ERROR warning. On PHP 8.6-dev there is no warning, but Admin and ADMIN still don’t match. Normalize case yourself, as shown in the username example below.
CHAR_LIMIT: a character-limit check. I haven’t verified its exact behavior, so check the manual before relying on it.
MIXED_SCRIPT_CONFUSABLE: the brand-impersonation check illustrated above.
INVISIBLE: the invisible-character check illustrated above.
SINGLE_SCRIPT: the identifier mixes scripts, e.g. ceo@раypal.com. This is the check the egulias/EmailValidator library uses (see the conclusion).

Combine them with bitwise OR: $checker->setChecks(Spoofchecker::MIXED_SCRIPT_CONFUSABLE | Spoofchecker::INVISIBLE | Spoofchecker::SINGLE_SCRIPT);

There are also two helper methods that don’t involve setChecks:

areConfusable('Admin', 'Аdmin', $errorCode);  // true

// Restrict allowed scripts to specific locales (affects restriction level checks)
$checker->setAllowedLocales('en_US,ru_RU,el_GR');
?>

Note the third argument. areConfusable() and isSuspicious() both take an int &$errorCode, not a human-readable message. You get a code, not a sentence, so map it to your own message if you need one.

New in PHP 8.6: skeletons and bidi comparison

PHP 8.6 adds getSkeleton(), getBidiSkeleton() and areBidiConfusable(), plus the LTR and RTL constants. I tested them on PHP 8.6.0-dev (built 15 October 2026); none of them exist in PHP 8.5. A skeleton maps each confusable character to a canonical form, which makes it a good way to show someone why a string looks suspicious:

getSkeleton('Damien');  // 'Darnien'

// The Cyrillic letters map to Latin, and `m` maps to `rn`
$checker->getSkeleton('раypal.com');  // 'paypal.corn'

// Bidi-aware skeleton, given the text direction
$checker->getBidiSkeleton(Spoofchecker::LTR, 'Elephpant'); // 'Elephpant'

// Bidi-aware comparison
$checker->areBidiConfusable(Spoofchecker::LTR, 'Аdmin', 'Admin'); // true
?>

Various usages of Spoofchecker

The Spoofchecker class is general-purpose, but in practice it shines in a handful of PHP situations. Here are a few of them.

Domain names and URLs

This is the headline use case. When your application accepts a URL from a user, for link preview, webmention, bookmark, social share, you’re implicitly trusting that the hostname is what it claims to be. IDN domains, aka Punycode, make this worse, because xn--80ak6aa92e.com decodes to аррӏе.com, an all-Cyrillic string that looks like apple.com (Don’t sue me!).

setChecks(Spoofchecker::MIXED_SCRIPT_CONFUSABLE);
    $checker->setRestrictionLevel(Spoofchecker::HIGHLY_RESTRICTIVE);

    return $checker->isSuspicious($decoded);
}

isLikelySpoofedUrl('https://paypal.com');              // false
isLikelySpoofedUrl('https://раypal.com');              // true
isLikelySpoofedUrl('https://xn--80ak6aa92e.com');       // true (Punycode → Cyrillic apple)
?>

Pair it with idn_to_ascii() for full domain validation: Spoofchecker looks at the visual content, idn_to_ascii() confirms the domain is well-formed.

Username and handle registration

Account impersonation is one of the most common abuse vectors in any platform with user-visible names. Without Spoofchecker, the only way to prevent Аdmin, with a Cyrillic А, from sneaking past a “don’t register as admin” check is to maintain your own confusable mapping. Usually, which you’ll get it wrong. Trust me, bro.

setChecks(
        Spoofchecker::MIXED_SCRIPT_CONFUSABLE
        | Spoofchecker::SINGLE_SCRIPT_CONFUSABLE
    );

    // Uppercase both sides: `0` looks like uppercase `O`, not lowercase `o`
    foreach ($existingNames as $existing) {
        if ($checker->areConfusable(mb_strtoupper($newName), mb_strtoupper($existing), $errorCode)) {
            return true;
        }
    }
    return false;
}

$existing = ['Admin', 'moderator', 'support'];
isUsernameImpersonation('Аdmin', $existing);     // true
isUsernameImpersonation('moderator', $existing); // true (exact match handled by other logic)
isUsernameImpersonation('m0derat0r', $existing);  // true (single-script confusable)
isUsernameImpersonation('alice', $existing);     // false
?>

Case is the awkward part. Uppercasing both sides, as above, makes the comparison case-insensitive for the letters that matter, and it doesn’t rely on the ANY_CASE option.

Email addresses and display names

filter_var($email, FILTER_VALIDATE_EMAIL) checks the syntax, and it rejects raw Unicode in the domain. So the attacker sends the Punycode form instead: ceo@xn--ypal-43d9g.com is ceo@раypal.com, and it passes validation. The syntax check does its job; it just can’t see that раypal is visually paypal. Display names are even worse: they’re free-form text, so they are prone to social engineering tactics.

setChecks(Spoofchecker::SINGLE_SCRIPT);
    return $checker->isSuspicious($local . '@' . $decodedDomain);
}

function isLikelySpoofedDisplayName(string $name, array $trustedNames): bool
{
    $checker = new Spoofchecker();
    $checker->setChecks(Spoofchecker::MIXED_SCRIPT_CONFUSABLE);
    foreach ($trustedNames as $trusted) {
        if ($checker->areConfusable(mb_strtoupper($name), mb_strtoupper($trusted), $errorCode)) {
            return true;
        }
    }
    return false;
}

isLikelySpoofedEmail('ceo@xn--ypal-43d9g.com');                     // true (decodes to ceo@раypal.com)
isLikelySpoofedEmail('ceo@paypal.com');                             // false
isLikelySpoofedDisplayName('Аlex from IT', ['Alex from IT']);       // true
?>

Password policy: the lesser taken road

Passwords with zero-width characters are a support nightmare: the user thinks they typed hunter2, but they copy pasted it, and the database stores hunter\xE2\x80\x8B2: the login fails forever. It is recommended to reject these at registration and update time.

setChecks(Spoofchecker::INVISIBLE);
    return !$checker->isSuspicious($password);
}

isPasswordSafeToStore('correct horse battery staple');  // true
isPasswordSafeToStore("correct\xE2\x80\x8B horse");     // false
?>

You probably don’t want to enforce full ASCII restriction on passwords: users legitimately use accented characters and Cyrillic in passphrases. But blocking invisible characters is almost always correct.

Content moderation and banned-word filters

Word filters are a classic spoofing target. If you block the string viagra in a comment, the first thing an attacker does is substitute visually identical Cyrillic characters: vіagra, with a Cyrillic і. The second thing they do is use single-script confusables: v1agra. Spoofchecker catches both.

setChecks(
        Spoofchecker::SINGLE_SCRIPT_CONFUSABLE
        | Spoofchecker::MIXED_SCRIPT_CONFUSABLE
    );
    foreach ($bannedWords as $word) {
        // Compare the whole text against the banned word
        // (in practice, tokenize first)
        if ($checker->areConfusable(mb_strtoupper($text), mb_strtoupper($word), $errorCode)) {
            return true;
        }
    }
    return false;
}
?>

For real production use, tokenize the input first and compare token-by-token rather than the whole string at once. The areConfusable method is a per-string check, not a substring search.

Other situations worth a pass

A few more places where the same pattern pays off, with less code:

Payment and financial contexts: payee names, bank references, invoice descriptions that visually mimic a known legitimate counterparty.
Brand and keyword monitoring: in marketplaces, app stores, and ad networks, to detect typosquatting and brand squatting in user-submitted product names and store names.
Anti-phishing in messaging and email: scan incoming sender display names and embedded links against a list of known-internal executive names and vendor domains before display.

Limitations and gotchas

Spoofchecker is definitely better than nothing. And probably better than anything you can come up with. Yet, there are a few things Spoofchecker is not: let’s review them so you don’t get surprised.

Spoofchecker requires the intl extension. Most modern PHP builds include intl by default, though shared hosting and minimal Docker images sometimes don’t. Check extension_loaded('intl') before relying on it; provide a fallback, or refuse the input otherwise.

isSuspicious is heuristic, not authoritative. It will produce false positives on legitimate multilingual names. A real Greek user named Αλέξ is flagged by setRestrictionLevel(Spoofchecker::ASCII). Always combine the check with locale context via setAllowedLocales(), and prefer MODERATELY_RESTRICTIVE for human-facing identifiers rather than the strictest levels.

Behavior depends on the ICU version. The confusable tables are maintained upstream in ICU and updated periodically. The same string may produce different results on PHP 8.1 with ICU 70 vs. PHP 8.3 with ICU 74. Don’t store isSuspicious results as long-lived authoritative flags; re-run the check when needed.

areConfusable is a per-string check, not a substring search. It compares two whole strings and tells you whether they look alike. It will not find раypal inside https://раypal.com/login. For substring detection, tokenize first: that is, split the URL on /, split the email on @, split text on whitespace, etc. and compare per-token.

It does not validate format. A Punycode string that doesn’t decode, or a domain with illegal characters, will pass Spoofchecker if no confusable pattern matches. Pair with idn_to_ascii() for full domain validation and with Normalizer::normalize() for general Unicode hygiene.

The default check set is conservative. If you don’t call setChecks(), you get a reasonable starting point but not a strict one. For anything security-sensitive, be explicit about which checks you want and which restriction level applies.

It is not a substitute for output encoding. Spoofchecker tells you whether input is suspicious. It doesn’t make output safe. Always pair with proper HTML escaping, URL encoding, and CSP headers.

Unicode tricks in your tests too

The same trick works against the output of your test suite. On 8 October 2026, The PHP Foundation published Your tool has a new reader, about PHPUnit. Its argument: a terminal now has two readers. A human sees the rendered output, and a coding agent reads the raw bytes and acts on them. Any gap between the two is a risk.

The post shows how a test name, data set name, or assertion message can carry control characters. An ESC[2K (erase line) or a carriage return can make a failing test look like a pass to a human, while the agent reads the failure. A line feed inside a data set name can forge the header of a record for a test that doesn’t exist. The fix is to show these characters as visible \u{NNNN} escapes rather than strip them. The lesson is the same as for Spoofchecker: the bytes differ from what the eye sees, and your test output is input too.

Conclusion: you may already be running Spoofchecker

Thanks to egulias/EmailValidator, which is included in many applications, Spoofchecker may already run in your code. Its SpoofCheckValidation strategy calls Spoofchecker with SINGLE_SCRIPT on the whole address, and its constructor throws a LogicException if the intl extension is missing. It is not part of the default RFC validation: it runs only when you add it to a validation chain. On the address from the email example above, it flags ceo@xn--ypal-43d9g.com and passes ceo@paypal.com.

To check your own code, run composer show egulias/email-validator and search your codebase, including your framework’s validation layer, for SpoofCheckValidation. If it is there, you’re already using Spoofchecker. If it is not, the three configurations above are a good place to start.

Check your Unicode strings a bit more

Spoofchecker is fourteen years old, underused, and still the right tool whenever your PHP application accepts Unicode that other humans will see.

Worth ten minutes of your time to wire in.

The post PHP has a Spoofchecker: A 14-Year-Old Tool You’re Probably Not Using appeared first on Exakat.

The 2,000th word: a personal notebook became a map of PHP - Exakat

2026-10-16T09:40:31.000Z

The 2,000th word: a personal notebook became a map of PHP

Today the PHP Dictionary reaches its 2,000th definition: bearer token, is the last entry, and, as you can see, it is quite niche subject for a definition and PHP. This is because, over the years, a lot of definitions were added to what was initially a simple knowledge memorisation. So, it is a good moment to look back at how we got here, and at what the dictionary has become.

It started as a notebook

The dictionary began as a way to clear up things I used every day without always understanding them. It is surprising how much words and concepts are used, both heard and pronounced, yet, they are not defined. This is how language (human, not PHP) live: initially, you learn by converting the meaning to what you already know, with a definition. Later, you build that same definition by experience: hear it, see its side effects, form a definition.

Even words that sound familiar are not obvious to pin down, because they were acquired without being defined. Think “dangling reference” or “garbage collection”: who put garbage in my code? Is there a notion of garbage creation? There is spagetti code, but when does it become garbage? And, yes, OOP is POO in French, but that is not the point.

Writing down a definition for each term, with a short illustration, may be a code sample, forced me to understand them properly.

Then, a definition is only useful in a context, so soon, definitions were not enough. So I started adding links: to the PHP manual, to the blog posts that explained a notion best, to the people who coined the terms, to other definitions in the dictionary. 2000 words gave 12000+ links, and they bring the technical reference of PHP together, like a carpet in a room.

It grew by listening to the community

That is where the dictionary changed shape. The PHP community has written an enormous amount of useful material over the last thirty years: articles, blog posts, conference talks, tutorials, videos, tools, release notes, funny things… Hundreds of authors explained concepts in great details, and with lyrism and enthusiasm. Their articles are now linked from the definitions.

The numbers show how wide that reach is:

What	Count
Definitions	2,000
Distinct URLs	4,108
Distinct websites cited	about 1,000
Definitions with a PHP code sample	1,452
Words written across descriptions	193,000+

Every definition points outward. The official PHP manual is the most-linked source, of course, and a large share of the links go to blogs and articles written by practitioners. Each one is a small credit to someone who took the time to write it down: thank you to all of you. You know who you are.

It connected the words together

PHP notions are not isolated. A “trait” leans on “class”, “class” on “object”, “object” on “reference”, “type”, “property”, “inheritance”, “composition”, “case”, and so on. So the dictionary also became a network.

There are 12,381 links between definitions. The most connected terms are the foundations of the language: array, security, interface, database, type, property, string. Reading one definition naturally leads to the next, which is what I wanted from the start. If you remember “surfing the net with hyperlinks” from the 1990’s, that’s the idea. If you don’t, well, you can catchup with something you definitely missed.

It untangled words with several meanings

Many PHP terms mean more than one thing, depending on who is talking. Over 59 definitions explicitly list multiple concepts they cover. Generally, it is difficult to come up with new words for each concept: as programmer, we don’t always add v2 as a suffix, so some words are covering several distinct meanings. It happens like in any natural and human language.

Take stack. It can be the call stack that tracks nested function calls, the data structure where the last item in is the first one out, or the LAMP stack of Linux, Apache, MySQL and PHP. Or unpacking, which is either the unpack() function that reads binary data, or the ... operator that spreads an array into arguments.

Those entries were often an eye opener: not by choosing one meaning, but by putting them side by side so the reader can tell which one a blog post is talking about.

Where does the PHP dictionary stands

Numbers are also a to-do list:

30 definitions are not linked from any other definition: I need to review them.
new blogs are created everyday, even today, and should be added to this dictionary.
old blogs decay, fade away, and disappear entirely, in a casino. These need a review.
Some corners of the PHP ecosystem should be brought forward. Which one? I missed them, so you tell me.

Each of these is a small, concrete contribution, accessible to everyone.

Beyond the book

The dictionary already exists in several forms:

a website, with a sitemap and an RSS feed
a machine readable JSON dictionary.json, one structured object per entry. Grab this one in one go, don’t scan web sites.
llms.txt and llms-full.txt for AI tools.
a terminal navigator, tui.php, to read the dictionary from the comfort of the commandline.

For the future, a book is not always the most convenient way to use a dictionary. I am looking at other formats: flashcards for learning the vocabulary, a Markdown vault for personal note-taking, an API or MCP, an editor plugin that shows a definition on hover, and a printable reference sheet. If one of those would help you, I want to hear about it.

Help build the next 2,000

Fix a broken link, suggest new articles. Open a file in src/index/, check JSON, and fill it in.
Connect an orphan. Pick one of the 30 definitions nobody links to, and add it to the related list of a relevant entry.
Add a resource. A good article or a manual page is worth more than a dozen generic links. A whole website.
Propose a missing word. Terms, acronyms and jargon are the most valuable addition. Send a pull request on the repository; the contributing guide explains the workflow.

Let’s talk, now that we have a PHP dictionary. You can reach me online on the PHPCommunity server, or on Mastodon or Twitter. Tell me which definition you want next, which one is wrong, or which format would make you actually use this dictionary.

And now, let’s go to 3,000.

The post The 2,000th word: a personal notebook became a map of PHP appeared first on Exakat.

PHP and Rust have been walking toward each other from across the room for years. One is the elephant: over thirty years old, used by about 70% of the websites whose server-side language W3Techs can identify, and believes == is a perfectly reasonable thing for two values to do. The other is the crab: young, armored, allergic to nulls, and insists you prove your code is correct before it runs, which frankly sounds like homework.

For a long time, the gap between them was a rift between continents. Crossing it meant writing C glue code by hand, at night, alone, without a debugger. That era is over. What changed is not the languages: it’s the sudden ability to produce a PHP VM in Rust with a lot of help from an AI that has read more C code than any human ever will. The results are wildly uneven, sometimes accidental, and occasionally brilliant. The rift is now being covered with bridges. Some are suspension bridges. Some are rope. One is a DOOM renderer.

This post inventories every crossing point between the two languages, in both directions, with notes on each project’s maturity where the sources show it.

From PHP, Toward Rust

1. Zend Extensions: The Classic Highway

This is the obvious move: write a PHP extension, in Rust instead of C. The Zend API stays the reference: the extension still has to speak its C-level interface. In fact, there are currently several ways to do this, including one that writes the extension code for you.

Project	Pitch
ext-php-rs	Bindings over the Zend API, macros galore. The respectable choice. Its README requires PHP 8.1 or later.
phper, aka “PHP Enjoy Rust”	“Pure and safe Rust whenever possible.” Supports PHP 7.0 to 8.5. Powers the Apache SkyWalking PHP agent, which is a serious résumé.
alef-backend-php	A code generator, not a compiler: from a Rust library it produces ext-php-rs source for a PHP 8.2+ extension, with classes, methods, free functions and serde conversions. It is the PHP backend of alef, a polyglot binding generator (MIT, version 0.17.35, May 2026).

Async calls in its output run through Tokio block_on, so from PHP’s side they behave synchronously.

These solutions are solid and battle tested. This is the road production code actually takes when it needs Rust speed inside PHP. It is also a great avenue to keep a production monolith in PHP, and offload heavy work to Rust.

Other languages are not so lucky: few have such comfortable tools to merge with PHP.

2. FFI: The Drawbridge

With FFI, no framework is needed. Since PHP 7.4, you can compile a Rust crate as a cdylib (.so, .dylib, .dll), declare the C signatures with FFI::cdef(), and call it. The elephant extends its trunk; the crab extends a claw; a C header mediates because neither trusts the other’s native language.

This solution is light and fast: so much that there is nothing more to explain than the paragraph above. And you own every unsafedecision yourself. FFI is the trust fall of interoperability, and it is common in other languages too.

3. WebAssembly: The Neutral Embassy

Why talk directly when you can meet in a sandbox? Compile Rust to WASM, execute it inside PHP through a runtime extension:

Project	Pitch
veewee/ext-wasm	The modern take, still experimental: wasmtime via ext-php-rs, component model, WASI preview1/2, Fibers-based async. Runs DOOM, because of course it does.
wasmer-php	Wasmer-based runtime, sandboxed. Only PHP 8.0 is supported, on Linux and macOS amd64, with no Windows or arm64 support.
php-ext-wasm	A fork of wasmer-php that runs WASM through Wasmer since v0.2.0 (earlier versions used wasmi), a matryoshka option.

This is the safest way, as a WASM binary can’t touch PHP’s memory. But you pay a toll at each call boundary. veewee’s ext-wasm is experimental, so expect its API to change before 1.0.

4. PHP to Rust Transpilation: A Moving Walkway

php-to-rust, from LegacyToRustProject, is an agent that converts an entire PHP project to Rust, module by module, with a verification loop: the Rust must compile, run, and produce identical output to the original PHP, or the AI fixes it and tries again. WordPress plugins are the first-class target.

It is not a transpiler; it’s a very patient intern with a diff tool. It is in early development, with a handful of commits so far.

Rust powered PHP engine: The Holy Bridge

Many people try this: rewrite the PHP engine in Rust. The official engine is heading for PHP 8.6, so these remain interesting experiments.

Phargo: PHP engine, written from scratch in Rust: it is capable of serving WordPress pages, with a SQLite database.
php-rust: a rewrite of PHP 8.5 in Rust, including the bytecode, garbage collector and database interfaces. According to its README, it passes 1,748 unit tests, runs WordPress on MySQL, installs Composer packages and produces PHPUnit output identical to PHP’s. Doctrine DBAL and Symfony’s http-kernel tests pass, though Doctrine ORM still has failures. It is called phpr.
rphp (rphp-lang): pre-alpha PHP-compatible engine with its own lexer, parser, bytecode compiler and VM. It does not copy the Zend architecture, and it is not yet a drop-in replacement for PHP.
phpl: PHP interpreter in Rust, in its early stages. It cannot yet execute complete PHP files.

Another rewrite comes from JoliCode. Writing the PHP Virtual Machine in Rust (with a lot of help from AI), from Jolicode with a rphp project, which calls itself a research project, not a production runtime.

Beyond the headline of rewriting PHP engine in Rust, you can follow various ways to do it: some experiments are trying to run subsets of PHP features, others are running it against an ever growing set of tests, whether it be the .phpt or the ones from popular projects. The goal is always the same: identify the parts of PHP that are not possible to run with Rust.

The Rumored Bridges: more to come!

Word of mouth and a tweet from Matthieu Napoli point to compiling Rust on the fly from within a Laravel application. No public artifact to cite yet: if this bridge exists, you’ll have to wait for publication.

And another experiment is coming from tweet from Jake Casto, which hits at rewriting the PHP engine with Rust. Still a mysterious endeavour at the moment, but let’s keep an eye on it.

7. The Mirror: A Rust Compiler Written in PHP

Compiling Rust code to PHP would make little sense, but apparently, compiling Rust code with PHP does.

rustc-php is a Rust compiler with ownership checking, borrow checking, generics, traits and closures, written in PHP, emitting x86-64 Linux ELF binaries directly, no LLVM, no linker. Its stated use case: “compile Rust on a shared hosting server from 2008 where the only installed runtime is PHP.” It is the perfect comedic twin of the previous category: while Rust developers rewrite PHP in Rust, PHP developers are compiling Rust in PHP. The circle is not just complete; it is smug about it.

From Rust, Toward PHP

Rust can also be the source of the PHP code, or the host that runs it.

php_codegen: Rust Writes the PHP

php_codegen is a Rust library with a fluent API for writing PHP source code: classes, functions, enums, interfaces, traits, methods and properties. It is not a transpiler: nothing reads Rust code and translates it. You describe PHP code in Rust, and the output is PHP source. The docs.rs page for 0.4.0 reports that none of the crate is documented, so the examples folder is the best entry point. It is dual-licensed MIT or Apache-2.0 and maintained by azjezz.

Rust as Plugin Host, Process Front, or Async Engine

Project	Pitch
php-tokio	Use any async Rust library from PHP: an extension that plugs into the Revolt event loop, so it works with amphp, PSL and ReactPHP. Apache-2.0, 357 stars, no releases listed.
Extism	Rust as a plugin language: compile a plugin to WebAssembly, then call it from a PHP host. PHP and Rust are both on Extism’s supported lists. The runtime library must be installed separately, and the Packagist listing I could see was from 2024, so check the current version.
solder	A library to build PHP extensions in Rust, started as a fork of php-rs. Early and unstable; its README says it only works with PHP 7.
php-rpm	An experimental process manager: Rust’s hyper server takes the HTTP requests and runs PHP itself, in place of nginx and PHP-FPM. The repository was archived in January 2018.

The Type Checker Will See You Now

For all this engineering exuberance, one truth keeps resurfacing in every project above: the two languages’ compatibility has hard limits, and they are philosophical, not technical.

The bridges work. What doesn’t transfer is the soul. PHP’s genius is forgiveness: == means “eh, close enough,” arrays are arrays are dictionaries are lists, and a null is just a value that hasn’t decided yet. Nobody, PHPersonne, as the folklore might say, wants to strictly type their code. We are all willing to do it, as it promises marvels and wonders. Yet, Rust’s non-negotiable entry fee is exactly that strictness: types proven, ownership proven, no hand-waving. To pass into Rust, PHP code must renounce the very flexibility that made it productive; to host PHP, Rust must build a runtime that simulates a looseness it was designed to reject. Every interpreter above has to model PHP’s loose values somehow: a type-juggling layer, and, likely, a quiet apology.

This is why the pragmatic bridges are partial: extract the static, well-typed, hot modules into Rust, via FFI or extensions, and let the rest of the application keep living its dynamic best life on the PHP side. Business rules are often fuzzy, vague, evolving and leaving no time to enforce maximum verification. The elephant does not need to become a crab. It just needs the crab to carry the heavy boxes.

The experiments keep coming; that is important, and healthy. The AI era is taking care of that. The mature engineering question is no longer can PHP and Rust talk, but how much of each other’s personality they should be asked to adopt. On that, both languages would probably agree: none, thank you.

Now excuse me while I push this pull request: it compiles, it passed the tests, and honestly, that’s the only kind of trust fall either of them respects.

The post PHP ❤️ Rust: Every Bridge Between Two Worlds appeared first on Exakat.

foreach Already Knows: PHP and the Zero-One-Infinity Rule - Exakat

2026-10-13T06:38:27.000Z

foreach Already Knows: PHP and the Zero-One-Infinity Rule

send($recipient, $message);
}
?>

This loop doesn’t ask when or if $recipients a list. It doesn’t ask anything, although, well, it does ask for an array or an iterable. Now, when $recipients holds three users, it runs three times. If it holds one, it runs once. If it’s empty, the body simply never executes: no dispatcher spun up, no mailer touched, no special case written by anyone. PHP’s own engine already treats zero, one, and many as the same problem: it is solved once, at the language level. And you don’t have to pay attention to it in any way.

The rest of the code that we write hasn’t caught up to that idea. Most PHP is written for exactly one thing: one user, one row, one file, one thing. The moment a function has to handle zero of them, or two, or an arbitrary number N, that code usually gets rewritten rather than extended: a new if, a extra loop, a external helper, you name it. The gap between how PHP’s runtime treats cardinality and how PHP programmers treat it is the subject of this piece.

Naming the rule

There’s a decades-old name for the discipline foreach is abiding by: the Zero-One-Infinity rule, that I credit to computing pioneer Willem van der Poel, with an independent claim by language designer Bruce MacLennan. The rule says that a well-designed system should never bake in an arbitrary limit, such as “up to 5”, or “at most 3”, on how many of something can exist. Either a thing is forbidden, that is 0, allowed exactly once, that is 1, or allowed without limit, that is many. Nothing in between is a design decision; it’s a bug waiting to be reported as a feature request.

Applied to everyday PHP, the rule reads a little differently than it did for language designers, back then in the previous millenium:

Zero is usually an optimization: don’t do the work, not even prepration, if there’s nothing to do. No preloading before you know it’s needed, no dispatch before you know there’s a recipient, no clean up.
One is the default case, the one every tutorial teaches, and it needs no introduction.
More, or 2, or 3, or an undefined N, depending on the situation, is where the real cost shows up: duplicated code, then the itch to centralize it into a function or method, or a loop to drive it, and sometimes both. Sometimes, you don’t even know where to put the lot: inside or outside the method.

PHP has plenty of internal gears for the two extremes already. What it’s never quite settled is the syntax for the middle: the moment a script goes from this variable holds one user to this variable holds however many users there are.

Let’s review them, and see how we can transition from one to the other.

Zero: be lazy

Zero rarely gets its own code path in well-written PHP: it gets avoided, short-circuited, omitted, ignored. May be, even dispised. A repository method finds a user or it doesn’t; the code afterward should cost nothing in the doesn’t branch.

find($id);   // ?User

if ($user === null) {
    return;                        // nothing to notify, nothing spent
}

$user->notify($message);
?>

The nullsafe operator collapses that guard into the call itself, which is in fact the same optimization written as one expression instead of two statements:

find($id)?->notify($message);
?>

??= is the same idea applied to work instead of data: don’t build the expensive thing until something actually asks for it:

loadExpensiveThing();
?>

Notice PHP already has two different spellings for nothing, and it chooses between them based on the cardinality the code expected before it turned out to be empty:

 null
function findUsers(array $ids): array  { /* ... */ }   // expected zero-or-many -> []
?>

null is what “zero” looks like when a slot was always meant to hold at most one thing. [] is what “zero” looks like when the slot was always meant to hold any number of things. These are two different absences, which are chosen by the shape of the context. There is no best practice so place the if anywhere.

One: same old, same old

This is the most common case. It is deliberately a short description, because it’s the case PHP needs the least help with. $user->notify($message); is all you need, and it gets used all the time, obviously. Just do it. If it is typed, it’s a safe thing. Every PHP tutorial’s first working example is the one case, and that’s not an accident: it’s the case the language was designed around first, and everything else was retrofitted on top.

Arrays, and the container that stopped caring

Before going further into more than one, it’s worth stopping on a traditional PHP feature, that the platform got right decades before this pattern had a name: the data side of this problem was already solved. PHP is untyped by default: it dissolves the zero/one/many distinction at the array level, long before it ever reaches a function signature. Actually, any effort to force types on arrays, is going against what we are presenting here.

Imagine a moment wrapping every value in an array. A list, if you want, with a steady type, no index.

The values are of the same type. Here, we see the humble [...] or array() for the old-timers (hi there!), regardless of how many elements are inside it. Nothing converts, nothing changes shape, nothing declares a new type as the count moves from 0 to 1 to N. count($x) doesn’t care which case it’s looking at: it is typeless. Neither does foreach. And it is important to understand that they are working on different levels.

Compare that to a statically-typed language, where the question maybe zero, maybe one, maybe many usually forces three genuinely different types that don’t compose without an explicit conversion step:

Optional zeroOrOne = Optional.empty();
List     zeroOrMany = new ArrayList<>();

Optional and List share no supertype worth using; going from one to the other is a refactor, not a reassignment. PHP’s array already is the composition those two types are trying to approximate separately. The literal syntax, [], is simultaneously the empty set, the singleton (the unique value here, not the pattern), and an arbitrary-length collection, with no wrapper to strip off later.

So the noun problem, what container holds however many of these there are, was never PHP’s weak point. What’s left, and what the rest of this piece is actually about, is the verb problem: the syntax you write to act on that container still assumes exactly one, and has to be entirely rewritten the moment it isn’t.

Two in a box: it is still fine to write by hand

Treating two items in th same way is where the more side of the rule start its transition, and it’s still comfortable territory: PHP lets you name both halves and move on:

name} beat {$runnerUp->name}";
?>

list() destructuring, and its less blog-friendly [$a, $b] shorthand, is PHP’s admission that exactly two, with distinct roles is common enough to deserve its own syntax: a middle ground between one variableand a loop. Nobody reaches for array_map() to handle a winner and a runner-up. Yet, most people should reach for in_array() instead of doing an or, even for at the two values scale: let that sink in. The point is that there are easy work around, that don’t feel like bringing out the big guns.

Three: where duplication starts to hurt

Three is usually still hand-writable, but it’s the point where the transition starts:

notify($message);
$cto->notify($message);
$cfo->notify($message);
?>

Three identical lines, differing only in which variable holds $this. Nothing here is wrong, but the pattern is now visible, and the next person to read it, aka the next executive to be added, is going to feel the pull toward a loop before they feel any pull toward more copy-paste.

N, the infinite and beyond: where centralization becomes mandatory

Once the count isn’t known until runtime, hand-written duplication stops being an option and PHP forces a choice: a function or method that takes the collection, and a loop inside it. We all recognize array_map() and foreach() and its cousins.

notify($message);
    }
}
?>

Actually, that notion applies to other PHP features, such as parameters. Variadics are PHP’s syntax for the specific flavor of manywhere even the caller doesn’t know the count at compile time: it’s baked into the call site itself rather than passed as a collection:

notify($message ?? 'Update available');
    }
}

notifyAll($ceo, $cto, $cfo);          // three, spelled like a normal call
notifyAll(...$allExecutives);          // N, unpacked from a collection
?>

Both are still hiding foreach under their vest. Variadics only change how the many things arrive at the function boundary, not how they’re processed once inside it, which is a hint that foreach really is doing all the load-bearing work for more in PHP, everywhere it shows up.

PHP’s built-in answers to “more”

Once more needs handling, PHP hands several tools, each answering a slightly different question about it.

array_map, array_filter, and array_reduce are foreach with the loop body extracted and named: the same zero-or-more traversal, but expressed as apply this operation instead of repeat this block:

 ucfirst(strolower($u->name)), $users); // get and format each name
$active = array_filter($users, fn(User $u) => $u->isActive());           // keep some, maybe none
$total  = array_reduce($orders, fn($sum, $o) => $sum + $o->total(), 0);  // collapse to one
?>

Countable and IteratorAggregate let a custom type declare that it behaves like zero or more without exposing its internal array at all: typing the cardinality instead of just the storage:

users[] = $user;
    }

    public function count(): int
    {
        return count($this->users);
    }

    public function getIterator(): Iterator
    {
        return new ArrayIterator($this->users);
    }
}
?>

The iterable type hint, union of array and Traversable, is PHP’s way of saying zero or more, and I genuinely don't need to know how you boxed them together:

notify($message);
    }
}
?>

Generators push this the furthest, because they can yield zero, one, or an unbounded number of values, lazily, one at a time, without ever materializing the “how many” question as a number:

isActive()) {
            yield $user;
        }
    }
}
?>

If nothing is active, the generator yields nothing and costs nothing beyond the check. If everything is active, it yields everything, one at a time, without ever holding the full set in memory. Zero, one, and infinity, genuinely unified in a single construct: not a bad way to close out the rule’s namesake.

The 8.x-era features, seen through this lens

A few newer additions to PHP line up with this pattern more directly than they’re usually given credit for.

First-class callable syntax is PHP explicitly turning a single-item operation into a value that can be handed to something that applies it across many:

 strtoupper($n), $names);
?>

strtoupper(...) doesn’t call strtoupper: it becomes a Closure version of it, built specifically to be passed somewhere that will call it repeatedly. That’s the one operation, applied N times idea, made explicit at the syntax level for the first time.

match() occasionally gets used to encode this exact rule directly, which is a nice bit of self-reference:

 'none',
    $count === 1 => 'one',
    default      => 'many',
};
?>

Enums are an interesting middle case: a fixed, compile-time many: a closed set of possibilities known in advance, where every individual case is simultaneously a singleton. Think of it as a boolean that will allow a third leg to sprout when you need it, or a fourth, a fifth (and not six, we don’t want bugs obviously):

An enum is many at the type level and one at every use site: a preview of the tension the next section runs into on purpose.

The idea PHP could finish: applying object syntax onto arrays

Now, let’s write a piece of science fiction. It’s worth noting that PHP wouldn’t be the first language to get there. Groovy’s spread-dot operator already does this at the language level:

def totals = orders*.total()
?>
[/php]

orders*.total() calls .total() on every element of orders and collects the results: no loop, no map, no proxy object. It reads exactly like calling .total() on a single order, with one extra character marking and do this to all of them.

Interestingly, there are already some experimentations in the PHP syntax with the current level of features. Laravel’s HigherOrderCollectionProxy gets close to the same effect in userland, without any language changes, by leaning on __call() and __get():

each->notify($message);
?>

->each returns a proxy object; the ->notify($message) that follows it gets forwarded to every item in the collection. It’s a library trick, not a syntax change, and it’s proof the idiom is desirable enough that people built magic-method plumbing to fake it.

PHP itself has neither. Today, going from one to many always means switching syntax entirely:

notify($message);                                    // one
array_map(fn(User $u) => $u->notify($message), $users);     // many
?>

The intent hasn’t changed at all between those two lines: only the cardinality has. Yet the code had to be rewritten from a method call into a function call wrapping a closure. A hypothetical broadcast syntax would let the array itself carry that intent, the same way [] already carries “however many” at the data level:

notify($message);   // $users is an array; call notify() on each element
?>

In this syntax, there is nothing to see. $users contains objects, and each, if any, can process a call to notify(), with the same method and arguments. This is no less readable than making it a foreach loop. No one needs three lines to understand what is happening here.

Upgrading some more syntax could be quite fun

Broadcasting only makes sense where we need to act on each element. There are some situations where we still want to work on the group, not the elements. I see two of them, and you can let your imagination run wild.

The first one is when reaching for class constants, static methods or properties. They would be always the same, as they do not depend on the object, but on the class. Of course, we could optimize this by short circuiting it to a call to array_fill(), unless there are side effects that need to be counted.

Generally speaking, a static method or property has no per-element $this to bind to. Logger::record() would stuff the same static values in the same file, again and again. This is quite a trap:

The second one is when using the current operators. Does a scalar, which are now virtually banned, auto-transform to an array, with array_fill(), to generate the same operation on each element? Nested arrays may also be worth a look.

Then,

A look at the bigger picture

PHP’s story on cardinality turns out to be further along than it looks at first glance. The container problem, that super-variable that holds zero, one, or many of something, was solved by being untyped: [] absorbs all three without ever needing a wrapper type to convert between them, which is more than most statically-typed languages can say. In fact, a large part of the PHP community tend to ditch this feature away in favor of typing strongly every single piece of data. And that might be a piece of advice I also provide, so, mea culpa.

The traversal problem is solved too, and solved very well: foreach skips empty input for free, Generators can lazily yield nothing, one thing, or an unbounded stream from the same construct, and iterable lets a function stop caring which container it was handed. Let them come to me…

What’s still unfinished is the call-site problem: the fact that do this and do this to each of these have never shared a syntax in PHP, even though the data underneath them always could. Groovy closed that gap at the language level with the star operator *.; Laravel closed a narrower version of it in userland with proxy objects. PHP has the container and the traversal machinery to make the same move: what’s missing is the verb. And a bit of syntax modernization or science fiction.

The post foreach Already Knows: PHP and the Zero-One-Infinity Rule appeared first on Exakat.

A Hard Memory Ceiling for PHP Scripts That Run for Hours - Exakat

2026-10-09T10:31:39.000Z

A Hard Memory Ceiling for PHP Scripts That Run for Hours

You inherit a legacy table full of auto-incrementing integers and a new architecture that wants UUIDs. You write a CLI worker, build an in-memory lookup array mapping old IDs to new ones, and let it run. Forty thousand rows in, the terminal stops mid-scroll and hands you the line every PHP developer eventually meet one day: Allowed memory size exhausted.

The instinctive fix is to raise memory_limit. The correct fix is to notice that you built an unbounded array and called it a lookup table. And once you’ve fixed that, a second problem is waiting right behind it: this migration runs for hours, across a table nobody trusts, on infrastructure nobody promised wouldn’t reboot. If the fix for memory doesn’t also make the script resumable, you haven’t solved anything: you’ve just delayed the crash until row two million, at which point restarting from zero stops being an inconvenience and starts being your weekend.

One structure fixes both problems, because they’re the same problem wearing two hats: an LRU cache backed by SQLite, doing double duty as a checkpoint log. Let’s see how one can do that.

Why WeakMap doesn’t apply here

PHP 8.0 gave us WeakMap, and it’s tempting to reach for it the moment “memory” and “cache” appear in the same sentence: the garbage collector drops an entry the moment nothing else references its key, no manual eviction required. It’s a real improvement over SplObjectStorage, which has been quietly holding strong references to its keys since PHP 5.3 and leaking memory in exactly the scenario you’d use it to avoid.

But WeakMap keys must be objects. In our case, the lookup table is keyed on database IDs, that is strings or integers, and WeakMap won’t accept them at all. It responds with WeakMap key must be an object, which is basically the exact contrary of the reaction of an array. Even granting yourself the trouble of wrapping every ID in a throwaway object, you’d still be trusting PHP’s generational garbage collector, incrementally improved since 7.4, but never deterministic, to decide when to reclaim memory. You want to keep control. You want a hard cap of exactly $maxItems entries, enforced on every write, not a random moment, sometime after PHP notices the cycle. WeakMap solves a reference-tracking problem. You have a capacity problem. Different tool.

Hot data in RAM, everything else on disk

The actual shape you want is a two-tier cache: a small PHP array holds the most recently touched entries, and SQLite holds all of them, unbounded, on disk. Reads check the array first; on a miss, they pull from SQLite and promote the entry into the array. Writes go to both, immediately.

PHP arrays are ordered by insertion, which makes LRU bookkeeping nearly free: unset() a key and reassign it, and it moves to the end. array_key_first() hands you the eviction candidate without a separate tracking structure. The only work SQLite does is being reliable, fast enough, and, crucially, still there after the process dies.

db = new PDO('sqlite:' . $dbPath);
        $this->db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $this->maxMemoryItems = $maxMemoryItems;

        $this->db->exec('
            CREATE TABLE IF NOT EXISTS data_store (
                key TEXT PRIMARY KEY,
                value TEXT,
                created_at INTEGER
            )
        ');

        $this->selectStmt = $this->db->prepare('SELECT value FROM data_store WHERE key = ?');
        $this->insertStmt = $this->db->prepare(
            'INSERT OR REPLACE INTO data_store (key, value, created_at) VALUES (?, ?, ?)'
        );
    }

    public function get(string $key): ?string
    {
        if (array_key_exists($key, $this->memoryCache)) {
            $value = $this->memoryCache[$key];
            unset($this->memoryCache[$key]);
            $this->memoryCache[$key] = $value; // promote to most-recently-used
            return $value;
        }

        $this->selectStmt->execute([$key]);
        $value = $this->selectStmt->fetchColumn();

        if ($value === false) {
            return null;
        }

        $this->remember($key, $value);
        return $value;
    }

    public function set(string $key, string $value): void
    {
        $this->insertStmt->execute([$key, $value, time()]);
        $this->remember($key, $value);
    }

    private function remember(string $key, string $value): void
    {
        unset($this->memoryCache[$key]);
        $this->memoryCache[$key] = $value;

        if (count($this->memoryCache) > $this->maxMemoryItems) {
            unset($this->memoryCache[array_key_first($this->memoryCache)]);
        }
    }
}
?>

It is worth pointing at the remember() extraction, because its absence is exactly where a first draft of this class would broke. set() on an existing key looks harmless, $this->memoryCache[$key] = $value, but PHP does not reorder an array on reassignment to an existing key. It only moves to the end on unset() + insert. If you sSkip that step, you have a structure calling itself an LRU cache that never promotes a re-set key. Eventually, it evicts values based on first-write order instead of last-touch order. Cheap bug, and one you’d only notice under load, exactly when you can least afford to.

The checkpoint you already own

set() writes to SQLite before it writes to the array. That means the database on disk is never more than one call behind the true migration state, which is a checkpoint mechanism, whether you asked for one or not. Use it deliberately: keep a progress table, read last_id on startup, resume from there.

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$db->exec('
    CREATE TABLE IF NOT EXISTS progress (
        id INTEGER PRIMARY KEY CHECK (id = 1),
        last_id INTEGER NOT NULL
    )
');
$db->exec('INSERT OR IGNORE INTO progress (id, last_id) VALUES (1, 0)');

$lastProcessedId = (int) $db->query('SELECT last_id FROM progress WHERE id = 1')->fetchColumn();
echo "Resuming from ID {$lastProcessedId}\n";

$fetchBatch = $oldDb->prepare('SELECT * FROM users WHERE id > ? ORDER BY id LIMIT 1000');
$saveCheckpoint = $db->prepare('UPDATE progress SET last_id = ? WHERE id = 1');
$cache = new MemoryCappedSQLiteCache('./migration_state.db');

do {
    $fetchBatch->execute([$lastProcessedId]);
    $rows = $fetchBatch->fetchAll(PDO::FETCH_ASSOC);

    foreach ($rows as $row) {
        $cache->set((string) $row['id'], generateUuid());
        $lastProcessedId = (int) $row['id'];
        $saveCheckpoint->execute([$lastProcessedId]);
    }
} while (count($rows) === 1000);
?>

That INSERT OR IGNORE seeding line is doing more work than its size suggests. An empty progress table with only an UPDATE statement pointed at it is a checkpoint that silently never checkpoints. UPDATE against zero matching rows succeeds, reports nothing wrong, and the resumable script will restart from ID 0. It’s the kind of bug that passes every manual test, because you only ever run it interrupted-and-resumed by accident once, in production, at 2am. I would recommend grepping your own scripts for that exact pattern: any UPDATE ... WHERE used as a substitute for an upsert, on a table, should be reviewed. Yes, this is me giving you homework.

The do...while around the fetch matters too. A single LIMIT 1000 query with no outer loop processes one batch and exits, which quietly turns a resumable migration into a migration you have to manually re-invoke a few thousand times. This is all fine if that’s what your process supervisor is for; but it is worth being honest with yourself about which one you want to built.

What broke	Why it passed a glance	The fix
`set()` doesn’t reorder existing keys	Looks identical to a fresh insert	Route both paths through one `remember()` that always `unset()`s first
`progress` table starts empty	`UPDATE` on zero rows raises no error	Seed the row with `INSERT OR IGNORE`before ever updating it
Single `LIMIT 1000`fetch, no loop	Runs fine, just stops after 1000 rows	Wrap the fetch/checkpoint pair in a `do...while` on batch size

The trade off of this approach

Reading through SQLite is slower than reading through a PHP array, for sure. But, what it buys back isn’t just a memory ceiling; it’s the automated checkpoint, because durability and eviction turned out to be the same write. The cost worth naming explicitly: every set() here is its own implicit transaction, so PDO commits to disk on every single row. For a migration touching millions of rows, that’s millions of fsyncs. Wrapping each 1000-row batch in $db->beginTransaction() / $db->commit() buys real throughput. This is the price to pay for the risk of losing up to one batch’s progress on a hard crash mid-transaction, instead of losing at most one row. Decide which of those numbers you can live with before you’re the one explaining the choice in an incident channel.

The bigger picture

Once a structure is durable, resumable, and survives its own process dying mid-write, it is tempting to call it a cache. In fact, a cache is allowed to lose data. In this case, it is deliberately built so it doesn’t and can’t. Every property that makes it safe for a nine-hour migration is a property a database has, not a property a cache has. The eviction policy is the only thing left distinguishing data_store from a table you’d just call your database.

In the end, we have now set up a robust system can both limit the amount of memory it uses to process even more data, and can even restart. This is a feature that rest on the shoulders of the data organisation, rather than PHP. Yet, with generators, and tools that walk datasets rather than process then in one time, it is not difficult to prepare PHP to be reborn after dying. Again, and again, and again…

The post A Hard Memory Ceiling for PHP Scripts That Run for Hours appeared first on Exakat.

Discover PHP 8.6 Through Its New Error Messages - Exakat

2026-10-05T20:16:58.000Z

Discover PHP 8.6 Through Its New Error Messages

A guided tour of what will bark at your code when you move, and how you should care now

PHP 8.6 lands in November 2025. You have a few weeks left to run your test suite on the release candidate, spot the deprecation notices, and fix them while nobody watches. Migrating now costs you an afternoon, and even if partially applied, it might improve your code anyway.

With the introduction of new features come error messages: after all, without experience yet, you might very well trespass the extend of the features. So, let’s see these new possible error messages, so you can react faster when you encounter them. If you ever do.

No more magic numbers: use the constants

PHP has always shipped named constants for function arguments. It has also always accepted raw integers instead, without a single complaint. That free ride stops in PHP 8.6 for a growing list of functions.

Take pathinfo(). Before 8.6, you could combine PATHINFO_DIRNAME | PATHINFO_EXTENSION and get… one of them. Which one? The answer depended on internal flag values abd black magic, not on logic. Now PHP throws a ValueError:

pathinfo(): Argument #2 ($flags) must be only one of the PATHINFO_* constants

The same treatment applies to array_filter(). Passing 42 as the mode used to default silently to ARRAY_FILTER_USE_VALUE. Now it rages at you:

arrayfilter(): Argument #3 ($mode) must be one of ARRAY_FILTER_USE_VALUE, ARRAY_FILTER_USE_KEY, or ARRAY_FILTER_USE_BOTH

And scandir() follows the same path, refusing invented sorting orders:

scandir(): Argument #2 ($sortingorder) must be one of the SCANDIR_SORT _ASCENDING, SCANDIR_SORT _DESCENDING, or SCANDIR_SORT_NONE constants

This trend deserves attention. PHP keeps replacing silently-accepted literal values with strict constant checks. Each time, the old behavior was to pick a default and hope nobody notices. The new behavior tells you exactly what went wrong and what to use instead. If you grep your codebase for raw integers passed to these functions, fix them now. The constants existed all along; PHP just stopped being polite about ignoring them.

Partial application arrives with guardrails

PHP 8.6 introduces partial function application, one of the most anticipated features in years. You can write add(1, ?) and get a Closure that remembers the 1 and waits for the rest. It is elegant, concise, and is also guarded by two brand-new error messages.

The first fires when you supply too many arguments during the partial call, just like any other function call, but with a reminder that you are using PFA:

Partial application of add() expects at most 2 arguments, 4 given

And a partial application cannot sneak extra arguments past the function signature. The ? placeholder reserves a slot for later; it does not magically create new parameters. What would they be used for? The body of the function is not changed by PFA, so they would be lost in translation.

The second fires when you supply too few:

Partial application of add() expects exactly 3 arguments, 2 given

Every required parameter needs either a value or a ? placeholder. If you want to defer all remaining parameters at once, use ... instead: add(1, ...) captures everything still missing. PHP checks the argument count at partial-creation time, not at call time. Better to fail early than to hand you a Closure that would blow up the moment you try to use it.

Constructors and destructors get their act cleaned up

Two long-standing PHP oddities finally get the deprecation notice they deserved for a decade. Until now, they were mostly reported by static analysis.

First, the generator constructor. Yes, you could put yield inside __construct(). Yes, it compiled. No, it never actually ran as a generator, because a generator only starts executing when iterated, and nothing iterates a constructor. The object was born with its initialization silently skipped.

Making a constructor a Generator is deprecated

Who thought this was a good idea? Nobody did. The feature emerged as a side effect of how generators work: any function with yield becomes a generator, and __construct() was no exception. PHP 8.6 recognizes this as an elephpant trap. The same deprecation applies to destructors, by the way. Geez…

Second, returning a value from a constructor. The new keyword always returns the fresh object, regardless of what __construct() hands back. Any return $value inside a constructor was dead code wearing a disguise:

Returning a value from a constructor is deprecated

A bare return; to exit the constructor early remains perfectly fine. Only return $something;triggers the deprecation, because that $something vanishes into the void every single time. And $something could have been as nothing as null.

Returning from finally, a silent killer

Here lies one of the most treacherous patterns in PHP. A return inside a finally block silently replaces whatever the try or catch was about to return. Worse, it swallows any exception that was propagating, without a trace.

Returning from a finally block is deprecated

PHP already forbids break, continue, and goto out of a finally block. A throw inside finally at least chains the discarded exception as $previous. But return got a free pass all these years, quietly eating exceptions and return values with no indication anything happened. That era ends now. Move the return out of the finally block, and make the control flow visible.

Named variadics versus internal functions

Internal functions written in C handle their variadic parameters differently from user-land functions. When you spread an associative array into array_merge(), PHP tries to match each string key to a parameter name. Since internal variadic functions only have one name for their catch-all parameter, every other key gets rejected:

Internal function array_merge() does not accept named variadic arguments

 [1], 'y' => [2]];
array_merge(...$parts); // string keys become named arguments
?>

The fix takes one line: wrap the array in array_values() before spreading it. This strips the string keys and turns them into plain numeric indexes, which the variadic parameter happily accepts. If your data comes from a database query or a JSON decode, string keys might lurk where you expected none. Apply array_values() as a habit, just in case.

NAN walks into clamp

PHP 8.6 ships the new clamp() function, which restricts a value to a given range. Simple, useful, and immediately confronted with the eternal troublemaker of floating-point arithmetic: NAN.

clamp(): Argument #2 ($min) must not be NAN

The fundamental problem with NAN is that any comparison involving it returns false. Ask “is 5 greater than NAN?” and the answer is no. Ask “is 5 less than NAN?” and the answer is also no. A clamping function built on comparisons cannot do anything meaningful with a bound that defeats all comparisons.

Note that NAN is technically a float. It passes type checks, it slips through type declarations, and it arrives in your code disguised as a perfectly normal number. The range() function already rejects it with “must be a finite number, NAN provided”. Now clamp() does the same. Validate your floats with is_nan() when they come from untrusted sources.

Note that range() had a similar problem with NAN, and INF for that matter. You could get that nice error message:

So, PHP is able to handle infinite numbers. That should attract attention of mathematicians, I guess.

Virtual properties resist lazy introspection

PHP 8.4 introduced property hooks and lazy objects. PHP 8.6 discovers that these two features do not always get along.

A virtual property, that is declared with only a get hook and no backing storage, has no memory slot for storage. The lazy objects API, specifically ReflectionProperty::setRawValueWithoutLazyInitialization(), tries to write directly to that memory slot. When the slot does not exist, the method has nothing to write to:

Cannot use setRawValueWithoutLazyInitialization() on virtual property Foo::$bar

 5; // virtual: no storage
    }
}

$prop = new ReflectionProperty(new Foo, 'bar');
$prop->setRawValueWithoutLazyInitialization(new Foo, 2);
?>

Only properties with actual backing storage, those whose hooks reference $this->propName, support raw value manipulation. Virtual properties compute their value on the fly and have nothing to bypass. If your lazy-object initialization code touches property hooks, check which properties are virtual before calling the raw setter.

The readonly function reaches end of life

When PHP 8.1 introduced readonly as a property modifier, the team carved out a compatibility exception: a global function literally named readonly() could still be declared and called, because WordPress shipped one. That exception kept the peace for four versions. In PHP 8.6, the moratorium ends:

Calling a function “readonly” is deprecated

The deprecation notice fires on every call, not on the declaration. Declaring the function still works, for now: it is only a deprecation. And here is the fun part: readonly as a method name remains perfectly legal. You can call $obj->readonly() all day long without a single warning. The deprecation targets only bare function calls, as part of the broader effort to fully reserve readonly as a language keyword.

If you maintain a library that defines a readonly() function, rename it. Pick isReadonly(), pick asReadonly(), pick anything that will not collide with the language in PHP 9.0.

The takeaway

PHP 8.6 cleans house. It replaces silent fallbacks with explicit errors, deprecates patterns that never worked as intended, and sets boundaries around its newest features. None of these changes will surprise you if you run your test suite against the RC today.

Every error message mentioned in this article links to its full documentation at php-errors.readthedocs.io, with code samples, explanations, and migration advice. When PHP hands you a new error message, look it up there. The answer already exists.

Go test your code. November gets closer every day.

The post Discover PHP 8.6 Through Its New Error Messages appeared first on Exakat.

Apidays London 2026 - Rob Allen

2026-10-05T10:00:00.000Z

Last week I attended FOST London 2026, mostly I was there for apidays and the OpenAPI Initiative track. As ever, there was a set of excellent talks and I particularly liked Abby Bangser's opening keynote, Steven Willmott's talk on how to think about software systems as AI is added to them, and Kristof Van Tomme's thoughts on where developer portals fit into today's AI world.

The OpenAPI track was excellent. We started with Frank Kilcommins covering API workflows before Lorna Mitchell talked about upgrading your OpenAPI spec to the latest 3.2. She really put it into perspective on how old version 3.0 is, and the benefits of updating to the latest version. Kin Lane followed with an interesting talk on OpenAPI extensions and how the help expand your specification, particularly when tied together with Overlays. He was followed by Chris Wood explaining the proposals around security that are in-flight at the moment.

There's a lot going on in the OpenAPI world and I will be paying more attention than I have. In particular, the security proposals look interesting and worth helping out on if I can. I also want to bring the OpenAPI story at one of my clients up to the latest version and see what we can leverage when we're there.

Another talk I was particularly happy to attend was Afsha H.'s talk on accountability in systems where agents work more autonomously. It's important that humans are responsible and do not hide behind "the agent did it", and Afsha's talk provided the things to think about. It was Afsha's first in-person technical conference talk and she knocked it out of the park.

In addition to the talks, the hallway track was good and I met new people starting out in the industry and caught up with old friends. The conversations were interesting and thought-provoking and I find it a very good way to learn new things from people who are actually doing and thinking about them.

It was fantastic to catch up with Phil Sturgeon too, which included a visit to the pub! Donate to his charity as he's doing amazing work.

If you're into APIs, I recommend attending a conference to find out where the industry is today. As Mehdi Medjaoui said at the start, conferences are where the humans connect (but we won't mention the SOAP joke!).

Partial Function Application : Building the Call Along the Way - Exakat

2026-10-02T10:18:50.000Z

Building the Call Along the Way

A function call is always atomic with PHP. The target and every argument must converge at the same place, at the same moment, or nothing happens. This doesn’t sound like a limitation, rather a cooking recipe: you’re not going to start your strawberry pie in Winter, with the pie crust, and wait for the fruits to be in season a few months later. Yet, the some ingredient may be mixed, and completed later with the rest of it. Sometimes, the kitchen counter is too small.

In comparison with source code, it means that every call site carries the full weight of assembly. When three arguments are known at boot time and the fourth arrives with the HTTP request, the developer bridges that gap with structure: a closure, a class, a wrapper function, or a re-fetch of values that were perfectly available ten layers up. The bridge costs code estate, and the writing stays hardcoded long after everyone forgets why it exists.

Partial Function Application, landing in PHP 8.6, removes the constraint, at least partially. A call can start where the first arguments live:

and finish wherever the last argument finally shows up:

The ? placeholder marks an open slot. What travels between the two lines is a Closure and not a hand-written one. PHP derives it from the target function, preserving names, types, defaults, and attributes. Reflection can read it. Static analysis can follow it. The half-made call is a first-class value.

Now, a value that nobody calls is a value that does nothing. PFA closures can be assembled patiently, one argument at configuration time, another at wiring time, a third when the request arrives, and then never be executed. The call was built; the actual call may well never be made. Between now and execution, there might be other condition that apply, and lead to the cancellation for the call. In other times, the arguments would have been grouped and moved, but not used at any level. Similar waste, if you ask me.

Whether that trade-off matters depends on how the partial function applications travel through the codebase, and on the patterns they replace. Let’s see what we can read from the current source code, before the new features gets activated.

The closure, by hand

Before architecture, there is instinct. When some arguments are known and others are not, the PHP developer reaches for a closure:

 in_array($s, $legal, strict: true);
?>

This closure is partial application, performed manually. The known value enters through use, or through automatic capture in arrow functions, the open slot becomes a parameter, and execution waits for the caller. The RFC calls the hand-written form “cumbersome” because it forces the author to redeclare every parameter name and type: this is information the target function already carries.

PFA replaces the ceremony:

One expression. No parameter list, no type annotations, no use clause. The resulting closure inherits its signature from in_array, and in particular, the subset of parameters that ? left open.

A Class’s job: the closure, objectified, again

When the open slots need names, discoverability, validation, or collection across many steps and many files, the closure grows into a class. A class whose entire purpose is storing arguments until someone calls run():

withDataSource($db)       // known at wiring time
    ->withFormat('csv')         // known at configuration time
    ->withDateRange($range)     // known at request time
    ->run();                    // the actual call, finally
?>

Query builders work this way. Doctrine’s QueryBuilder chains select(), where(), orderBy(), then getResult(). Fluent option resolvers, mock builders in test frameworks, HTTP request builders: the pattern occurs everywhere a call’s arguments arrive in stages.

Each of these classes is a partially applied function written as a type: one field per open slot, one setter per argument, one terminal method for the deferred invocation. The cost scales with the number of arguments: fields, setters, validation, a terminal method, a class per call shape.

PFA collapses the pure-plumbing cases into an expression:

publish(DateTime::now(), ...);
if ($shouldPublish) {
    $publish();
}
?>

The ... after the last provided argument signals that everything else remains open, producing a zero-argument closure — a delayed call. No class needed.

Builder classes that carry domain logic, cross-slot validation, conditionals, negotiated defaults, remain classes. PFA replaces argument warehouses, not argument processors.

Code inverted around the last argument

The subtlest workaround, and the most pervasive. Since all arguments must exist at the call site, code migrates to the location of the scarcest argument. The late value becomes the organizing principle:

The function lives here because $title lives here. Everything else, $legal, $locale, gets fetched on the spot, re-derived at every call, because there was nowhere to put it earlier. The shape of the code follows data availability, not logic.

PFA inverts the organization. Stable arguments bind where they originate; only the volatile one stays open:

Larry Garfield, who authored the RFC, notes on the PHP Foundation blog that most uses in practice will follow this shape: reducing a function down to a single remaining argument, applied when the callback’s single parameter arrives. Currying, in everything but name. No, not the basketball player.

The grandmother of all partial applications

The oldest workaround predates closures, predates first-class callables, predates everything. When the same function keeps appearing with the same leading arguments, the developer promotes it to a named wrapper:

This is a hand-compiled partial application, fossilized into a function definition. Codebases are full of them. Entire CMS ecosystems run on stacks of such wrappers, passed as string callables, or called as a global function, always available. In a way, PFA are hunting down global functions, the way we ostracized the global variables:

The wrapper is static and greppable, so any IDE finds it, any code search locates every call site. PFA replaces the wrapper with a runtime value:

The gain is dynamism: str_replace($from, $to, ?) adapts to its inputs, and no signature gets duplicated. The trade-off is indirection: the call shape lives one step away from the function name. Both forms coexist in PHP 8.6. The named wrapper becomes a choice, not the only option.

But the repeated call without a wrapper remains the pattern most vulnerable to drift:

The day the rule changes, every site needs editing. PFA consolidates the rule into one configuration point:

One place to change. Every completion site just calls $underscore().

The trio

These three features form a long story arc, across PHP versions.

First-Class Callable syntax, since PHP 8.1, proved that a call can be held before being made. trim(...) wraps the function into a Closure with all arguments pending.

The pipe operator, since PHP 8.5, gave the held call a canonical place to complete. $input |> trim(...) feeds the value and executes in one step: no intermediate variable, no nested parentheses.

PFA, with PHP 8.6, fills the gap between the two: the call can be assembled gradually, one argument at a time, between first-class capture and pipe completion. Garfield calls pipes and PFA “the twins, reunited.”

 str_replace(' ', '-', ?)
    |> strtolower(?)
    |> trim(?);
?>

Spotting PFA candidates in today’s code

Let’s switch our hat, and take the static code analysis one. The workaround family doubles as an audit map. Every workaround still in a codebase marks a spot where PFA can slot in.

Relay closures: the highest-frequency target. Any arrow function whose body is a single call, whose parameters appear verbatim among the call’s arguments, and whose body contains no logic beyond the call itself:

Hand-written form	PFA form
`fn($x) => f($x, $a, $b)`	`f(?, $a, $b)`
`fn($x) => f($a, $x, $b)`	`f($a, ?, $b)`
`fn($x) => $this->repo->save($x, $this->tenant)`	`$this->repo->save(?, $this->tenant)`
`fn() => $svc->flush($em)`	`$svc->flush($em, ...)`
wrappers inside pipe chains	`$x \\|> f($const, ?)`

Closures that contain conditions, transformations, null-coalescing, or multiple statements stay closures. PFA replaces the relay, not the logic.

Repeated literal calls: str_replace(' ', '_', ...) scattered across files, $date->format('d/m/Y') copy-pasted through a template layer. Grep finds them. Each cluster is one PFA closure built at configuration time, completed at each call site.

Argument-warehouse classes: the vanishing test settles these. If PHP had always had PFA, would this class exist? If the class stores arguments and forwards them to a single real call, it converts. If it validates, negotiates, or branches on its stored values, it stays.

Waste by absence

PFA closures are cheap to create and carry no side effects until called. That is the feature, and here is a related risk.

A closure built at boot time and stored in a container costs memory for the lifetime of the request, whether or not any code path reaches it. A builder class had the same cost, but the class was visible: it had a name, a file, an import statement. The PFA closure is a value in a variable. Nothing in the code advertises that it was prepared but never used.

The preparation cost is small in isolation. Multiplied across a container that eagerly builds PFA closures the way it eagerly builds services, it accumulates. And it does it silently, because the closures leave no trace of non-execution, and no naming conflict in case of repetition.

Static analysis could flag this: a PFA closure assigned but never invoked on any reachable path. That pattern is detectable. Now, imagine that the execution is conditional: cannot get the 4th parameter? well, we’ll throw an exception, and forget it.

PFA will impact the code organisation by linking several methods in a series of steps to build the final call. Either the closure is completed with a new argument, or it is passed to the next step intact, and it is eventually executed. It is now a lot easier to follow how a specific function is executed, and it is always good to see how conditions are applied to data.

I also wonder if PFA will generate a family of function with long list of arguments. After all, a PFA make more sense the more arguments there are.

The post Partial Function Application : Building the Call Along the Way appeared first on Exakat.

After running into one too many error because my PHP application opened too many files on Mac OSX, I learned about ulimit and its opened file soft limit. There were many others, that are worth learning about.

Two Rooms, Two Atmospheres

PHP’s directives are the polite layer. When you hit memory_limit, you get a catchable fatal error with a message telling you exactly what happened. When you hit a ulimit, and the kernel sends a signal, usually SIGKILL or SIGXCPU or SIGXFSZ, and your process is simply gone. No stack trace, no log line, no register_shutdown_function call in most cases. One process, formerly running: a ghost that never was.

Concern	PHP directive	ulimit flag	What happens when you cross it
CPU time	`max_execution_time`	`-t`	Catchable timeout, then `SIGXCPU`/`SIGKILL`
Memory	`memory_limit`	`-v` (address space), `-d`(data segment)	Catchable fatal, then process killed
Upload size	`upload_max_filesize`	`-f`	`SIGXFSZ`, then killed on repeat
Stack depth	none (until 8.3)	`-s`	Catchable `Error` since 8.3, `SIGSEGV` before
Open files	none	`-n`	`fopen()`/`fsockopen()`return `false`
Child processes	none	`-u`	`pcntl_fork()` fails, `EAGAIN`
Core dumps	none	`-c`	Core file written or suppressed

That table is the short version of this article. Everything below is what happens in the gap between the second and third column.

This is most useful in three places: shared hosting, where one tenant’s runaway script cannot be allowed to starve the others; containers, where the orchestrator enforces limits from outside PHP entirely; and development, where I’d rather discover a resource assumption on my laptop than in production. A dev environment that is more permissive than prod is a dev environment making you way softer than you should.

CPU Time: A Warning Shot, Then None

max_execution_time throws a catchable fatal error, and PHP still runs your registered shutdown functions afterward. You get a chance to log the timeout, flush a buffer, close a connection. ulimit -t gives you none of that by default: cross the soft limit and the kernel sends SIGXCPU; cross the hard limit and it’s SIGKILL, uncatchable. On a Docker container running a worker script, this is the difference between “we logged a timeout” and the container just restarted, for no apparent reason.

The one point to note: SIGXCPU is catchable, if you bother.

ulimit -t 5   # soft limit hit at 5s, SIGXCPU fires; hard kill follows shortly after
php burn.php

File Size: Not as Silent as It Looks

upload_max_filesize caps what PHP accepts over HTTP. ulimit -f caps what the process may write to disk, and it is stricter than the “fopen just returns false” story usually told about it. A write() that starts past the limit fails with EFBIG and delivers SIGXFSZ to the process, which terminates it by default, same as any other unhandled signal. Only a write that starts below the limit and crosses it gets the gentler treatment: a short write, fewer bytes than requested, no signal at all.

If you want the false-return behavior people expect, ignore the signal first:

The writing basically limit the total size of the file. If the application proceeds with bite-size appends, it will still stop once the file pass the threshold set by the operating system.

On the other hand, ulimit -f does not affect reading from files.

Memory: Two Different Ceilings Wearing the Same Name

memory_limit tracks what the Zend engine allocates for PHP values: arrays, objects, strings, resources. ulimit -d, for data segment, and ulimit -v, for virtual address space, are OS-level ceilings on the whole process: PHP binary, extensions, shared libraries, everything. Hit memory_limit and you get Allowed memory size exhausted. Hit -v and the kernel kills the process outright.

One nuance worth knowing before you rely on -d: modern glibc malloc() routes large allocations through mmap() rather than growing the classic data segment, so ulimit -d can undercount what your process is actually holding. ulimit -v, which bounds total address space regardless of how it got mapped, is the one that reliably catches PHP’s big allocations.

<# belt and suspenders: PHP warns first, the OS enforces the hard ceiling
ulimit -v 524288   # 512MB in KB
php -d memory_limit=256M script.php

Stack Depth: PHP Caught Up in 8.3

Deep recursion used to mean a segfault once you hit ulimit -s. This is not a PHP error, just a dead process, often mid-request. PHP 8.3 added zend.max_allowed_stack_size, and now the engine checks its own call stack against that budget and throws a catchable Error before the OS ever gets involved:

getMessage(), PHP_EOL;
}
?>

ulimit -s is still there underneath as the hard backstop, set it too low and you can still starve the Zend stack before PHP’s own guard has room to react, but for the ordinary “someone forgot a final condition” bug, PHP now catches its own mistake before the kernel has to.

File Descriptors: The Most Popular Of All

ulimit -n is the limit you will meet first, because macOS ships a default soft limit of 256, and any script that opens a handful of files, a couple of database connections, and a cURL handle or two can get there faster than seems reasonable.

ulimit -n        # check the current soft limit
ulimit -n 10000   # raise it for this shell session

No exception is thrown. fopen(), fsockopen(), a fresh PDO connection: they all just hand back false or an exception you may not be catching. Sometimes, there is also a warning message telling you the file could not be opened. That is true, and that is misleading. It produces the most confused bug reports. The fix is almost always that someone forgot to check a return value, and the person debugging it wasn’t the person who wrote that line. At best, it was himself, six months prior.

Processes and Core Dumps, Briefly

ulimit -u caps how many processes your user may run at once, relevant the moment your app forks workers or shells out repeatedly pcntl_fork(), proc_open(), a queue worker spawning children. Cross it and you get EAGAIN, “resource temporarily unavailable,” which reads like a transient network error and isn’t.

ulimit -c controls core dump size. Core dumps are gold for debugging a segfault and a liability if they land on disk in production with a database password sitting in memory. Set it to 0 outside of a debugging session:

ulimit -c 0        # no core dumps
ulimit -c unlimited  # full core dumps, for a debugging box only

Asking the OS From Inside PHP

posix_getrlimit() reads every limit at once; posix_setrlimit() also exists, to set the same limits, within whatever ceiling the hard limit already allows. So you can’t break free from them, but make them even tighter: it reminds me of certain knots.

An unprivileged process can only move its soft limit up to its hard limit, and can only ever lower the hard limit. If you need a higher ceiling than the hard limit allows, that change happens outside PHP, in /etc/security/limits.conf, the systemd unit, or the --ulimit flag on docker run.

Breaking It on Purpose

The most useful thing you can do with ulimit has nothing to do with production. Set -n to 10 and run your test suite. Set -v to something your app should never approach. Watch what falls over.

( ulimit -n 10 && ulimit -v 65536 && php vendor/bin/phpunit )

The subshell keeps the tightened limits from leaking into your regular terminal. What breaks under this is usually not a bug in the strict sense: it’s every place your code assumed a resource would always be there, written down as a stack trace instead of as a comment.

Watching What PHP Has Open

PHP has no built-in inventory of its own open file descriptors. get_included_files() tells you what got required; php_ini_loaded_file() and php_ini_scanned_files() tell you which .ini files were read. None of that is the same as the list of files descriptors currently open, and extensions open handles of their own that never surface in any PHP-level list. Actually, exceptions may also be an opened file by themselves. For the real picture, ask the kernel:

lsof -p $(pgrep -f 'php-fpm: pool')

May be we could request such a function as a native PHP one. It could be useful to improve performances, by reducing the number of opened files.

Where the Two Resource Constraints Actually Meet

Use ulimit for the limit that must never be crossed, no matter what PHP thinks it’s doing, including bugs or by-pass: a worker script that must die rather than eat the box, a shared host where one tenant cannot be allowed to take the others down. Use PHP directives for the limit you want a chance to react to. Although, in practice, it is rare to take time to climb out of such holes.

In practice you want both, tuned so the soft one fires first:

; php.ini — the polite warning
memory_limit = 256M

# the hard backstop, set where the process actually starts
ulimit -v 524288  # 512MB, comfortably above 256M
php-fpm

The gap between the two numbers is your reaction time. Make it wide enough to matter and narrow enough that the OS limit isn’t just decorative.

The pitfalls, in short: don’t assume fopen(), file_get_contents(), or PDO‘s constructor will always succeed. Check what they return, especially in code that runs under a tightened ulimit. Don’t tune limits only in staging and assume production behaves the same under real load. And close what you open; a script that never calls fclose() is a script slowly negotiating its own file-descriptor limit downward.

Conclusion

ulimit is the layer PHP’s error messages were never going to warn you about, because PHP doesn’t get informed before the kernel acts. It finds out the same way you do, by no longer running. Treat the two layers as complementary: PHP’s directives for the failure you want to observe, ulimitfor the one you want to guarantee.

The open question is the one from the “breaking it on purpose” section, generalized: if a resource assumption is worth catching in production, why is ulimit -n 10 not part of the test matrix already, next to the PHP version and the database driver?

How to lint PHP code within the source - Exakat

2026-09-28T08:53:11.000Z

How to lint PHP code within the source

Ahead-of-time languages check a closed world. Compile a Rust crate, a Go module, a C project with two functions named parse_config, and you never get to run anything at all: the compiler builds the whole symbol table before it hands anything to a linker, and a duplicate name is a compile error you read on a screen that has executed exactly zero lines of your program. Everything gets loaded, every symbol gets resolved, every collision gets flagged, and only then does a single instruction run. The checking and the running are two different eras, and the first one is not allowed to end quietly.

PHP was never built this way. There is no linker, and there is no moment where the language looks at your whole codebase and pronounces it sound and complete. It compiles and runs file by file, as include and require pull them in, in whatever order your own conditionals decide today. A “PHP program” isn’t a fixed graph of symbols the way a Rust crate is: it’s whatever subset of your files happened to get pulled into this particular execution, given this particular input. So the question “is this PHP code valid?” is not a single question. It’s actually three distinct questions. Let’s see what we can understand of these.

Lint PHP like a human being

The obvious move, from inside a running PHP process, is to treat PHP as a black box and interrogate it from outside:

This totally works. It’s also faintly absurd: you are already running an interpreter, and your answer to “does this code parse” is to fork a second one, wait for it to boot, and scrape its stdout. It’s the “turn it off and on again” of static checking: dependable, and a small admission that you don’t trust the interpreter you’re standing inside of. It’s also the wrong tool the moment you want this per-keystroke in a language server rather than once per CI run: a process fork per file doesn’t scale to that, and it hands you a string to grep instead of a tree to walk.

The only valid use case is when you want to test the code with a different PHP versions than the one you’re currently running. But that is a specific use case for static analysis authors, so that doesn’t apply to a lot of us.

PHP can answer the same question about itself, natively, three times, at three different depths. The hidden issue is that all these answers cover different grounds. They don’t check the same thing than the previous one, but more. They check three non-overlapping categories of rules, and the deepest one only agrees to check anything if you also let it run.

All your tokens are belong to us

token_get_all(), or its object-oriented sibling PhpToken::tokenize(), added in PHP 8.0, is a pure tokenizer. It pattern-matches its way through a string and hands back an array of tokens. It has no concept of grammar, no concept of balance, no memory of what it saw two tokens ago.

That is not a bug in the tokenizer, it’s the entire point of it: a syntax highlighter has to colour code you haven’t finished typing yet, and a formatter has to touch files that don’t compile so it can hand them back still broken but reindented. Rejecting anything would make it useless for the one job it’s actually built for.

In fact, it is quite possible to clean these tokens, or invent pre-processing rules on these tokens, that could produce valid PHP code.

Tokens, meet grammar rules

token_get_all($code, TOKEN_PARSE), added in PHP 7.2, feeds the same tokens through PHP’s real parser, that is the one that builds the Abstract Syntax Tree PHP itself compiles from. Now grammar actually matters, and a real ParseError shows up, catchable this time:

getMessage();
    // syntax error, unexpected end of file, expecting "," or ";"
}
?>

The same string handed to plain token_get_all() returns four tokens and no complaint at all. Such a dangling statement isn’t a lexical fact, it’s a grammatical one, and the default tokenizer doesn’t have grammar. TOKEN_PARSE does, but a parser only builds a tree; it has no symbol table. You can ask it something that requires remembering a name across two declarations rather than reading a declaration’s shape, and it goes quiet. This is because it isn’t a grammar fact either:

Grammatically, nothing is wrong here. The parser checks each declaration in isolation against a rule that checks if this looks like a class, or an interface or else; it was never asked to remember which names it has already seen. Naming is difficult, and it it the next step.

The Only Judge That Counts

Run the same string instead of parsing it, and the compiler finally objects:

Note that is not a catchable error. Try to wrap it in try/catch (\Throwable) and this still ends the script. It requires PHP to actually compile the file into opcodes and register each declaration into the runtime’s symbol tables as it goes. That pass lives in the execution phase of PHP, not only the parsing side.

Here PHP has one more surprise, and it part of the folklore of PHP syntax. Forward references work! You can call a function or instantiate a class defined further down the same code, because unconditional top-level declarations get bound early, during compilation, before the first opcode runs. So does that mean a duplicate class is caught the same way, as a fact about the whole file, before anything executes? Put an exit() between two unconditional declarations and ask PHP directly:

reached
stopped
?>
[/php]


No fatal error, ever. The second class A {} needed to actually execute to be judged, and exit() denied it the chance. The redeclaration simply never happened. Do the identical experiment with two function f() {} instead, and the file dies before printing a single character:

PHP Fatal error:  Cannot redeclare function f() (previously declared on line 2) in ... on line 5
?>
[/php]

echo "reached\n" never fires. The conflict was caught during compilation of the whole file, exactly the way an AOT linker would, before execution had a chance to reach line 2. Traits and interfaces side with classes, not with functions: believe me, bro, I checked all three. So of PHP's three kinds of user declaration, exactly one gets the ahead-of-time treatment, and it's the one nobody would have bet on. Class, trait, and interface collisions are genuinely runtime facts, dependent on which lines actually execute, and if autoload is triggered or not; function collisions are compile-time facts about the file as a whole, indifferent to whether execution ever gets there. The same keyword, eval, enforces two different eras of checking depending on which kind of name you handed it.

Now, you can put a class inside a conditional, and this runtime dependency stops being a curiosity and starts being a way to hide a collision entirely:




Two declarations named Formatter. Neither TOKEN_PARSE nor a hundred ordinary runs of this file will ever complain, because a single run only ever walks one branch — one Formatter gets declared, no collision, forever, as far as that execution is concerned. The clash isn't a property of the text. It isn't even a property of a single run. It only exists across runs that disagree with each other about $legacyMode, which is a sentence that has no meaning until you fix an execution and then fix another one to compare it against.
What Each One Actually Sees




tokenizes text
checks grammar
catches ParseError
catches a class/trait/interface collision
catches a function collision




token_get_all()







token_get_all(TOKEN_PARSE)







include / eval



only if that line executes
always, whole file, before anything runs



When I wrote this table, I realized it looks like a ladder: each string of checks is strictly stronger or longer than the last. But I had to stop using emojis for the last last two columns: include doesn't have one uniform "now I also check declarations" superpower, it has two different policies depending on what kind of name is colliding, and only one of those policies is the AOT-style, whole-file, checked-before-anything-runs guarantee the opening of this piece described. The other is a genuinely runtime fact. It is true only when a specific execution reaches the conflicting line, silent about every execution that didn't. You can't know before execution starts, and, even at that, long time after it has started.
Under an ordinary php-fpm request, that silence is almost cosmetic: each request is a fresh process, one branch wins, the process dies, nothing ever compares notes with the branch that didn't run. Under a persistent worker, such as RoadRunner, Swoole, FrankenPHP, or any of the newer tools that makes PHP run for a long time, that isolation is exactly what's gone. An early request can take the legacy branch, a later request B can take the modern one, in the same worker, and the two class declarations that a linter, a parser, and every previous request found perfectly innocent finally meet, weeks after the branch was written. Kaboom.
Static analyzers exist to close this gap without paying for an execution: Psalm, PHPStan, exakat's own engine walk both arms of every branch at once, something no single run of include will ever do. That's real ground gained over the three built-in tools above. But it's an approximation of running every path, not a report from having run one, and it inherits every hazard of predicting a program instead of asking it. Which leaves an uncomfortable question to answer: is this PHP code valid? The lexer won't answer completely, the parser won't answer completely and it is still down to the PHP engine, during execution, to check how something is running or not.
Unless you write the code without any possible branching such as the one we covered above.
The post How to lint PHP code within the source appeared first on Exakat.



Four ways to count to four: PHP strings, iconv, mbstring and grapheme - Exakat
2026-09-25T16:48:05.000Z
Four ways to count to four: PHP strings, iconv, mbstring and grapheme
Nothing like starting the day with a nice café, in a Parisian café, pun intended. Now, when you ask PHP how long the word "Café" is, you get four answers from four families of functions. Two of them agree, one says 5, and the fourth is waiting for you to add an emoji before it gets interesting. A croissant 🥐 for sure.
PHP is blessed with no more than four string toolboxes. Until recently, I was only aware of three of them, so I’ll start by a review of them all:

Native string functions, such as strlen(), substr(), strtoupper()…, which count bytes. They’re fast, always available, and they have no idea what a character is. Did I say they count bytes?
iconv, with iconv_strlen(), iconv_substr()… count code points. Code points are identifier for characters in an encoding, such as Unicode, but not only. They cover a huge number of characters, beyond the 256 range of bytes. iconv is a small extension with a narrow job: converting between encodings.
mbstring, with such function as mb_strlen(), mb_substr()… also counts code points. It’s the big extension, with more than 60 functions. They overlap native functions, and deal with multi-bytes strings.
grapheme functions from intl, with grapheme_strlen()…, count what a human would call a character. That solves the problem of characters build with different code points. This is a nuance, and it pays to know where it brings value to the code.

Let’s see where all these functions and extension agree, and where they don’t. Obviously, they will.
Round 1: how long is a string?




A whole table of figures to count a string does require some explanations:

strlen() counts bytes. That’s not a bug, it’s the job description. Use it for buffers, binary protocols and Content-Length.
mb_strlen() and iconv_strlen() agree on everything: they both count Unicode code points.
Only grapheme_strlen() sees what your users see. The accented é has two spellings in Unicode, called precomposed and decomposed, and only grapheme gives both the same length. The family emoji is five code points glued together with zero-width joiners. The flag is two “regional indicator” letters, F and R, which fonts merge into a flag.

If you validate a “max 20 characters” username field with mb_strlen(), a user with a family emoji in their nickname gets charged 5 characters for it. If you use strlen(), they get charged 18. That’s steep for a family.
Round 2: how to slice a string
Measuring is harmless. Cutting is where things get serious and break:




substr() cuts in the middle of a multibyte sequence and leaves invalid UTF-8 behind. Your database may reject it, or quietly save a lovely ?. mb_substr() never breaks a code point, but it can still separate a letter from its accent, or a dad from his family. Only grapheme_substr() keeps a grapheme together.
Negative offsets work everywhere. Three families agree on the result, and the fourth brings its own:




Half a crème is still less than you ordered.
Round 3: how to search in a string
This is where the families are closest, and also where the surprises hide.




Here’s the useful bit: for valid UTF-8, strpos() is correct for “is this in there?” A UTF-8 sequence can never match in the middle of another one, so str_contains(), str_starts_with() and str_ends_with() are safe. This is lucky, but it works.
You only need the mb_ version when you want the position as a character offset, for example to hand it to mb_substr(). Mixing byte positions from strpos() with mb_substr() is a classic bug.
Case-insensitive search is a different story:




And grapheme has opinions about what counts as a match:




Depending on your use case, that’s either exactly right or a nasty surprise. Search engines and word filters love it. Code that searches with grapheme_strpos() and then cuts with substr() does not.
Some more edge cases
Out-of-range offsets are one area where all four agree: they throw the same ValueError.




Empty needles are where they split:




iconv never got the PHP 8.0 memo about empty needles. It’s been busy converting charsets.
Round 4: upper, lower and the case of longer uppercase strings




Since PHP 8.2, strtoupper() and friends ignore the locale configuration of the system and only handle ASCII. That way, th feature is more predictable, and it’s also wrong for anything past the letter z. mbstring handles Unicode case mapping, including the German ß, which turns into two letters when uppercased. So that universal truth that “uppercased string has the same length” assumption just failed an exam.
iconv has no case conversion functions at all.
Grapheme also has no case conversion, but that is handled by the rest of the intl extension, which is the host of Grapheme: the IntlCharhas the methods you need. Grapheme’s case-insensitive search does case folding internally, so it won’t give you the result.
Round 5: how to deal with invalid strings
Now let’s feed them invalid strings. By that, we mean strings containing invalid UTF-8 since PHP string are always valid as the byte level. Yet, invalid UTF-8 is the the way of real life:




Four functions, four attitudes:

native doesn’t care, as expected. It’s valid.
mbstring keeps going,
iconv complains,
grapheme returns null, which isn’t even in the traditional int|false return value.

So if (grapheme_strlen($s) === false) will never catch that error. Validate first with mb_check_encoding($s, 'UTF-8'), or clean up with mb_scrub(), which gives "abc?def".
Round 6: all together now, splitting, padding, trimming, reversing




mbstring has been catching up quickly: mb_str_pad() in 8.3, then mb_trim(), mb_ltrim(), mb_rtrim(), mb_ucfirst() and mb_lcfirst() in 8.4. There’s still no mb_strrev() though, but it may come some day. The usual workaround is implode('', array_reverse(grapheme_str_split($s))), and yes, it should be grapheme. Reversing by code points moves accents onto the wrong letters, which is a creative way to write French.
Round 7: converting strings
iconv has 10 only functions, and the most important one is the eponymous one: iconv(). This is where it earns its place.




//TRANSLIT is great for slugs, but there’s a catch: the result depends on the underlying C library. The output above is from glibc, so check ICONV_IMPL. On Alpine’s musl, or on older libiconv builds, you may get ? or false instead. Your Docker image just became part of your business logic. If you need a slug that’s reproducible everywhere, intl’s Transliterator::transliterate('Any-Latin; Latin-ASCII', $s) is the portable choice.
For plain conversions like UTF-8 <=> ISO-8859-1, both work:




mbstring also has encoding detection, with mb_detect_encoding(), to be taken with a large grain of salt, HTML entities, Japanese kana conversions with mb_convert_kana(), and display width:




This is handy for aligning console tables, and nobody else offers it.
What the string families have in common
Before the scoreboard, here’s what’s shared, because it’s more than you’d expect:

Same naming pattern, strlen -> mb_strlen / iconv_strlen / grapheme_strlen. The same goes for substr, strpos, strrpos. Swapping one family for another is mostly a search-and-replace, which makes it tempting to do without thinking. Just remember some behavior and return values may change.
Same signatures and conventions. Negative offsets, false when nothing is found, and ValueError on out-of-range offsets since PHP 8.0.
Same answer on simple text. On ASCII, all four agree. That’s exactly why the bugs survive testing: your test suite is written in English.
Configurable encoding for mbstring and iconv: mb_strlen($s, 'ISO-8859-1'), iconv_strlen($s, 'ISO-8859-1'). Both default to default_charset, which is UTF-8. Grapheme is UTF-8 only. By the way, mb_strlen($s, '8bit') is a well-known alias for strlen().
None of them normalize. "Café" === "Cafe\u{0301}" is false, whichever family you pick. Use Normalizer::normalize() from intl before comparing, hashing or storing unique keys.

The scoreboard




native
iconv
mbstring
grapheme




Unit
byte
code point
code point
grapheme cluster


Functions
~100
10
65
10


Always available
✅
usually
usually
needs intl


Case conversion
ASCII only
❌
✅ full Unicode
❌


Case-insensitive search
ASCII only
❌
✅
✅


Split / pad / trim
✅ (bytes)
❌
✅ (8.3/8.4)
split only (8.4)


Invalid UTF-8
ignores
false + notice
counts bytes
null


Empty needle
0
false
0
0


Encoding conversion
❌
✅ (libc dependent)
✅
❌


Speed
🚀
🚗
🚗
🚲



I just could not resist using emojis in an article about unicode and string manipulation. Sorry, not sorry.
So, which to use in what situation?

Bytes, for storage, protocols, hashing, str_contains() on valid UTF-8: native functions. They’re not wrong, just literal. And fast.
Text processing for case, trimming, padding, code-point offsets: mbstring. It’s the most popular for multilingual code in PHP codes, so it is safe. If you want to prepare for the future, consider moving to intl and grapheme functions.
Encoding conversion and quick transliteration: iconv(), as long as you pay attention to which libc you’re running on. For the iconv_str* functions, there’s nothing mbstring doesn’t also do, with fewer notices.
Anything a human will read, count or cut: truncating titles, length limits in forms, cursor positions, reversing: grapheme. It’s slower and returns odd values on bad input, but it’s the only one that knows a family is one thing.

And the golden rule: never mix units. A position from strpos() fed to mb_substr(), or from mb_strpos() fed to grapheme_substr(), will work perfectly until the first customer called Zoë or 李.
Happy coding, and may all your strings be exactly as long as they look! May be I’ll take a second 🥐 today…
The post Four ways to count to four: PHP strings, iconv, mbstring and grapheme appeared first on Exakat.


Recently updated PIE extensions #8 - Exakat
2026-09-24T10:59:13.000Z
Recently updated PIE extensions #8 (since September 17th, 2026)
18 PHP Pie extensions were updated.

carthage-software/ext-typst (0.4.0): PHP extension for the Typst typesetting engine
hmennen90/php-steamworks (v0.16.0): PHP extension providing access to the Valve Steamworks SDK via a flat C API
phpolygon/php-vio (2.27.0): PHP extension for GPU rendering (OpenGL, Vulkan, Metal), audio, video recording, streaming, and input
symfony/deepclone (v0.8.5): Export any serializable PHP values as pure arrays – accelerator for Symfony’s DeepCloner
kreuzberg/kreuzberg (4.10.4): High-performance document intelligence for PHP. Extract text, metadata, and structured information from PDFs, Office documents, images, and 75 formats. Powered by Rust core for 10-50x speed improvements.
mailmug/php_dlib (v2.0.1): PHP extension for the Dlib C++ library (face detection, landmarks, recognition, and clustering).
phalcon/cphalcon (v5.22.0): Phalcon is an open source web framework delivered as a C extension for the PHP language providing high performance and lower resource consumption.
xberg-io/liter-llm (v2.0.3): Universal LLM API client with Rust-powered polyglot bindings.
xberg-io/xberg (v1.2.8): High-performance document intelligence library
xberg-io/html-to-markdown (v3.14.3): High-performance HTML to Markdown converter
extport/protobuf (36.2): Unofficial PIE-compatible mirror of protocolbuffers/protobuf
phpstan/turbo (2.2.15): Native acceleration extension for PHPStan
prateekbhujel/php-terminal (v1.0.1): Native terminal primitives for PHP CLI on Unix and Windows
open-telemetry/ext-opentelemetry (1.4.2): Auto-instrumentation extension for OpenTelemetry
orieg/expanse-extension (v0.8.1): Native PHP Zend Engine extension for Expanse: modern Judy arrays in pure Rust (ext-php-rs). Userland API: orieg/expanse.
osmanov/pecl-ev (1.2.4): PECL extension providing interface to libev library
swoole/swoole (v6.2.3): Swoole is an event-driven, asynchronous, coroutine-based concurrency library with high performance for PHP.
win32service/win32service (1.1.1beta20): The win32service extension is a Windows-specific extension that allows PHP to communicate with the Service Control Manager to start, stop, register and unregister the services, and even allows your PHP scripts to run as a service.

The post Recently updated PIE extensions #8 appeared first on Exakat.


Continuing to Move PHP Open Source Forward - PhpStorm : The IDE that empowers PHP developers | The JetBrains Blog
2026-09-24T09:46:38.000Z
A year ago, we introduced the first wave of PhpStorm’s open-source sponsorships. We truly believe in the power of open source and the importance of it to the PHP community, and so we want to do our bit, too. 



Each year, we pick five open-source projects to sponsor for a whole year. Our goal is not only to financially support these projects but also to raise awareness of the crucial role open source plays in PHP development and to encourage others to pitch in as well.



Before announcing the new projects, I want to thank everyone for sending in their suggestions. We know there are many more projects to sponsor, and we had to make some tough decisions. Eventually, we decided on projects we thought would have the biggest impact and the greatest need for financing.



So here goes, the new projects on our sponsor list:




Sebastian Bergmann, the creator and maintainer of PHPUnit, the most impactful test suite for PHP. 



George Dumitrescu, who’s creating Lerd, an open source tool for managing local PHP installations and servers.



Jerry Ma, who’s creating static-php-cli; a tool used for example by FrankenPHP and Native PHP.



Composer, which is basically the backbone of modern PHP.



Larabelles, because open source is about more than code; inclusivity is crucial.








If you or your company are in a position to pitch in as well, we would highly recommend doing so. Every bit and piece becomes a substantial difference when added together. Apart from sponsoring individual projects, we also stay committed to sponsoring the PHP Foundation, and encourage as many organizations to do so as well.


    
        
                                                Sponsor the PHP Foundation
                                    
    







Let’s work together to continue to make PHP the best it can be!






PHPenomenal 8.6: A Challenge to For PHP’s Next Release - Exakat
2026-09-24T07:33:04.000Z
PHPenomenal 8.6: A Challenge to For PHP’s Next Release
PHPenomenal 8.6: A Challenge to For PHP’s Next Release
PHP 8.6 lands on November 19th, 2026, and with it comes a handful of features that have been simmering in RFCs for a while: partial function application, clamp(), a new Time\Durationclass, #[\Override] on constants, writes on const-held objects, readonly properties with defaults, and a SortDirection enum. Reading a changelog is one thing. Actually reaching for these features in real code is another — and that gap is exactly what PHPenomenal 8.6 is built to close.
What It Is
PHPenomenal is a community challenge, open until PHP 8.6’s release, with a deceptively simple brief: write a useful PHP application that actually uses the new PHP 8.6 features. Not a toy snippet demonstrating syntax — a real program that takes input, runs, and produces output within a reasonable time, on a single machine.
“Useful” is left deliberately loose. Fizz-buzz with algebraic numbers counts. So does a calculator that echoes its arguments. The point isn’t to build the next killer app — it’s to get hands-on with language features before they ship, and to see how other developers are interpreting them.
The Feature List
There’s a core list every submission is expected to touch:

Partial Function Application
Time\Duration
clamp()
#[\Override] on a constant
Writes on const-held objects
Readonly property defaults
SortDirection enum

And a secondary, optional list for extra credit — things like the polling API, trim()‘s new Form-Feed handling, the reworked stream error management, the array_map() optimization, doc comments in function parameters, and __debugInfo() on enums. This secondary list is explicitly open to growing as more PHP 8.6 quirks get discovered and written up.
The Rules (There’s Basically One)
Share at least one application, with its source, by the end of the event. It has to compile under PHP 8.6 — compiling under 8.5 isn’t required and, for some features, won’t even be possible. Beyond that: architect it however you like, add assets, pull in Composer, write tests, run static analysis. Nobody’s stopping you from going overboard.
The one hard constraint is scope: keep the application self-contained on one machine. No downloading a remote dataset just to demonstrate clamp() on an integer.
How to Join
Participation happens through the repo’s issue tracker — open an issue to declare your intent, and update it as you go. A README explaining what you’re building is encouraged, and so are dev diaries and sample output along the way. Feeling ambitious? Open a second issue for a second idea. And browsing other participants’ issues to comment and compare notes is very much part of the fun.
Checking Your Work
The repo ships a small tool for this exact purpose: scripts/check-php86-features.php. It’s not a naive string search — it tokenizes your source with PhpToken::tokenize() and checks the actual token stream, so a feature name sitting in a comment or a string literal won’t falsely count as “used.” Point it at your file:

php scripts/check-php86-features.php path/to/your-file.php

and it reports, feature by feature, what it found and where — plus what’s still missing.
You’ll also want PHP 8.6 itself on hand to lint against (php8.6 -l yourfile.php). The README lists several ways to get there: pre-release builds from php.net, Docker images, Homebrew on macOS, or compiling from source.
Why Bother
New language features only prove their worth once people try to break them, combine them in unexpected ways, and hit the edges the RFC didn’t anticipate. PHPenomenal turns that process into something social and a little competitive — and yes, there’s a prize: the best (especially the funniest) submissions earn an elePHPant.
The event is run by Damien Seguy (@dseguy) and Jon Purvis (https://x.com/JonPurvis), reachable on the repo or the PHP community Discord.
Deadline: November 19th, 2026, 00:00 UTC, aka the moment PHP 8.6 officially exists.
If you’ve been meaning to actually understand what Time\Duration or partial function application look like in practice, rather than just reading about them, this is a good excuse.
The post PHPenomenal 8.6: A Challenge to For PHP’s Next Release appeared first on Exakat.


Lazy class constants in PHP - Exakat
2026-09-22T07:19:50.000Z
Lazy class constants in PHP: fast by design, sometimes surprising
PHP has class constant, which are named literals. It also supports static constant expressions, where the value is not always a literal. Rather, it’s an expression that PHP doesn’t evaluate immediately. PHP evaluates it the first time the code needs it. This is the concept of lazy execution. It is good for performance, and it also means some bugs only show up at runtime, in the one request that touches the broken constant.
So, power and macros come at a risk of eventual error. Let’s see how this works.
How it works
When PHP compiles a class, it tries to fold each constant expression into a plain value. const A = 2; is an obvious case. const A = 2 * 21; becomes 42 at compile time. And then, some expressions can’t be folded, because they depend on something that doesn’t exist yet, now or ever:

global constants: const PATH = APP_ROOT . '/var';
constants from other classes: const B = Dep::VALUE; They must be loaded first.
enum cases: const DEFAULT = Status::On;. They must be accessed first.
expressions that would throw: const X = 1 % 0;. This fails, but it the exception is defered to execution phase.

For these, PHP stores the expression as an AST, the famous syntax tree, and marks the constant as “not updated yet”. The first time the constant is read, PHP evaluates the tree, replaces it with the result and uses the stored value after that.

&amp;amp;lt;?php
class Config {
    const OK     = 'fine';
    const BROKEN = UNDEFINED_THING . '/cache';
}

echo "compiled and running\n";
echo Config::OK, "\n";
echo Config::BROKEN, "\n";
?&amp;amp;gt;



compiled and running
fine
Error: Undefined constant "UNDEFINED_THING"
?>
[/php]


The class compiles, php -l reports no syntax errors, and Config::OK works. The error only appears when something reads Config::BROKEN.
Why it helps performance
Evaluating constants lazily saves work in three ways.
1. You don’t pay for constants you never read. A class may define dozens of constants while a given request uses two of them. PHP doesn’t resolve the rest. It does some compilation work and allocate memory for the constant, its value and the AST. But these are usually cheap, in terms of memory and execution time.
2. Dependencies aren’t autoloaded early. A constant that points to another class only triggers that class’s autoloader when it’s read. This is the same problem with entity hydration or deep cloning, where one element depends on n elements, which dependes on even more elements and dependencies…

&amp;amp;lt;?php
spl_autoload_register(function ($c) {
    echo "[autoload($c)] ";
    // eval() usage is tolerated to keep the illustration simple. 
    // imagine this is a file inclusion, not a dynamic piece of code
    if ($c === 'Dep') { eval('class Dep { const V = 42; }'); }
});

class Svc { 
    const A = 1; 
    const B = Dep::V; 
}

echo "Svc::A = ", Svc::A, "\n";
echo "Svc::B = ", Svc::B, "\n";
echo "Svc::B again = ", Svc::B, "\n";
?&amp;amp;gt;



Svc::A = 1
Svc::B = [autoload(Dep)] 42
Svc::B again = 42
?>
[/php]


Reading Svc::A doesn’t load Dep. Only Svc::B does, and only once. In a large codebase, constants refer to other classes all the time. Resolving them eagerly would pull in large parts of the class graph on every request.
3. Declaration order doesn’t matter. A constant can refer to a global constant defined later during bootstrap. It works as long as the value exists when the constant is first read.
With OPcache, classes are cached in shared memory with their unresolved expressions. Each request resolves only the constants it uses.
Bugs waiting for the right request
Lazy evaluation delays value building, so it also delays errors. A mistake in a constant expression doesn’t fail when the file is loaded. It fails when some code first reads that constant, which may be rare or only happen in production.
Typos and missing dependencies

&amp;amp;lt;?php
enum Status: string {
    case On  = 'on';
    case Off = 'off';
    const DEFAULT = self::Of;   // typo
}
?&amp;amp;gt;


This file loads without complaint. Reading Status::On works. Reading Status::Off works. Reading Status::DEFAULT fails with:

Undefined constant self::Of
?>
[/php]


A missing class behaves the same way: const B = Missing::VALUE; raises Class "Missing" not found, but only when it’s evaluated.
Math that fails at runtime
PHP doesn’t detect it at compile time when an expression would throw an exception. It saves it for later:

&amp;amp;lt;?php
class Math { 
    const X = 1 % 0; 
    const Y = 10 / 0; 
}
echo "loaded\n";   // prints fine
echo Math::X;      // DivisionByZeroError: Modulo by zero
?&amp;amp;gt;


Now, real code rarely divides by a literal zero. It does divide by other constants, which can be zero in some configuration or an empty string. Dependencies may hide some errors under several layers of camouflage.
Typed constants checked late
PHP 8.3 added typed class constants. When the value comes from an expression, PHP can only check the type once it computes the value:

&amp;amp;lt;?php
class T { 
    const int LIMIT = SOME_ENV_VALUE; 
}
define('SOME_ENV_VALUE', '100 items');
echo "loaded\n";
var_dump(T::LIMIT);
// TypeError: Cannot assign string to class constant T::LIMIT of type int
?&amp;amp;gt;


Note the stange situation where PHP report the assignation of a value to a constant.
new evaluates every constant
Reading one constant evaluates only that one. Calling a static method also works. And then, instantiating the class, or reading a static property, evaluates all of the class’s constants:

&amp;amp;lt;?php
class Foo {
    const A = 'a';
    const B = Missing::VALUE;
    public static $s = 1;
    public static function m() { return 'm'; }
}

Foo::m();        // works
Foo::A;          // works
Foo::$s;         // Error: Class "Missing" not found
new Foo;         // Error: Class "Missing" not found
?&amp;amp;gt;


A broken constant that nobody reads can still break new Foo in code that has nothing to do with that constant. Calling a static method works, then reading a static property on the same class fails. And the stack trace points to where the class was used, not where the mistake is.
Results that depend on execution order
A failed evaluation isn’t cached as a failure. If the global constant gets defined later, the next read succeeds:

&amp;amp;lt;?php
class Late { 
    const PATH = APP_ROOT . '/var'; 
}

try {
    echo Late::PATH;               // Error: Undefined constant "APP_ROOT"
} catch (Error $e) {
    // Catch constant errors with this clause
    print $e-&amp;amp;gt;getMessage();
}
define('APP_ROOT', '/srv/app');
echo Late::PATH;               // /srv/app/var
?&amp;amp;gt;


So the outcome depends on execution order. The code works through the web front controller, where bootstrap has run, and fails in a CLI command, a queue worker or a unit test that skips bootstrap. It’s the kind of bug that gets reported as “only happens sometimes”.
Recommendations
1. Keep constant expressions self-contained. Prefer literals and constants within the same class, or to classes that are always available. Every reference to a global constant or another class is a dependency that is only checked at runtime.
2. Don’t use constants for environment values. Constants built from APP_ROOT, define()d settings or config values create the timing problem above. Put that data in a config object, or in a static method that reads configuration explicitly and fails with a clear message.
3. Evaluate every constant in your test suite. ReflectionClass::getConstants() forces all of a class’s constants to be evaluated, so one test can check the whole codebase:

&amp;amp;lt;?php
public function testAllClassConstantsResolve(): void
{
    foreach ($this-&amp;amp;gt;allProjectClasses() as $class) {   // e.g. from Composer's classmap
        (new ReflectionClass($class))-&amp;amp;gt;getConstants(); // throws if anything is broken
    }
    $this-&amp;amp;gt;addToAssertionCount(1);
}
?&amp;amp;gt;


This moves errors from “the first request that happens to read the constant” to CI. Run it after your bootstrap, and a second time without it, to catch constants that depend on bootstrap.
4. Use static analysis. PHPStan, Psalm and Exakat resolve constant expressions without running the code. They report undefined constants and classes, missing enum cases and type mismatches that php -l doesn’t catch. At high enough strictness levels, most of the problems above get flagged before anything runs.
5. Use typed constants. A typed constant can’t silently turn into the wrong type. Static analyzers can check the type ahead of time, and at runtime a mismatch throws a TypeError where the constant is declared, not further down the line.
6. Remember that new checks every constant. When new SomeClass throws an error that mentions a class or constant you’ve never heard of, look at that class’s constants first. Many “impossible” instantiation errors come from there.
7. Preload in production for an early warning. With opcache.preload, classes are compiled when the server starts, and constants that can be resolved at that point are resolved then. It isn’t a complete check, because anything that depends on runtime state stays unresolved. It does move some failures from the first unlucky request to startup.
Summary
Lazy class constants are offer the same advantages and drawbacks than lazy objects. They are a good trade-off: requests don’t pay for constants they don’t use or for class graphs they don’t need. The cost is that constants are no longer validated when the file compiles. An error in a constant expression shows up only when the right code path reads it, or when new runs on its class. Check your constants in CI with reflection and static analysis so those errors don’t reach production.
The post Lazy class constants in PHP appeared first on Exakat.

	catches a class/trait/interface collision	catches a function collision
`token_get_all()`
`token_get_all(TOKEN_PARSE)`
`include` / `eval`	only if that line executes	always, whole file, before anything runs

	native	iconv	mbstring	grapheme
Unit	byte	code point	code point	grapheme cluster
Functions	~100	10	65	10
Always available	✅	usually	usually	needs intl
Case conversion	ASCII only	❌	✅ full Unicode	❌
Case-insensitive search	ASCII only	❌	✅	✅
Split / pad / trim	✅ (bytes)	❌	✅ (8.3/8.4)	split only (8.4)
Invalid UTF-8	ignores	`false` + notice	counts bytes	`null`
Empty needle	0	`false`	0	0
Encoding conversion	❌	✅ (libc dependent)	✅	❌
Speed	🚀	🚗	🚗	🚲

PHP - BlogFlock

Find the slowest PHPUnit tests - Rob Allen

Every Road Around the Zend Engine - Exakat

Every Road Around the Zend Engine

The panorama

The canonical path, briefly

Replace the compiler and its target

Straight to native code

Straight to someone else’s VM

The ancestor of this whole family is Facebook’s HipHop

Keep the real Zend engine, change its house

Leave the engine alone, change what’s around it

The diagram

What the panorama shows

The bigger picture

PHP has a Spoofchecker: A 14-Year-Old Tool You’re Probably Not Using - Exakat

PHP has a Spoofchecker: A 14-Year-Old Tool You’re Probably Not Using

Start here: when visual traps aren’t a runtime problem

Three configurations worth knowing in detail

1. Mixed-script confusables: the brand-impersonation check

2. Invisible characters: the password and ID hygiene check

3. Restriction level: the policy-grade check

The rest of the checks

New in PHP 8.6: skeletons and bidi comparison

Various usages of Spoofchecker

Domain names and URLs

Username and handle registration

Email addresses and display names

Password policy: the lesser taken road

Content moderation and banned-word filters

Other situations worth a pass

Limitations and gotchas

Unicode tricks in your tests too

Conclusion: you may already be running Spoofchecker

Check your Unicode strings a bit more

The 2,000th word: a personal notebook became a map of PHP - Exakat

The 2,000th word: a personal notebook became a map of PHP

It started as a notebook

It grew by listening to the community

It connected the words together

It untangled words with several meanings

Where does the PHP dictionary stands

Beyond the book

Help build the next 2,000

Recently updated PIE extensions #11 (since October 8th, 2026) - Exakat

Recently updated PIE extensions #11 (since October 8th, 2026)

PHP ❤️ Rust: Every Bridge Between Two Worlds - Exakat

PHP Rust: Every Bridge Between Two Worlds

An Elephant and a Crab Walk Into a Bar

From PHP, Toward Rust

1. Zend Extensions: The Classic Highway

2. FFI: The Drawbridge

3. WebAssembly: The Neutral Embassy

4. PHP to Rust Transpilation: A Moving Walkway

Rust powered PHP engine: The Holy Bridge

The Rumored Bridges: more to come!

7. The Mirror: A Rust Compiler Written in PHP

From Rust, Toward PHP

php_codegen: Rust Writes the PHP

Rust as Plugin Host, Process Front, or Async Engine

The Type Checker Will See You Now

foreach Already Knows: PHP and the Zero-One-Infinity Rule - Exakat

foreach Already Knows: PHP and the Zero-One-Infinity Rule

Naming the rule

Zero: be lazy

One: same old, same old

Arrays, and the container that stopped caring

Two in a box: it is still fine to write by hand

Three: where duplication starts to hurt

N, the infinite and beyond: where centralization becomes mandatory

PHP’s built-in answers to “more”

The 8.x-era features, seen through this lens

The idea PHP could finish: applying object syntax onto arrays

Upgrading some more syntax could be quite fun

A look at the bigger picture

A Hard Memory Ceiling for PHP Scripts That Run for Hours - Exakat

A Hard Memory Ceiling for PHP Scripts That Run for Hours

Why WeakMap doesn’t apply here

Hot data in RAM, everything else on disk

The checkpoint you already own

PHP has a `Spoofchecker`: A 14-Year-Old Tool You’re Probably Not Using