PHP - BlogFlock

Vale Reviews Your Comments In The Code - Exakat

2026-09-20T08:38:14.000Z

Vale Reviews Your Comments In The Code

Static analysis will tell you a function’s return type is wrong down to the last nullable. It doesn’t tell you that the docblock two lines above it opens with “This class is responsible for,” restates the method signature it’s sitting on, or, this happened, in a project with genuinely careful code review, is written half in French. Vale will. It pulls the prose out of source code and runs style rules over it, the same way a linter runs rules over syntax. Nobody pay designs a codebase’s comments the way they design its types, which is exactly why nobody’s checking them.

I pointed it at Cecil, a mature, well-documented static site generator, 126 PHP files. Its docblocks are better than most projects’. They are full sentences, bullet lists, fenced code samples. Vale ran on it, and found the following, in src/Asset.php, src/Converter/Parsedown.php, src/Generator/VirtualPages.php and src/Step/Menus/Create.php:

Location	Finding
`src/Asset.php:790`	Returns image size `informations`.	“information” has no plural in English
`src/Asset.php:853`	Remove `redondant` ‘/thumbnails/…/’ in the path.	French spelling of “redundant”
`src/Converter/Parsedown.php:439`	`abord` if InlineImage is an animated GIF	“abort”
`src/Generator/VirtualPages.php:66`	`abord` if the page id already exists
`src/Step/Menus/Create.php:129`	`abord` if entry is not enabled

Same French leak, three separate files: I recognize the consistency as, in French, information may be plural: there is no such thing as a pièce d'information. I’m not going to pretend I’m neutral about a project’s comments quietly code-switching into French, I do that too. The leak isn’t the point. The point is that it survived a genuinely good review process for as long as the project has existed, because nothing in that process was built to catch it. Static analysis checks types. Code prettifier checks formatting. None of them opens a comment and reads it. Comments are for human consumption.

Vale finding range from simple case typo to actual intent. For example, it found ten places where the project’s own docs write Twig and the docblocks write twig. And alter, forty class docblocks that open with “This class is responsible for…” instead of saying what the class does. This is the docblock equivalent of a job interview answer that restates the question before answering it. Let’s see how it can be applied to a code base.

Getting Vale ready

Vale is a single Go binary, which means installing it has nothing to do with Composer:

# macOS
brew install vale

# Debian / Ubuntu — see pkg.haus for the archive setup
sudo apt install vale

# Arch
sudo pacman -S vale

# Windows
winget install -e --id errata-ai.Vale

For a PHP project you’ll want the version pinned alongside everything else, so your laptop and CI agree on which rules exist: Vale has versions every week, so there might be evolution within a short time range. Vale ships through the usual registries too. Each one just downloads the same release binary and puts vale on your path:

# any project, any language
mise use vale@3.22.0

# or via npm / PyPI, if you already have one of them
npm install --save-dev @vvago/vale
pip install vale

$ vale --version
vale version 3.22.0

The one place Vale genuinely isn’t packaged is Composer, and it isn’t an oversight: it’s a Go binary, not a PHP library, and PHP’s package manager has no business fetching it. Install it beside Composer, not through it.

Pointing it at real code

For a life size test, we’re going to use Cecil.app, the famous PHP static website generator. For a full disclosure, it is authored by Arnaud Ligny, and available in open source.

There are 126 PHP files under src/, with docblocks rich enough to make this worth doing: they have full sentences, bullet lists, fenced code samples, in English. For example:

/**
 * The main Cecil builder class.
 *
 * This class is responsible for building the website by processing various steps,
 * managing configuration, and handling content, data, static files, pages, assets,
 * menus, taxonomies, and rendering.
 * It also provides methods for logging, debugging, and managing build metrics.
 *
 * ```php
 * $config = [
 *   'title'   => "My website",
 *   'baseurl' => 'https://domain.tld/',
 * ];
 * Builder::create($config)->build();
 * ```
 */
class Builder implements BuildContextInterface, LoggerAwareInterface

That docblock is already a small preview of everything below: a summary that restates its own class name, a weasel word various, and a fenced code sample that had better not get treated as prose.

Teaching Vale that this is Markdown wearing a PHP hat

Vale reads PHP natively: //, # and /* … */ comments come back as scoped blocks, and everything that isn’t a comment is discarded before any rule runs. That part needs no configuration. The two lines that do all the real work are the format association and the file glob:

StylesPath = .vale
MinAlertLevel = suggestion
Packages = write-good, proselint, Microsoft

[formats]
php = md

[*.php]
BasedOnStyles = Vale, write-good, proselint, Microsoft

php = md is the line that makes docblocks legible, and for PHP specifically it isn’t a nicety. It’s the difference between a usable run and a useless one. With the association in place, Vale strips the leading * from every line of a block comment, so a docblock reads as paragraphs and lists instead of one giant bullet point; treats fenced phpsamples inside docblocks as code and skips them, soBuilder::create($config)->build();doesn't get flagged for "using 'is'"; and unlocksTokenIgnoresandBlockIgnores`, which are otherwise unavailable on source files at all — both of them earn their keep two sections from now.

$ mkdir -p .vale
$ vale sync
 SUCCESS  Synced 3 package(s) to '/home/you/cecil/.vale'.

StylesPath has to exist before Vale will run at all. It will not create the directory on your behalf, and a missing one fails with E201 Invalid value pointing at .vale.ini, which reads exactly like a syntax error in your config and is, in fact, a missing folder.

The first vale run is a firehose, and that’s normal

$ vale src/
…
✖ 765 errors, 431 warnings and 1036 suggestions in 126 files.

real    0m1.517s

2,232 alerts, almost all of them noise, produced in a second and a half. At least, it tells you Vale’s speed was never the problem. A single file shows why:

$ vale src/Builder.php

 src/Builder.php
   4:14   suggestion  Try to avoid using 'is'.                     write-good.E-Prime
   6:4    error       Consider using the '©' symbol instead of…    proselint.Typography
   6:8    error       Did you really mean 'Arnaud'?                Vale.Spelling
   9:14   warning     'was distributed' may be passive voice.      write-good.Passive
  27:15   warning     'is responsible for' is too wordy.           write-good.TooWordy
  27:69   warning     'various' is a weasel word!                  write-good.Weasel
  51:46   error       Use 'aren't' instead of 'are not'.           Microsoft.Contractions
 112:13   error       Did you really mean 'bool'?                  Vale.Spelling

There are three genuinely different problems, sitting in that list, and each needs a different fix:

Rule	Hits	Why it fires
`write-good.E-Prime`	588	Bans the verb “to be,” full stop. It is a stylistic experiment some writer once picked a fight with, not a standard. It is useless for API docs, which exist to state facts, several of which are facts about what things are.
`Vale.Spelling`	525	This error reports mostly identifiers, such as `$baseurl`, `getFile()`, `min_word_count`, and not prose. Vale doesn’t yet know the difference between a sentence and a variable name. May be the `$` sign is not obvious enough?
`Microsoft.Passive` + `write-good.Passive`	271 + more	Two packages independently policing the passive voice, so every real hit gets counted, and complained about, twice.
`proselint.Typography`	139	The `(c)` in the license header, once per file, 126 times over.
`Microsoft.Contractions`	49	Demands “aren’t” over “are not.” That’s Microsoft’s house style leaking into your codebase’s opinions, not yours.

Vale is not telling you the comments are bad. Vale is telling you it hasn’t been told what this project is yet. It is the same conversation every static analyzer has with a codebase on day one, just conducted in English instead of PHPDoc types.

Four moves, in the order that pays off fastest

Turn off the rules that were never arguing with you

E-Prime alone is a quarter of the noise; contractions and the spell-out-your-acronyms rules are house-style opinions a docblock has no obligation to hold.

[*.php]
BasedOnStyles = Vale, write-good, Microsoft

write-good.E-Prime = NO
Microsoft.Contractions = NO
Microsoft.GeneralURL = NO
Microsoft.Acronyms = NO
Microsoft.QuestionMarks = NO

This new configuration drops proselint from BasedOnStyles and Packages entirely. These are typography rules, aimed at published essays, and once the license header is excluded, it has nothing left worth saying about a codebase.

Give the project a vocabulary

Vocab names a folder under StylesPath/config/vocabularies/. accept.txt lists terms the spellchecker should already know; reject.txt lists terms that should be flagged wherever they appear. Both take one case-sensitive regex per line.

.vale/config/vocabularies/Cecil/accept.txt

Cecil
Symfony
Twig
Parsedown
Imagick
libvips
Phar
Composer
frontmatter
baseurl
slugify
[Pp]aginator
[Cc]onfig
[Bb]ool(ean)?
[Hh][Tt][Mm][Ll]
[Uu][Rr][Ll]
deduplicat(e|ion)

And the inverse list, where, satisfyingly, the French spelling leak gets caught for good:

.vale/config/vocabularies/Cecil/reject.txt

abord
informations
redondant

One gotcha worth knowing before you write this list yourself: every entry in accept.txt doubles as a canonical-spelling rule via Vale.Terms. Write html in the list, lowercase, and Vale will start insisting you write HTML as html everywhere else. 386 new alerts appeared the first time I tried it, including Use 'url' instead of 'URL', forty-six separate times, from a spellchecker that had until that point been perfectly reasonable. Either write the entry in the casing you actually want, or spell it case-insensitively as [Hh][Tt][Mm][Ll]. Used on purpose, this is the exact feature that produced the ten Use 'Twig' instead of 'twig'findings above.

Tell it that code sitting inside a sentence is still code

Most of the remaining spelling alerts are identifiers written bare in prose. TokenIgnores takes a comma-separated list of regexes and strips each match before any rule sees the line:

TokenIgnores = (\$[A-Za-z_]\w*), (`[^`]+`), (@\w+[^\n]*), \
               ([A-Za-z]+\\[\w\\]+), (\w+\(\)), \
               ([a-z]+_[a-z_]+), ([a-z]+[A-Z]\w*)

This is where we make the PHP variable syntax, with its leading $ sign active. And, of course, this is not the only syntax we want to apply. So, left to right: variables, backticked spans, annotation lines (@param, @return, @see and the rest), namespaced class names, function calls, snake_case, camelCase. Spelling alerts drop from 525 to 70, and what’s left is almost entirely real. The trailing \ line continuations are valid .vale.ini syntax; the value parses identically to writing the same regexes on one very long line.

Exempt the paragraph nobody’s ever going to rewrite

Cecil carries the same eight-line license header in all 126 files. Every Open Source project stats its code file with a licence reminder. Left in, they contribute a passive-voice warning, a typography error and two spelling errors per file. It counts 500 alerts spent reviewing a block of legal boilerplate nobody involved has the authority to change.

BlockIgnores = (?s)This file is part of Cecil\..*?source code\.

The gotcha here is subtler than it looks: the obvious regex starts /\*\* or \* This file…, and matches nothing, because step three already happened by the time BlockIgnores runs. The php = md association strips the leading asterisks before the ignore patterns are evaluated, so BlockIgnores is looking at the comment body as plain paragraphs, not as a raw block comment. Write the pattern against that, and add (?s) so . crosses the blank lines in between.

before tuning  ████████████████████████████████████████  2,232
after tuning   ████████                                    432

What a clean we just did. Along the way, we have learnt about the code base, and the Vale configuration. Now, what’s left is 144 passive-voice warnings, 70 spelling alerts, 69 wordiness warnings, 13 casing findings and 5 rejected terms: oof. Yet, that is a list a human being could actually sit down and work through in an afternoon, which was never true of the first number.

Writing rules for docblocks specifically

Every comment Vale extracts carries a scope. It is a one-line comment is text.comment.line.php, a block comment text.comment.block.php. A rule that declares one of those runs only there, which is what makes it possible to hold a published API docblock to a stricter standard than a throwaway // note two lines below it.

A style is just a folder of YAML under StylesPath. The first rule targets block comments only:

.vale/Docblock/Summary.yml

extends: existence
message: "Start the summary with a verb: '%s' repeats what the signature already says."
link: https://www.php-fig.org/psr/psr-5/
level: warning
scope: text.comment.block.php
nonword: true
tokens:
  - '(?i)^\s*This (?:class|function|method|file|property|constant)\b'

.vale/Docblock/Marker.yml

extends: existence
message: "Leftover '%s' marker: link an issue or remove it."
level: error
scope: text.comment
tokens:
  - TODO
  - FIXME
  - XXX
  - HACK

Add Docblock to BasedOnStyles and it runs alongside the packages. Applied to Cecil, the summary rule fires 40 times, every single one on a class or method docblock that opens by re-announcing the thing it’s already attached to:

$ vale --filter='.Name matches "Docblock.*"' src/

 src/Builder.php
  27:4   warning  Start the summary with a verb: 'This class' repeats…   Docblock.Summary
 271:8   warning  Start the summary with a verb: 'This method' repeats…  Docblock.Summary

 src/Command/AbstractCommand.php
  36:4   warning  Start the summary with a verb: 'This class' repeats…   Docblock.Summary

--filter is worth remembering for itself: it takes an expression over the alert’s fields, so --filter='.Level == "error"' or --filter='.Name in ["Vale.Avoid", "Vale.Terms"]' lets you work through one category at a time without touching the config file at all.

Drop this fourteen-line file somewhere and every rule type fires on it at once, in miniature:

$ vale demo.php

 demo.php
  4:4    warning  Start the summary with a verb: 'This class' repeats…  Docblock.Summary
  4:15   warning  'is responsible for' is too wordy.                    write-good.TooWordy
  4:47   warning  'various' is a weasel word!                           write-good.Weasel
  4:60   error    Avoid using 'informations'.                           Vale.Avoid
  6:4    warning  'It is' is too wordy.                                 write-good.TooWordy
  6:10   warning  Remove 'very' if it's not important to the meaning.   Microsoft.Adverbs
  6:40   warning  'is invalidated' may be passive voice.                write-good.Passive
 10:8    error    Leftover 'TODO' marker: link an issue or remove it.   Docblock.Marker
 10:14   error    Avoid using 'abord'.                                  Vale.Avoid

✖ 5 errors, 7 warnings and 0 suggestions in 1 file.

Now, that demo file is trying too hard, deliberately, but every fault it’s committing showed up for real, somewhere in Cecil’s 126 files, once each.

Putting it in CI without picking a fight with day one

Vale exits with a non-zero value when any alert at or above MinAlertLevel is found, so --minAlertLevel is the severity dial. The arrangement that actually survives contact with an existing codebase is to fail the build only on what’s been explicitly declared unacceptable. This is the case with rejected terms, leftover markers, wrong casing. On the other hand, it should still be printing the advisory warnings for anyone who wants to read them.

.github/workflows/vale.yml

name: Prose

on: [push, pull_request]

jobs:
  vale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: vale-cli/vale-action@v2
        with:
          version: 3.22.0
          files: src
          fail_on_error: true

Or, without the action, two lines suffice in any runner:

vale sync
vale --minAlertLevel=error src/   # exit 1 on errors, warnings still printed

One flag worth knowing on a first adoption: --output=JSON. Aggregating that by rule name is exactly how the table earlier in this piece got built, and it’s the fastest way to decide what to switch off next, rather than guessing.

vale --output=JSON src/ | jq -r '.[][] | .Check' | sort | uniq -c | sort -rn

   144 write-good.Passive
     70 Vale.Spelling
     69 write-good.TooWordy
     40 Docblock.Summary
     24 Microsoft.Quotes

On a large, unreviewed codebase, start with MinAlertLevel = error and an empty reject.txt, so the build is green from the first commit. Every time the team actually agrees on a rule, like a banned term, a house spelling, a docblock convention, promote it to an error. The advisory warnings sit in the log the whole time, visible, opinionated, and blocking absolutely nothing.

The finished config

Here is the configuration file that brought down 2,232 alerts down to 432.

.vale.ini

StylesPath = .vale
MinAlertLevel = warning
Packages = write-good, Microsoft
Vocab = Cecil

[formats]
php = md

[*.php]
BasedOnStyles = Vale, write-good, Microsoft, Docblock

# The licence header, repeated in all 126 files. Matched against the
# comment body after the leading asterisks have been stripped.
BlockIgnores = (?s)This file is part of Cecil\..*?source code\.

# Identifiers, annotations and code spans are not prose.
TokenIgnores = (\$[A-Za-z_]\w*), (`[^`]+`), (@\w+[^\n]*), \
               ([A-Za-z]+\\[\w\\]+), (\w+\(\)), \
               ([a-z]+_[a-z_]+), ([a-z]+[A-Z]\w*)

# House-style rules a docblock has no reason to follow.
write-good.E-Prime = NO
Microsoft.Contractions = NO
Microsoft.GeneralURL = NO
Microsoft.Acronyms = NO
Microsoft.QuestionMarks = NO

cecil/
├── .vale.ini
├── .vale/
│   ├── config/vocabularies/Cecil/
│   │   ├── accept.txt
│   │   └── reject.txt
│   ├── Docblock/
│   │   ├── Summary.yml
│   │   └── Marker.yml
│   ├── Microsoft/        # vale sync
│   └── write-good/       # vale sync
└── src/

Commit .vale.ini, the vocabularies and your own Docblock/ rules to the repository. Then, gitignore the synced package folders and let vale sync refill them on every machine and every CI run.

For reference, the four PHP comment forms and where they land:

Syntax	Scope
`// line comment`	`text.comment.line.php`
`# line comment`	`text.comment.line.php`
`/* inline */`	`text.comment.line.php`
`/** docblock */`	`text.comment.block.php`

Note that scopes match by containment, not by prefix: a rule scoped comment catches all four forms, comment.block catches docblocks in any language Vale understands, and text.comment.block.php narrows all the way down to PHP docblocks alone.

Who read the comments anyway?

PHP has spent the last decade getting steadily better at making the compiler check things a human used to have to remember. Types, nullability, exhaustiveness, the whole run of the type-system work that keeps closing gaps the language left open a version or two earlier. The same engine has always striped the source code of comments and whitespaces, as they are useless to code execution, event the PHPdoc with extra types. A function can be fully typed, covered, statically verified down to the last edge case, and still be documented by a comment that lies about what it does, restates its own signature, or, as it turns out, even in a codebase good enough to be worth cloning as an example, applies grammar from a different language.

Nobody has time to audit comments, because nothing forces the question the way a red squiggly line under a type mismatch does. Vale doesn’t fix that asymmetry so much as it makes the asymmetry visible for the first time: 2,232 things a well-reviewed project’s comments were quietly getting away with, tunable down to 432 worth a person’s actual attention. Whether prose ever gets the same treatment types did, checked by default, invisible when it’s clean, argued about only at the edges, or whether “the comment sounds right” just stays a taste nobody automates, is the same open question this project’s own docblocks have been answering, one informations at a time, since before anyone thought to ask.

The post Vale Reviews Your Comments In The Code appeared first on Exakat.

Webmention support - Blog entries :: mwop.net

2026-09-18T15:12:40.000Z

I've known about webmentions for years, as well as microformats; I've even included microformats in my markup for probably close to a decade at this point. But accepting and sending webmentions, while it seemed like a great idea, just never really made it to my priority list.

Until it did.

Inspired by James Titcumb and Owls, I started investigating how to implement webmentions, and ended up going down the rabbit hole myself.

There has long been a PHP API for Microformats (php-mf2). It's not been updated in 4 years — largely because it's complete — and uses PCRE for finding microformats and validating URIs. Here's the thing: the last two releases of PHP (8.4 and 8.5 at the time I write this) have included some amazing features that make things like this both far simpler and more accurate. These include the new HTML5 parser included in PHP 8.4 — which even provides querySelector() and querySelectorAll() implementations — and the Uri extension included in PHP 8.5, which provides robust, standards-based URL parsing and validation.

Add in things like PSR-18's HTTP Client, and it seemed possible to create a pretty minimal library that gives full-featured support for both microformats and webmentions.

So, I decided to try my hand at it.

I'll likely open source the libraries I created (one for parsing microformats, another for sending and receiving webmentions), but I want to wait until I've ironed out any edge cases. While I've tested against the various resources that webmention.rocks provides, as well as the microformats website, I'm sure that I'll be observing some oddities in the wild. But I have webmention receiving in place, with microformats discovery for identifying the type of webmention sent to my site. I have also setup a post-publication process for parsing my own content for links, and performing webmention discovery and sending. I want these all to run for a while to find what is working and what isn't in the real world.

In the meantime, feel free to send webmentions to my blog posts, art gallery images, or Now pages. Just like my comments, I moderate all webmentions before publishing them (someday I'll blog about how I accomplished that as well).

Webmention support was originally published 18 September 2026 on https://mwop.net by Matthew Weier O'Phinney.

Fatal error: Cannot redeclare non static DOMElement::$id as static ezcDocumentPropertyContainerDomElement::$id

So, a piece of code used to have a property, and now, one of the classes is now trying to redeclare this as a static. Obviously, this is never going to work, in PHP 8.6, but also, in previous versions. The class comes from the eZ Components, now Zeta Components, Document library. This is not new code, and it has not been updated for a long time. Though, it extends DOMElement and keeps a counter used to hand out unique numbers to nodes:

There is nothing exotic here. A static counter, named $id, in a class that had been stable for years. It feels like the error message is a bit misleading, or out of context. So what happened?

First suspect: PHP 8.6

The error showed up while testing the code against PHP 8.6, so the natural first guess was a fresh change in the engine. It did not last long. Running the same code on older versions showed that the error was already there in earlier releases, and bisecting quickly narrowed it down to the 8.2 to 8.3 transition: PHP 8.2 runs the class without complaint, PHP 8.3 refuses to compile it.

Second suspect: a new error message

Maybe PHP 8.3 introduced a new check? Not at all. The message “Cannot redeclare %s%s::$%s as %s%s::$%s” lives in Zend/zend_inheritance.c in PHP 7.0, and before that in Zend/zend_compile.c in PHP 5.6. It is an old, well established rule: a child class cannot turn an instance property of its parent into a static one, or the other way round. Userland code has always been subject to it:

So the rule is not new. Something else changed.

Third suspect: native classes are checked differently

Since the parent is DOMElement, a native class, the next idea was that internal classes might escape the compile time check, and only complain later, or under certain conditions. That theory falls apart with a quick test on PHP 8.2, using a property that DOMElement has always had:

The same happens with DOMNode::$nodeName, DOMDocument::$encoding, XMLReader::$name, ZipArchive::$status, Exception::$message, Error::$code or PDOStatement::$queryString. Native classes get exactly the same treatment as custom ones. There is no special leniency.

The actual culprit: a brand new property

The explanation is much simpler. In PHP 8.2, DOMElement has no $id property at all. Reflection lists $tagName, $schemaTypeInfo, the element traversal properties and everything inherited from DOMNode, but no $id. On an element with an id attribute, property_exists($element, 'id') returns false. PHP 8.3 added two properties to DOMElement, mirroring the DOM standard:

The UPGRADING file lists this under “New Features”, not under “Backward Incompatible Changes”. From the point of view of DOMElement, it is indeed a feature. From the point of view of every class that extends DOMElement and already had its own $id, it is a breaking change. In PHP 8.2, the static $id of the ezc class did not redeclare anything: there was nothing to redeclare. In PHP 8.3, it suddenly collides with a public, non static, typed property of its parent.

Why adding a property is not free

Adding a class, a function or a constant to PHP is usually uneventful. Adding a method to a non final class is already riskier, as child classes may have a method with the same name and an incompatible signature. Properties come with their own set of inheritance rules, and all of them now apply to any child that happens to use the same name. When the parent property is public or protected, the child’s declaration must:

keep the same static or non static nature,
keep the same or a wider visibility,
keep the same type, when the parent property is typed.

So, beyond the static case, PHP 8.3 also rejects these, which were perfectly valid in PHP 8.2:

Each child class that used $id for its own purpose has to match a contract it never signed.

When would it have been safe?

A private property

Private properties do not take part in inheritance checks. Had the new property been private, the child class would simply have its own, unrelated $id:

id; }
}

class C extends P {
    protected static $id = 1;
    static function s() { return static::$id; }
}

var_dump((new C)->get(), C::s());
// string(6) "parent"
// int(1)
?>

Both properties live side by side, and each class sees its own. Of course, a private property is useless for a public API such as $element->id, so this was not an option for the DOM extension. It is, however, a good option for library authors: private properties can be added in a minor version without risking this kind of collision in child classes.

What about `final`?

It is tempting to think that final would help, but it goes the other way. Since PHP 8.4, properties may be marked final, and that forbids any redeclaration, compatible or not:

A final property turns every same-named property in a child class into an error. final cannot be combined with private either (“Property cannot be both final and private”). The only final that removes the problem is a final class: without children, there are no collisions. DOMElement cannot be final, though, since extending it is the whole point of DOMDocument::registerNodeClass(), and that is exactly what the ezc library does.

The popularity factor

The last ingredient is the name itself. $id is probably one of the most common property names in PHP code: entities, models, nodes, counters, registries all have one. $className is not far behind. A new property called $isConnected, added to DOMNode in the same release, is much less likely to hit anyone. The risk of adding a property to a non final, widely extended class is roughly proportional to how common its name is. DOMElement::$id scores high on both counts. For the record, here are the 20 most commonly used property names in PHP projects:

$name
$collection_key
$id
$RequestId
$type
$response
$description
$value
$container
$config
$options
$initialized
$logger
$data
$table
$message
$getters
$setters
$attributeMap
$connection

Fixing and detecting

The fix is a rename. The Zeta Components Document library now uses $_id for its counter, which no longer collides with anything. To find such collisions ahead of time, here is a small script that lists properties declared in your classes that share a name with a non private property of an internal ancestor. Load your code first (autoloader, class map…), then run it on the PHP version you are migrating to:

isInternal()) { continue; }

    for ($p = $r->getParentClass(); $p; $p = $p->getParentClass()) {
        if (!$p->isInternal()) { continue; }

        foreach ($r->getProperties() as $prop) {
            if ($prop->getDeclaringClass()->getName() !== $class) { continue; }

            $name = $prop->getName();
            if ($p->hasProperty($name) && !$p->getProperty($name)->isPrivate()) {
                printf("%s::$%s collides with %s::$%s\n",
                    $class, $name, $p->getName(), $name);
            }
        }
    }
}
?>

Incompatible declarations will stop the script with a fatal error as soon as the class is loaded, which is the loud version of the report. Compatible ones, such as a public string $id in a DOMElement child, compile fine on PHP 8.3 but are reported by the script: the name now means something to the parent class, and it is worth checking that both meanings still agree.

    MyElement::$id collides with DOMElement::$id

Conclusion

Along the way, we ruled out a new PHP version, a new error message and a special treatment for native classes, and reviewed several edge cases of property inheritance: static versus non static, visibility, types, private and final properties. The real cause was a small, well meaning addition to the DOM API.

For the DOM extension, $id was a green field: an empty slot, waiting for a standard property. For the code that extends DOMElement, it was also a green field, when it was written. The migration error could have come from PHP adding the property, or the custome code adding it on its own. The only way out is to rename a property that had done nothing wrong for years. This is yet another case of a painful migration, discovered at compile time, one Fatal error at a time.

The post What do you mean, redeclare a property static? appeared first on Exakat.

Tracing a PHP CLI application with filo - Exakat

2026-09-15T06:05:54.000Z

Tracing a PHP CLI application with filo

filo is a zero-extension PHP call tracer. No PECL module, no Xdebug session: it registers a file:// stream wrapper and rewrites your code’s AST on the way in, so every function entry and exit gets timed. Your files on disk are never touched: instrumented copies live in a throwaway cache.

This tutorial builds a small CLI app with a realistic call stack, traces it, and then turns the trace into something you can actually read.

Everything below was run against filo v0.2.0 / dev-main on PHP 8.3.6. All numbers and output are real.

1. The demo app

orderbot prints an order report. This is nothing exotic: it has a command, a service, two repositories, a pricing helper, a renderer:

src/
├── Cli/
│   ├── Application.php        run() → dispatch + poor man's container
│   ├── ReportCommand.php      execute()
│   └── TableRenderer.php      render()
├── Service/
│   ├── OrderService.php       report()   ← the interesting one
│   ├── PricingService.php     gross()
│   └── TaxCalculator.php      rateFor()
└── Repository/
    ├── OrderRepository.php    all()
    ├── CustomerRepository.php find()
    └── Database.php           usleep() stands in for query latency

The call chain is five levels deep: Application::run → ReportCommand::execute → OrderService::report → OrderRepository::all → Database::selectOrders. Deep enough that a stack trace tells you nothing useful about where time goes.

You can download the filo tutorial source code for this article here. It is a zip archive, with PHP scripts.

Here is the method the whole tutorial revolves around:

orders->all() as $order) {
        $customer = $this->customers->find($order['customer_id']);

        $rows[] = [
            'order'    => $order['id'],
            'customer' => $customer['name'],
            'lines'    => $order['lines'],
            'gross'    => $this->pricing->gross($order),
        ];
    }

    return $rows;
}
?>

At a first glance, it looks fine. And that is the point that Filo tries to fix.

2. Install

composer require --dev giacomomasseron/filo

filo registers bootstrap.php through Composer’s autoload.files, so it executes the instant vendor/autoload.php is loaded — and does nothing at all unless explicitly enabled.

3. The one rule that matters for CLI

The filo feature is not loaded, and neither is anything loaded before vendor/autoload.php.

The stream wrapper can only intercept files that are included after it has been registered. So the entry point must load the autoloader first and everything else second:

#!/usr/bin/env php
run($argv));
?>

If you define classes directly inside bin/orderbot, or require them above the autoloader, they simply won’t appear in the trace. For full coverage including the entry script, point auto_prepend_file at vendor/giacomomasseron/filo/bootstrap.php.

Second rule, smaller: vendor is excluded by default with FILO_EXCLUDE, so you trace your code, not Composer’s.

4. Turning it on

Two switches. For a one-off CLI run, the env var is the natural one:

FILO_ENABLED=1 php -d opcache.enable_cli=0 bin/orderbot report

For an editor-driven workflow, create an empty .filo-on file in the project root instead. It’s checked per run, so toggling is instant. In a Laravel app, a .env entry does not work, as phpdotenv loads after the tracer bootstraps.

The -d opcache.enable_cli=0 is critical: opcache CLI is off by default, but if you’ve turned it on, cached opcodes bypass the wrapper entirely and you’ll get an empty trace.

Run it. The output is byte-identical to the untraced run. Instrumentation doesn’t change behaviour:

ORDER    CUSTOMER            LINES      GROSS
---------------------------------------------
1001     Aurora Tools BV         3     301.29
1002     Aurora Tools BV         1      48.28
1003     Nordwind GmbH           5     928.80
1004     Nordwind GmbH           2     142.80
1005     Papeterie Lyon          4     492.30
1006     Papeterie Lyon          1      18.00

But now there’s a trace next to it:

.filo/traces/20260914-090557-df3af8ef.json

Add .filo/ to .gitignore.

5. What’s in the trace

Format v1 is deliberately small. It is a flat event list, not a nested tree:

{
  "version": 1,
  "duration": 41780000,
  "context": { "sapi": "cli", "argv": ["bin/orderbot", "report"] },
  "events": [
    { "i": 0, "p": -1, "fn": "App\\Cli\\Application::run",
      "file": "/home/you/orderbot/src/Cli/Application.php", "line": 15,
      "s": 149289, "e": 41653573, "m": 3078600 }
  ]
}

i: event id, p — parent event id (-1 = root)
s / e: start and end offsets in nanoseconds from process start
m: memory usage at entry, in bytes
fn: the __METHOD__ form: App\Repo::find, my_function, {closure}

Worth noting: with CLI, the context object carries sapi and argv, not the method/uri pair the README shows for HTTP requests. If you write your own tooling, you might want to handle both.

The one derived number you actually care about isn’t in the file:

self time = (e - s) − Σ (direct children’s e - s)

Inclusive time tells you a call was slow. Self time tells you it was slow rather than something it called.

6. Displaying it, option A: the built-in viewer

vendor/bin/filo serve        # http://127.0.0.1:8090

This is a single-file, zero-dependency viewer on PHP’s built-in server: trace list, zoomable flamegraph, call tree with self-times, top-functions table, and a live panel for paused requests. CLI traces land in the same list as web ones. It is verified against the run above:

 curl -s http://127.0.0.1:8090/api/traces | head -c 200
[{"version":1,"ts":"2026-09-14T09:03:00+00:00","duration":41666870,
  "context":{"sapi":"cli","argv":["bin/orderbot","report"]}, ...

It’s localhost-only by design, as it is supposed to be used by developers or local AI. And, for security reasons, traces contain file paths and variable values, so never expose that port.

Three JSON endpoints back it: /api/traces, /api/breaks, /api/breakpoints. If you want a nicer UI, drop static files into server/ui/ (entry point index.html) and they’re served instead of the built-in page, no code changes needed.

7. Displaying it, option B: in the terminal

For a CLI app, staying in the terminal is often the faster loop, and it makes the trace format concrete. tools/trace-report.php, which is included alongside this tutorial, reads the newest trace and prints a call tree plus a hotspot table. It’s ~150 lines and the only real logic is the self-time subtraction from §5.

php tools/trace-report.php                  # newest trace
php tools/trace-report.php path/to.json     # a specific one

Here is a real output from the run above, abridged in the middle. Of course, your mileage may vary, but it should stay very similar:

filo  bin/orderbot report
41.78 ms · 31 calls · sapi cli · 20260914-090557-df3af8ef.json

CALL TREE   (inclusive | self)
App\Cli\Application::run    41.58 ms |    0.01 ms self
 ├─ App\Cli\Application::makeReportCommand     0.36 ms |    0.36 ms self
 └─ App\Cli\ReportCommand::execute    41.21 ms |    0.01 ms self
    ├─ App\Service\OrderService::report    41.17 ms |    0.04 ms self
    │  ├─ App\Repository\OrderRepository::all     4.17 ms |    0.07 ms self
    │  │  └─ App\Repository\Database::selectOrders     4.10 ms |    4.10 ms self
    │  ├─ App\Repository\CustomerRepository::find     6.11 ms |    0.01 ms self
    │  │  └─ App\Repository\Database::selectCustomer   6.11 ms |    6.11 ms self
    │  ├─ App\Service\PricingService::gross     0.00 ms |    0.00 ms self
    │  │  └─ App\Service\TaxCalculator::rateFor     0.00 ms |    0.00 ms self
    │  ├─ App\Repository\CustomerRepository::find     6.09 ms |    0.00 ms self
    │  │  └─ App\Repository\Database::selectCustomer   6.09 ms |    6.09 ms self
    │           ⋮  (four more identical pairs)
    └─ App\Cli\TableRenderer::render     0.03 ms |    0.03 ms self

TOP FUNCTIONS BY SELF TIME
FUNCTION                                        CALLS     SELF ms    SHARE
---------------------------------------------------------------------------
App\Repository\Database::selectCustomer             6       36.90    88.3%  ← N+1?
App\Repository\Database::selectOrders               1        4.10     9.8%
App\Cli\Application::makeReportCommand              1        0.36     0.9%
App\Repository\OrderRepository::all                 1        0.07     0.2%
App\Service\OrderService::report                    1        0.04     0.1%
App\Cli\TableRenderer::render                       1        0.03     0.1%
App\Service\PricingService::gross                   6        0.03     0.1%
App\Repository\CustomerRepository::find             6        0.03     0.1%

Two design choices make this readable, and they’re worth stealing for any trace UI:

Aggregate by self time, not inclusive time. Sorted by inclusive time, the top of the table would be Application::run at 41.58 ms: technically true, completely useless. Sorted by self time, the actual culprit is line one.

Show the call count next to it. CustomerRepository::find costs 0.01 ms per call; nobody would ever optimise it. What matters is the pair high call count × high total self time, which is the signature of an N+1. The script flags it automatically (≥5 calls and ≥10% of runtime), and the repetition in the call tree above is the same finding in visual form.

Note also how the tree exonerates the innocent: OrderService::report has 41.17 ms inclusive but 0.04 ms self. It isn’t slow. It’s calling something slow, six times.

8. Acting on it

The trace says: 6 customer lookups for 6 orders, but only 3 distinct customers. Batch them.

-        $rows = [];
-
-        foreach ($this->orders->all() as $order) {
-            $customer = $this->customers->find($order['customer_id']);
+        $rows   = [];
+        $orders = $this->orders->all();
+
+        // Resolve every customer up front, in one pass.
+        $customers = $this->customers->findMany(array_column($orders, 'customer_id'));
+
+        foreach ($orders as $order) {
+            $customer = $customers[$order['customer_id']];

with findMany() de-duplicating ids before hitting storage. Re-run, re-measure:

	calls traced	`selectCustomer`	total
before	31	6 × — 36.90 ms	41.78 ms
after	23	3 × — 18.44 ms	23.68 ms

43% off the runtime, and the measurement loop was: run the command, run the report script. That’s the useful part of having a tracer wired into a CLI app.

9. Bonus: pausing a CLI run

filo also does function-entry breakpoints, without a daemon, nor a IDE protocol. They work on a CLI process exactly as on a web request:

$ vendor/bin/filo break "App\Service\PricingService::gross"
breakpoint added: App\Service\PricingService::gross

# terminal 1 — the process freezes at that function's entry
$ FILO_ENABLED=1 php -d opcache.enable_cli=0 bin/orderbot report

# terminal 2
$ vendor/bin/filo pending
090547-13d7e9  App\Service\PricingService::gross   bin/orderbot report

$ vendor/bin/filo show 090547-13d7e9
App\Service\PricingService::gross
  at /home/you/orderbot/src/Service/PricingService.php:11
  request: bin/orderbot report
  vars:
{
    "order": {
        "id": 1001,
        "customer_id": 7,
        "lines": 3,
        "net": 249,
        "country": "NL"
    },
    "__this": {
        "__class": "App\\Service\\PricingService",
        "props": { "tax": { "__class": "App\\Service\\TaxCalculator", "props": [] } }
    }
}

$ vendor/bin/filo continue 090547-13d7e9
released 090547-13d7e9

The command then finishes normally and still writes its trace. There are some noteworthy details:

Entry only. You see arguments and $this as the function begins. No stepping, no eval, as these are deliberately left to Xdebug.
Once per request. So a breakpoint inside a loop pauses once, not six times.
Pause time is excluded from trace timings. So inspecting doesn’t corrupt your numbers.
Auto-continue after FILO_BREAK_TIMEOUT seconds, by default 120, a forgotten breakpoint can’t hang a process forever.
State lives in .filo/breakpoints.json and .filo/traces/breaks/; the CLI and the web UI read and write the same files, so you can mix them freely.

One practical note from building this: if a paused process is killed rather than continued, its snapshot lingers in pending. vendor/bin/filo continue --all clears the strays.

10. Gotchas worth knowing up front

Gotcha	What happens	Fix
opcache on	Cached opcodes bypass the wrapper: empty or stale traces. Worse on web: opcache may keep serving instrumented code after you disable tracing, since the file on disk never changed	`opcache.enable=0` while tracing (CLI is off by default)
Code loaded before the autoloader	Silently missing from the trace	Load `vendor/autoload.php` first, or use `auto_prepend_file`
Native functions, `eval`, arrow functions	They are not instrumented: they show up as self time of their caller	Expected; read a fat self time as “this frame plus its native calls”
Line numbers in instrumented files	Drift, because of the pretty printer	Trace line numbers are still correct — baked in from the original AST
Long-running workers (Octane, RoadRunner, FrankenPHP)	Shutdown flush never fires	Call `\Filo\Collector::cycle($dir)`at your request boundary
Traces contain values and paths	Leaking them would be bad	Never expose `filo serve`; keep `.filo/` gitignored

11. Where to take it next

filo also plugs into test suites, which is the natural home for what section 8 did by hand: it turns the finding into a regression guard:

 $service->report())->toRunUnder(30);              // ms
expect(fn () => $service->report())->toCall('App\Repository\Database::selectCustomer')->atMost(3);

// PHPUnit, via the Filo\Testing\FiloAssertions trait
$this->assertCallCount('App\Repository\Database::selectCustomer', atMost: 3, callable: fn () => $service->report());
?>

toCall() on its own asserts nothing — always finish the chain with atMost() / atLeast() / times(). And if the suite runs without filo enabled, call-based assertions throw FiloNotEnabledException rather than silently passing, which is the right default.

Register Filo\Testing\PHPUnit\TraceExtension in phpunit.xml and every failing test drops a trace artifact in .filo/traces/tests/ — openable in the same viewer, uploadable from CI as a build artifact.

12. Conclusion

filo is a genuinely interesting tool, and the reason is the idea at its core rather than the feature list.

Call tracing in PHP has always been extension territory. You install Xdebug or XHProf or Excimer, you fight your php.ini, and on shared hosting or a locked-down container you simply don’t get to profile at all. filo sidesteps the whole problem by noticing that PHP lets you take over file:// yourself: register a stream wrapper, parse each incoming file with nikic/php-parser, inject entry and exit hooks into the AST, hand the rewritten source back to the engine. The engine never knows. Your files on disk are never touched: the instrumented copies live in a throwaway cache. It is a genuinely creative use of a mundane part of the language, and it’s rare to see a userland trick buy you this much.

What that creates is actual feature. From the run in this tutorial: a full parent-linked call tree with correct self-time accounting, aggregation that surfaced an N+1 three layers down as 88.3% of runtime, a flamegraph viewer, per-test trace artifacts for CI, performance assertions you can commit as regression guards, and, the part I expected to be vapour, working function-entry breakpoints on a live CLI process, complete with arguments and $this, with pause time correctly excluded from the timings so inspecting doesn’t corrupt your numbers. No extension. No daemon. No IDE protocol. Two commands from composer require to a flamegraph.

The rough edges are real, though, and mostly follow from the same design choice. Because instrumentation happens at include time, anything the engine loads another way is invisible: your entry script, anything required above the autoloader, native functions, eval, arrow functions. Because the trick operates on source that opcache has already cached, opcache and filo cannot coexist, and the failure mode on a web SAPI is nasty, since opcache may keep serving instrumented code after you switch tracing off, the file on disk being unchanged. Smaller scrapes show elsewhere: line numbers drift inside instrumented files, a killed process leaves a stale entry in pending until you run continue --all, and the shipped web UI is explicitly a functional placeholder with a documented seam for replacing it. None of these bit me hard, but you do need to know them: see section 3 and section 10.

That’s a fair trade for v0.2.0 on a package with single-digit installs. The architecture is sound, the constraints are honestly documented rather than hidden, and the author has clearly thought about the failure modes: the auto-continue timeout on breakpoints and the FiloNotEnabledException on silently-unenforced assertions are both the kind of detail you only add after being burned. Whether it matures into something you’d reach for over Xdebug depends on questions byeond this tutorial: overhead on a large real codebase, behaviour under frameworks with heavy bootstrapping, and how the viewer develops.

Worth watching, and worth an afternoon on a project where installing an extension isn’t an option. Keep an eye on where filo goes.

The post Tracing a PHP CLI application with filo appeared first on Exakat.

PHP Property Resolution Order: Class · Trait · Parent · Interface - Exakat

2026-09-14T09:45:25.000Z

PHP Property Resolution Order: Class · Trait · Parent · Interface

PHP offers the same four places to define a property that it offers for constants: directly in a class, in a trait the class uses, in a parent class it extends, and, as of PHP 8.4, in an interface it implements. Since these different places may all happen at the same time, they are in competition. So, thre will be only one winner in the PHP property resolution order: Class, Trait, Parent, Interface

That last one used to be a flat “no”. For the entire history of the language before 8.4, interfaces could not declare properties at all; they were the one member kind interfaces had nothing to say about. Property hooks changed that, but not by making interfaces work like they do for constants. They introduced a third model, distinct from both.

There’s also a dimension constants never had to deal with: storage. A constant is a value: read it from anywhere in the hierarchy and you get one thing back, copied conceptually into whichever class resolves it. A property is a slot in an object, or a shared cell on a class, and where that slot lives is not always where you’d guess. Two of the surprises below come directly from that difference.

The priority stack

Priority	Layer	Description
1 highest	Class own property	Always wins. Defined directly in the class body, or as a promoted property.
2	Trait property	Used when the class has no own definition. Copied in at compile time: value-checked against the class’s own definition, but not against the parent’s.
3	Parent class property	Inherited when nothing more local claims the name. A “inherited” doesn’t always mean “copied”. See the static-property section below.
4 new in 8.4	Interface hooked property only	A plain property on an interface is a compile error. A hooked property is a contract, exactly like an interface method: the interface says the property must exist and be readable or writable or both; the implementing class supplies the actual logic.

Tier 4 isn’t really competing with tiers 1–3 the way an interface constant competes with a parent constant. A hooked property in an interface has no storage and no default value of its own. It’s a shape, not a value. So there’s no version of the constants article’s “ambiguous, parent and interface both supply a value” fatal error here. Properties sidestep that entire category of conflict, at the cost of interfaces being locked out of the storage-based kind of property for good.

A concrete example

greeting;
// "Hello from App itself"
?>

This code actually fails, as the compatibility between the class and the trait definition MUST be complete: down to the default value. If the definition is not the same, it yields a “App and HasGreeting define the same property ($greeting) in the composition of %s. However, the definition differs and is considered incompatible. Class was composed” compilation error.

Now, remove App‘s own property and the trait takes over: "Hello from trait", with no complaint that it disagrees with the parent’s value: class-vs-parent and trait-vs-parent are silent overrides, not a checked ones. Remove the trait too, and App simply inherits BaseGreeter‘s property, no conflict, because nothing else at that level is competing for the name.

Interfaces couldn’t join this club, until PHP 8.4

Fatal error: Interfaces may only include hooked properties
?>
[/php]

That’s the whole story, for every PHP version before 8.4: an interface demanding a property was simply not expressible. Property hooks reopen the door, but as a contract for behavior, not storage:

 'Hello, hooked'; }
}

echo (new App)->greeting; // "Hello, hooked"
?>

This is structurally closer to how interfaces handle methods than how they handle constants: the interface declares that reading or writing $greeting must be possible, and leaves the actual value, computed, stored, whatever the implementer wants, entirely up to the class. Two interfaces can declare the same hooked property name without any risk of the “ambiguous” fatal error the constants article ran into, because neither interface is supplying a competing value to be ambiguous about.

The rules that catch people out

Trait beats parent, no questions asked

foo; // "trait-val" — no error, despite disagreeing with the parent
?>

Same rule as constants: a trait property is compiled directly into the class body, so it’s treated as the class’s own definition the moment there’s nothing more local to contest it.

Class beats trait — but only if they agree, or the class overrides

Fatal error: C and T define the same property ($foo) in the
composition of C. However, the definition differs and is
considered incompatible.
?>
[/php]

Give the class the same default the trait has and it compiles fine. This value-sensitivity is specific to the class-vs-its-own-traits relationship: it doesn’t apply to trait-vs-parent, which never checks at all.

Two traits, same property: fatal only if the defaults differ

Identical defaults compile without complaint. As with constants, there’s no insteadof/as for properties: that syntax only resolves method conflicts. The only fix is declaring the property explicitly on the class.

Shadowing a private property doesn’t override it — it duplicates it

This is the one with no equivalent anywhere in the constants article, because constants aren’t storage and can’t be duplicated. Properties can:

x; }
}
class ChildF extends ParentF {
    private $x = 'child-x';
    public function dumpChild() { return $this->x; }
}

$obj = new ChildF();
var_dump($obj);
?>

object(ChildF)#1 (2) {
  ["x":"ParentF":private]=>
  string(8) "parent-x"
  ["x":"ChildF":private]=>
  string(7) "child-x"
}
?>
[/php]

Both $x properties are alive in the same object, in two separate storage slots, each visible only from methods declared in its own class. dumpParent() reads ParentF‘s slot, dumpChild() reads ChildF‘s slot — from the outside this looks like one property, but it’s genuinely two. This only happens with private; protected and public properties with the same name really do get overridden, one slot, like you’d expect.

Static properties: shared storage unless you redeclare

Skip redeclaring a static property in the child and it isn’t “inherited” in the copy sense at all: it’s the literal same storage cell, and writes through either class name are visible through the other. Redeclare it, even with the same value, and that link is severed:

Nothing in the constants model prepares you for this, because constants have no concept of a write happening after declaration: this is a live, mutable, shareable cell, not a value baked in at compile time.

`readonly` blocks a subclass from re-touching an already-set property

foo = 'parent-init'; }
}
class ChildI extends ParentI {
    public function __construct() {
        parent::__construct();
        $this->foo = 'child-attempt'; // too late — already initialized
    }
}
?>

Error: Cannot modify readonly property ParentI::$foo
?>
[/php]

The lock applies per-property, not per-class: once parent::__construct() has set it, no code anywhere, including a subclass constructor, gets a second write.

Uninitialized typed properties throw exceptions, they don’t default to null

x;
?>

Error: Typed property C::$x must not be accessed before initialization
?>
[/php]

This isn’t strictly a resolution-order rule, but it’s a failure mode constants simply cannot have, so it is worth mentioning here. A constant always has a value the moment the class is compiled. A typed property without a default can exist, structurally, in a state where reading it is an error.

Calling up the chain: `self::` vs `static::`

Same late-static-binding split as constants, but with real consequences now that static properties are shared storage rather than fixed values:

self::$foo, written inside ParentH, always reads ParentH‘s cell, no matter which subclass calls the method. static::$foo reads whichever class’s cell is actually in play. Combined with the storage-sharing rule above, this means self:: and static:: can end up pointing at two different cells entirely, not just two different values.

Side note reminder: enums

This is the sharpest three-way contrast of the whole series. Enums can declare their own constants freely, and they can implement interfaces just like classes: but they cannot declare properties at all, of any kind:

Not instance properties, not static ones, not hooked ones: the baillon is total. An enum case is meant to be a fixed, singleton value; giving it mutable storage would undermine that guarantee, so PHP forbids the whole category rather than picking rules for it. Where the constants article found enums following the same rules as classes, properties are where enums diverge completely.

The mental model

For class constants, “closest wins” was nearly the whole story, with one wrinkle: same-distance conflicts, like two interfaces or two traits, need an explicit tiebreaker because there’s no storage to fall back on: only values, and values don’t merge. Properties keep the “closest wins” rule for which definition is visible, but add a second, independent question the constants model never had to ask: is it the same storage, or two different storages wearing the same name?

Public and protected inheritance answer that question the boring, expected way: one property, always redefined identically. Private inheritance answers it the surprising way: two properties, coexisting, as dizigot twins. Static properties answer it based on whether the child bothered to redeclare, one shared cell, or two independent ones. Interfaces, which fully participated in the constants story, sit almost entirely outside the properties story, contributing shape through hooks but never storage. Knowing which value resolves is only half of understanding a property; the other half is knowing which piece of memory it actually lives in.

In the end, it is a zoo with very diverse animals.

The post PHP Property Resolution Order: Class · Trait · Parent · Interface appeared first on Exakat.

RisingWave, PHP, and the Streaming Database Idea - Exakat

2026-09-12T20:50:44.000Z

RisingWave, PHP, and the Streaming Database Idea

A regular database answers the question you ask it, once, against whatever state happens to be sitting on disk at that moment. If the data changes a second later, your answer is stale until you ask again. This is why dashboards poll, and why “real-time analytics” has historically meant “batch job that runs every five minutes instead of every night.” Streaming SQL engines, such as Storm, Kafka Streams, ksqlDB, or Flink SQL, grew up to close that gap, but they did it by putting a processing layer in front of a database, not by being one: you still needed somewhere to land the output.

A streaming database collapses that distinction. You write an ordinary CREATE MATERIALIZED VIEW ... AS SELECT ..., and instead of computing it once, the engine keeps it continuously correct: every insert that touches the view’s inputs is incrementally folded into the result, and the query never has to run again from scratch. Materialize popularized the idea, and, tellingly, chose to speak Postgres’s wire protocol rather than invent its own client ecosystem. RisingWave, first released in 2022 and written in Rust, took the same premise of incremental view maintenance, not recomputation, and paired it with a Snowflake-style architecture: compute nodes that scale independently of storage, with S3 or a compatible object store as the actual source of truth underneath.

For this piece it’s enough to know it as a database that happens to update its views for you. To make that concrete, imagine a coffee shop, BrewStream, whose orders you want to track as they arrive rather than re-query for. Now, let’s use RisingWave to make this work and deliver delicious coffee.

Setting up RisingWave

RisingWave ships a self-contained “playground” image for exactly this kind of exploration: one process, in-memory storage, gone after 30 minutes of inactivity. We’ll use Docker for that.

docker run -it --pull=always -p 4566:4566 -p 5691:5691 risingwavelabs/risingwave:latest playground

Port 4566 is the SQL interface: this is the one PHP will talk to. Port 5691 is a dashboard, useful for watching a materialized view’s fragments graph while you tinker, but nothing below depends on it.

Connect with psql, because RisingWave speaks the PostgreSQL wire protocol closely enough that the actual psql binary doesn’t know the difference:

psql -h localhost -p 4566 -U root

PSA: we are not using password here. This is a playground, not a production environment.

A table, same as any other

CREATE TABLE coffee_orders (
    order_id INT,
    coffee_type VARCHAR,
    size VARCHAR,
    customer_name VARCHAR,
    order_time TIMESTAMP
);

Nothing streaming-specific here yet. coffee_orders is a plain table you can INSERT into, exactly as PostgreSQL would let you. The streaming part will be added later, at the moment something else shows up and queries it continuously.

The producer: pushing orders from PHP

There is no risingwave/php-client package published on Packagist, and there doesn’t need to be one. RisingWave’s front door is the Postgres wire protocol, and PHP has shipped a driver for that protocol since pdo_pgsql landed in PHP 5.1L a driver written years before RisingWave existed, which will connect to it without modification. The only requirement is the extension, which is part of the PHP core:

php -m | grep pdo_pgsql

Now, producer.php simulates BrewStream’s influx of coffee orders, one at a time:

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

    $coffeeTypes = ['Espresso', 'Latte', 'Cappuccino', 'Americano'];
    $sizes = ['Small', 'Medium', 'Large'];
    $customers = ['Alice', 'Bob', 'Charlie', 'Diana', 'Eve'];

    for ($i = 1; $i <= 10; $i++) {
        $order = [
            'order_id' => $i,
            'coffee_type' => $coffeeTypes[array_rand($coffeeTypes)],
            'size' => $sizes[array_rand($sizes)],
            'customer_name' => $customers[array_rand($customers)],
            'order_time' => date('Y-m-d H:i:s'),
        ];

        $stmt = $conn->prepare(
            'INSERT INTO coffee_orders (order_id, coffee_type, size, customer_name, order_time)
             VALUES (:order_id, :coffee_type, :size, :customer_name, :order_time)'
        );
        $stmt->execute($order);

        echo "Order #{$i}: {$order['coffee_type']} ({$order['size']}) for {$order['customer_name']} at {$order['order_time']}\n";

        sleep(1);
    }

    echo "All orders placed!\n";
} catch (PDOException $e) {
    die('Error: ' . $e->getMessage());
}

php producer.php

Ten coffee INSERTs over ten seconds. This is fine for a demo, and it represents a fair stream. A real BrewStream would front this with a CDC source or a Kafka topic rather than a PHP loop holding a PDO connection open; that distinction matters enough, so we’ll come back to it at the end. For now, let’s leave it aside.

Reading the stream back, four ways

The interesting part isn’t that PHP can read from RisingWave: any Postgres client can. It’s that the same stored rows support four genuinely different query shapes without extra plumbing on RisingWave’s side.

Everything

This is basically a SQL database. Not impressive, but perfect to have some classic tools to start with a new technology.

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

$stmt = $conn->query('SELECT * FROM coffee_orders');
foreach ($stmt->fetchAll(PDO::FETCH_ASSOC) as $order) {
    echo "Order #{$order['order_id']}: {$order['coffee_type']} ({$order['size']}) for {$order['customer_name']} at {$order['order_time']}\n";
}
?>

Filtered

This supports also the WHERE clause.

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

$coffeeType = 'Latte';
$stmt = $conn->prepare('SELECT * FROM coffee_orders WHERE coffee_type = :coffee_type');
$stmt->execute(['coffee_type' => $coffeeType]);
foreach ($stmt->fetchAll(PDO::FETCH_ASSOC) as $order) {
    echo "Order #{$order['order_id']}: {$order['size']} for {$order['customer_name']} at {$order['order_time']}\n";
}
?>

Aggregated

And the GROUP BY clause.

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

$stmt = $conn->query('SELECT coffee_type, COUNT(*) AS order_count FROM coffee_orders GROUP BY coffee_type');
foreach ($stmt->fetchAll(PDO::FETCH_ASSOC) as $row) {
    echo "{$row['coffee_type']}: {$row['order_count']} orders\n";
}
?>

Three ordinary SQL queries, indistinguishable from what you’d write against MySQL. The fourth one is where RisingWave stops pretending to be an ordinary database.

Continuously aggregated

CREATE MATERIALIZED VIEW coffee_orders_by_type AS
SELECT coffee_type, COUNT(*) AS order_count
FROM coffee_orders
GROUP BY coffee_type;

It looks a bit like SQL, but it has some important nuance. That GROUP BY doesn’t get recomputed on read. RisingWave maintains it incrementally: every new row in coffee_orders nudges the count for its coffee_type rather than triggering a full rescan.

The naive way to read that back from PHP is what the previous three scripts already do: SELECT * FROM coffee_orders_by_type in a while (true) loop with a sleep(2). It works, and it’s also exactly the busy-polling this whole exercise was supposed to get away from: PHP asking “anything new?” on a timer, indistinguishable from hammering a plain table.

RisingWave has a better primitive for this, and PHP has one too: they just need introducing to each other.

On the RisingWave side, a subscription turns a table or materialized view into something you FETCHfrom rather than SELECT from, and the fetch can block on the server until a row actually shows up:

CREATE SUBSCRIPTION coffee_orders_sub FROM coffee_orders_by_type WITH (retention = '1D');
DECLARE order_cursor SUBSCRIPTION CURSOR FOR coffee_orders_sub SINCE now();

-- returns as soon as a change arrives, or after 5 seconds, whichever is first
FETCH NEXT FROM order_cursor WITH (timeout = '5s');

Each row that comes back carries an op column: Insert, UpdateInsert, UpdateDelete, or Delete — so a consumer sees not just the new count but what kind of change produced it.

That solves RisingWave’s half of the problem: the server no longer has to be asked twice for the same unchanged answer. It doesn’t yet solve PHP’s half: calling that FETCH through an ordinary synchronous query still ties up the PHP process for up to five seconds, unable to do anything else, which is a strange way to treat “waiting for I/O” in a language whose sockets have supported non-blocking waits for decades. This is where pg_socket() earns its keep. It hands you the raw socket resource behind a PostgreSQL connection: it is a resource PDO’s pgsql driver deliberately keeps hidden, which is why this one script switches to the lower-level pgsql extension instead. Once you have that socket, stream_select() can lock on it exactly the way it would block on a file, a pipe, or any other stream, which means “wait for RisingWave’s next change” stops being a special case and becomes one more file descriptor in an ordinary I/O wait:

The shape looks similar to the polling version. After all, it is still a while (true), still one iteration per change. But the wait inside it is now a real wait. stream_select() returns the moment data lands on the wire rather than on a fixed clock tick, and because it’s a wait on a file descriptor rather than a sleep(), it composes: hand it a second socket and this loop watches two RisingWave subscriptions, or ten, without spinning a thread per connection. At ten orders a sleep(2) loop and this one are indistinguishable to the person watching the terminal. The difference only shows up under load, and under load is exactly when you can’t afford a poll interval as your latency floor.

Putting it together

Start RisingWave (playground image).
Create coffee_orders and coffee_orders_by_type.
Run producer.php to generate orders.
Run any consumer script against the same tables: plain reads and the continuously maintained aggregate coexist without conflict.

The bigger picture: fewer moving parts, not just faster ones

The BrewStream example above is one PHP script INSERT-ing into a table it also owns: a fine way to learn the SQL, but not why anyone puts RisingWave in front of a real system. The actual case starts one layer up: a production Postgres or MySQL database that’s the system of record for orders, and a reporting need that shouldn’t be allowed anywhere near it.

The conventional answer is Change Data Capture: point Debezium at the database’s write-ahead log or binlog, publish every row change to a Kafka topic, run a stream processor to reshape it, land the result somewhere queryable. That’s four systems, namely connector, broker, processor, sink, to keep configured, monitored, and upgraded in lockstep, in service of one goal: let something read the data without touching the primary. RisingWave’s CDC connectors fold all four into one CREATE TABLE ... FROM cdc statement, reading the source database’s log directly and taking a consistent snapshot before it starts streaming, so the pipeline that used to be a small distributed system becomes a line of SQL.

What you get for that is the second half of the trade: heavy, bursty, or badly-written analytical queries, such as the GROUP BY a dashboard fires every ten seconds, the report someone runs at month-end, move onto RisingWave’s copy of the data instead of the OLTP database that also has to process checkout. The primary stops being asked to be two things at once.

PostgreSQL protocol everywhere!

And underneath both of those wins sits the detail that should, honestly, be a little startling: none of this required a new PHP driver. pdo_pgsql for the ordinary reads, the plain pgsql extension for the socket-level subscription — both predate RisingWave by well over a decade, and neither was written with the faintest idea it would one day be handed a stream_select()-driven subscription cursor to talk to. RisingWave’s actual machinery, a distributed dataflow engine maintaining incremental views over object storage, has nothing in common with a single-node B-tree-and-WAL database. It doesn’t matter. It answers on port 5432-shaped wire protocol like Postgres does, so every tool built assuming “the other end is Postgres”: psql, pdo_pgsql, Grafana, dbt, whatever a PHP developer already had installed in 2007: it just works. Materialize made the same choice; so did CockroachDB, so did YugabyteDB. The wire protocol PostgreSQL happened to define has quietly become the thing every ambitious new database engine speaks at its front door, whatever it’s doing in the basement. It is quite impressive to see the evolution from a protocol between a server and its client become an insdustry standard.

Anoter tool for your database architecture

Databases are notoriously the slowest part of an online application. Data streaming is a modern tool to extract data that needs to be feed back in the application fast and in real time. With a materialized view, and some possible processing between ingestion and publication, RisingWave is a great tool to improve your application level of reactivity.

The post RisingWave, PHP, and the Streaming Database Idea appeared first on Exakat.

When PHP Reads Something Else: Visual Traps in Source Code - Exakat

2026-09-10T20:09:19.000Z

When PHP Reads Something Else: Visual Traps in Source Code

PHP code is read by two very different audiences: human developers and the PHP parser. Humans read glyphs, the shapes our eyes recognise. The parser reads bytes or characters, raw octets encoded in a file. Most of the time these two views agree perfectly. Sometimes they disagree in ways that are merely confusing. And occasionally they disagree in ways that are actively exploitable.

This post takes a tour through the full spectrum, from the classic letter O versus the digit 0, to the genuinely dangerous Cyrillic homoglyphs in class names. Along the way we will look at Unicode comment starters, non-breaking spaces, dollar-sign imposters, and invisible variable names. Each chapter builds on the same underlying idea: the character you see and the byte PHP reads are not always the same thing.

1. The classic confusables: human eyes under pressure

Long before Unicode entered the picture, programmers were already fooling themselves with plain ASCII. The most famous offenders are the pairs that look nearly identical in many monospace fonts:

Looks like	Actually	Code point
`O` (letter oh)	`0` (digit zero)	U+004F vs U+0030
`l` (lowercase L)	`1` (digit one)	U+006C vs U+0031
`S`	`$` (dollar)	U+0053 vs U+0024
`Q`	`0` or `O`	U+0051 vs U+0030 / U+004F

The $ / S pair is particularly dangerous in PHP because $ is syntactically significant. A variable $status misread as Status becomes a bare string constant or, with strict_types, a fatal error. In the other direction, a stray $ in a string context can silently interpolate a variable you never intended to reference.

These problems are not purely historical. They still bite developers who:

Work in low-contrast dark themes where O and 0 are hard to tell apart.
Copy-paste from PDFs, which sometimes substitute similar glyphs.
Review code at the end of a long day (yes, cognitive fatigue matters).
Get older and need help with vision (not me, I have had glasses since the age of 7)

The traditional defences are the same ones your IDE enforces without you thinking about them: 80-column limits and short methods. A narrow column means fewer characters per line, which reduces the visual search space. A short method means fewer lines on screen at once, which means each identifier is referenced more often and any typo is spotted sooner. These are not arbitrary style rules: they are empirical answers to the limits of human pattern matching.

2. Unicode comment starters pack: the `#️⃣️` trick

PHP has four comment syntaxes: //, #, /* … */, and /** … */. There is, in fact, a fifth, or rather a family of them, thanks to Unicode.

PHP’s lexer works byte by byte. When it encounters byte 0x23 outside a string, it opens a line comment and discards everything until the next newline. 0x23 is the ASCII code for #. The trick is that several Unicode grapheme clusters, that is sequences of code points that a human perceives as one character, begin with the byte 0x23 followed by combining code points.

#️⃣️  =>  23 EF B8 8F E2 83 A3 EF B8 8F   (keycap hash emoji)
#⃣  =>  23 E2 83 A3                      (hash + combining enclosing keycap)
#️  =>  23 EF B8 8F                      (hash + variation selector-16)

PHP sees the leading 0x23 and opens a comment. The remaining bytes of the emoji are swallowed as comment content. The result: this is valid PHP that executes without error:

What works and what does not:

Character	First byte	PHP treats as comment?
`#`	23	✓ always (standard)
`#️` (# + VS-16)	23	✓ yes
`#⃣` (# + keycap)	23	✓ yes
`#️⃣️` (full keycap emoji)	23	✓ yes
`＃` U+FF03 fullwidth	EF	✗ no
`﹟` U+FE5F small	EF	✗ no

The look-alike Unicode # symbols, fullwidth # and small # do not work because their UTF-8 encoding begins with 0xEF, not 0x23. The illusion only works for grapheme clusters that literally start with the plain ASCII #.

3. Non-breaking spaces: the non-breakable space

Copy a PHP snippet from a rendered HTML page, a PDF, or a Word document and you may import a character that looks exactly like a space but is not: the non-breaking space, also known as U+00A0, UTF-8 bytes C2 A0.

PHP’s lexer recognises as whitespace only the six ASCII control characters0x20 0x09 0x0A 0x0D 0x0B 0x0C. A non-breaking space is not among them. Its two bytes C2and A0 are both in the range 0x80–0xFF, which PHP’s identifier rules accept as valid identifier characters. The parser therefore tries to incorporate the non-breaking space into whatever token it is currently building.

The error message is baffling because the file looks perfectly formatted. Most editors render U+00A0 identically to U+0020. The fix is a linter or editor rule that highlights non-ASCII bytes outside strings and comments — or, better, a editorconfig + IDE combination that refuses to save files with unexpected encoding.

Zero-width characters compound this further. U+200B (ZERO WIDTH SPACE), U+200C (ZERO WIDTH NON-JOINER), and U+200D (ZERO WIDTH JOINER) are completely invisible, yet their bytes (E2 80 8B, E2 80 8C, E2 80 8D) are valid PHP identifier bytes. A function named validateInput (with an invisible U+200B between validate and Input) is a different function from validateInput. The call site and the definition can be made to reference different functions while looking completely identical in any editor.

4. Dollar-sign look-alikes: the imposters that fail silently

After comments and spaces, we can start looking at the weirder characters. Unicode contains several characters that look like the PHP variable-starting $ U+0024:

Character	Code point	UTF-8
`＄`	U+FF04 fullwidth dollar	EF BC 84
`﹩`	U+FE69 small dollar	EF B9 A9
`💲`	U+1F4B2 heavy dollar sign	F0 9F 92 B2

None of these starts a PHP variable. PHP’s variable rule triggers on byte 0x24 only. Every UTF-8 multi-byte sequence has a lead byte ≥ 0xC0, so no single Unicode character, other than $ itself, can trigger variable parsing.

A subtle code-review trap: a line that reads ＄config['key'] looks like it is reading a variable, but PHP would produce a parse error or treat the whole thing as an unexpected token. An attacker who replaces a legitimate $config['key'] with ＄config['key'] in a patch could silently neutralise a security check while the diff looks harmless to a distracted reviewer.

5. The dollar sign combined with Unicode: invisible variable names

The flip side of the look-alike problem is the extension problem. Just as #️⃣️ combines the ASCII #with emoji-forming code points, you can combine the ASCII $ with Unicode combining characters to create grapheme clusters that start a variable but embed the combining bytes into the variable name:

$️⃣  →  24 EF B8 8F E2 83 A3   ($ + VS-16 + combining keycap)

This is where the analogy with comments breaks down sharply:

Comment: bytes after 0x23 on that line are inert: they vanish into comment text.
Variable: bytes after 0x24 are parsed as the variable name: they survive and matter.

Consequence: $️⃣secret and $secret are completely different variables.

A malicious contributor could introduce a variable assignment that looks identical to a legitimate one but writes to a different slot in the symbol table. The legitimate variable remains unmodified. The injected value is never used. Both facts are invisible without byte-level inspection.

May be malicious is not the right adjective: facetious may be better. But now, we can meet the real serious cases.

6. Cyrillic homoglyphs: the real security threat

Everything above can be classified as confusing, surprising, or exotic. Cyrillic homoglyphs are in a different category: they are a documented attack vector used in real-world supply-chain compromises.

Numerous Cyrillic letters are visually indistinguishable from their Latin counterparts in most fonts:

Cyrillic	Code point	Latin look-alike	Code point
`а`	U+0430	`a`	U+0061
`е`	U+0435	`e`	U+0065
`о`	U+043E	`o`	U+006F
`р`	U+0440	`p`	U+0070
`с`	U+0441	`c`	U+0063
`х`	U+0445	`x`	U+0078
`А`	U+0410	`A`	U+0041
`В`	U+0412	`B`	U+0042
`С`	U+0421	`C`	U+0043

Because PHP identifiers accept bytes 0x80–0xFF, a class defined as Rеquest (where е is Cyrillic U+0435) is syntactically valid and entirely distinct from Request (Latin e). The bytes differ; PHP sees two different class names.

The attack surface is significant:

Shadow class injection. An attacker adds a file to a project that defines a class whose name is the Cyrillic homoglyph of a framework class. A crafted use statement or a subtly altered autoloader path causes the shadow class to be loaded instead of the real one. The diff shows only what appears to be a trivial typo or whitespace change.

Bypassing instanceof checks. A guard like if (!$obj instanceof Request) will pass silently when $obj is an instance of Cyrillic Rеquest, because the two class names do not match.

Autoloader confusion. PSR-4 autoloaders translate class names to file paths. Rеquest with Cyrillic bytes would resolve to a file path that contains those bytes, a file that probably does not exist, or in a hostile scenario, one that was planted.

String comparisons. Any code that compares class names as strings, get_class($obj) === 'Request', will silently fail or pass incorrectly depending on which alphabet was used in the definition.

This class of attack is not theoretical. It mirrors the IDN homograph attack with domain names mixing scripts, and the Trojan Source attack, CVE-2021-42574, which uses bidirectional Unicode control characters to reorder how code appears in an editor versus how the parser reads it. Both have real CVEs.

7. Defence: what to actually do

Use token_get_all() as a source-code auditor. PHP’s own tokenizer exposes every token and its byte content. A short script can scan a codebase for non-ASCII bytes appearing outside string literals and comments:

Configure your editor to render non-ASCII bytes visibly: most IDEs have a “show invisible characters” or “highlight non-ASCII” option. Pair this with an .editorconfig rule enforcing ASCII-only identifiers.

Add a CI lint step that rejects PHP source files containing non-ASCII bytes in identifier positions. Tools like grpc/php-cs-fixer, static analysers, or a custom pre-commit hook can enforce this.

For OSS projects: require signed commits and enforce Unicode identifier restrictions in code review checklists, particularly for any file that touches authentication, authorisation, or class-loading paths.

Summary

PHP source code sits at the intersection of two audiences: human eyes and a byte-eating parser. And the gap between them is wider than most developers realise.

Topic	Human sees	PHP reads
`S` vs `$`	same glyph in bad fonts	different bytes entirely
`#️⃣️`	keycap emoji	`#` comment starter
Non-breaking space	a space	an identifier byte
`＄varname`	a variable	a parse error
`$️⃣varname`	a dollar sign with decoration	a different variable
Cyrillic `Rеquest`	`Request`	a completely separate class

The theme is consistent: PHP’s lexer is byte-precise, but human perception is not. The good news is that the same tooling that has always helped with readability, narrow columns, short methods, strict linters, CI enforcement, also helps catch these issues before they become vulnerabilities.

The post When PHP Reads Something Else: Visual Traps in Source Code appeared first on Exakat.

Governments may be large or small, and it may have several departements, ministries, cabinets or even local administrations with competing technologies. For this page, I only collected at least one PHP powered site.

The list has all 191 UN Member States + 1 UN Observer State, sorted alphabetically by English name. There are some Notes at the bottom, and an Methodology Annex with details about the methodology. This page might not get much update in the future, but a related repository php-in-the-world is ready to host updates and complements.

Note: some websites may not be available to you for various reasons.

PHP in every governments on the planet

Country	Government Website	PHP Technology / CMS
Albania	e-albania.al	Drupal / Symfony
Andorra	govern.ad	TYPO3
Angola	minfin.gov.ao	WordPress
Antigua and Barbuda	ab.gov.ag	Drupal
Argentina	argentina.gob.ar	Drupal
Armenia	gov.am	Custom PHP
Australia	australia.gov.au	Drupal
Austria	austria.gv.at	Drupal
Azerbaijan	gov.az	Drupal
Bahamas	bahamas.gov.bs	WordPress
Bahrain	bahrain.bh	Drupal
Bangladesh	bangladesh.gov.bd	WordPress
Barbados	gov.bb	WordPress
Belarus	belarus.by	Drupal
Belgium	belgium.be	Drupal
Belize	belize.gov.bz	WordPress
Benin	presidence.bj	WordPress
Bhutan	gov.bt	WordPress
Bolivia	bolivia.gob.bo	WordPress
Bosnia and Herzegovina	mvp.gov.ba	WordPress
Botswana	gov.bw	Drupal
Brazil	www2.camara.leg.br	Drupal
Brunei	gov.bn	WordPress
Bulgaria	government.bg	Symfony / Custom PHP
Burkina Faso	presidence.bf	SPIP
Burundi	presidence.bi	WordPress
Cabo Verde	gov.cv	Drupal
Cambodia	cambodia.gov.kh	Drupal
Cameroon	spm.gov.cm	Drupal
Canada	canada.ca	Drupal
Central African Republic	presidence.cf	WordPress
Chad	presidence.td	WordPress
Chile	gob.cl	Drupal
China	en.beijing.gov.cn	Drupal
Colombia	gov.co	Drupal
Comoros	presidence.km	WordPress
Congo (Brazzaville)	gouv.cg	Drupal
Congo (DR)	presidence.cd	WordPress
Costa Rica	gov.cr	Drupal
Croatia	vlada.gov.hr	Drupal
Cuba	minrex.gob.cu	Joomla
Cyprus	cyprus.gov.cy	Drupal
Czechia	vlada.gov.cz	Drupal
Côte d’Ivoire	gouv.ci	Drupal
Denmark	denmark.dk	Drupal
Djibouti	presidence.dj	WordPress
Dominica	dominica.dm	WordPress
Dominican Republic	dominicana.gob.do	Drupal
Ecuador	educacion.gob.ec	WordPress
Egypt	egypt.gov.eg	Drupal
El Salvador	presidencia.gob.sv	WordPress
Equatorial Guinea	presidencia-guinee.com	WordPress
Eritrea	shabait.com	WordPress
Estonia	valitsus.ee	Drupal
Eswatini	gov.sz	Drupal
Ethiopia	ethiopia.gov.et	WordPress
Fiji	fiji.gov.fj	WordPress
Finland	valtioneuvosto.fi	Drupal
France	service-public.fr	Symfony / Drupal
Gabon	gouv.ga	Drupal
Gambia	statehouse.gov.gm	WordPress
Georgia	gov.ge	Drupal
Germany	bundesregierung.de	TYPO3
Ghana	gov.gh	WordPress
Greece	gov.gr	Drupal
Grenada	gov.gd	WordPress
Guatemala	minex.gob.gt	WordPress
Guinea	presidence.gov.gn	WordPress
Guinea-Bissau	secom.gov.gw	WordPress
Guyana	minfor.gov.gy	WordPress
Haiti	presidence.ht	WordPress
Honduras	presidencia.hn	WordPress
Hungary	magyarorszag.hu	Drupal
Iceland	government.is	Drupal
India	india.gov.in	Drupal
Indonesia	setkab.go.id	WordPress
Iran	iran.ir	Joomla
Iraq	cabinet.gov.iq	Joomla
Ireland	gov.ie	Drupal
Israel	gov.il	Drupal
Italy	governo.it	Drupal
Jamaica	jis.gov.jm	WordPress
Japan	japan.go.jp	WordPress
Jordan	portal.jordan.gov.jo	Drupal
Kazakhstan	primeminister.kz	Drupal
Kenya	parliament.go.ke	WordPress
Kiribati	parliament.gov.ki	WordPress
Kuwait	kuwait.gov.kw	Drupal
Kyrgyzstan	gov.kg	Drupal
Laos	laogov.la	Joomla
Latvia	latvija.lv	Drupal
Lebanon	presidency.gov.lb	WordPress
Lesotho	gov.ls	WordPress
Liberia	mofa.gov.lr	WordPress
Libya	gov.ly	WordPress
Liechtenstein	llv.li	Drupal
Lithuania	lithuania.lt	Drupal
Luxembourg	luxembourg.lu	Drupal
Madagascar	presidence.gov.mg	WordPress
Malawi	malawi.gov.mw	WordPress
Malaysia	malaysia.gov.my	WordPress
Maldives	presidency.gov.mv	WordPress
Mali	malibo.org	Joomla
Malta	gov.mt	Drupal
Marshall Islands	rmigov.org	WordPress
Mauritania	primature.gov.mr	Drupal
Mauritius	govmu.org	WordPress
Mexico	gob.mx	Drupal
Micronesia	fsmgov.org	WordPress
Moldova	gov.md	Drupal
Monaco	en.gouv.mc	Drupal
Mongolia	pmis.gov.mn	Drupal
Montenegro	gov.me	Drupal
Morocco	maroc.ma	Drupal
Mozambique	portaldogoverno.gov.mz	Joomla
Myanmar	president-office.gov.mm	Drupal
Namibia	gov.na	Drupal
Nauru	nauru.gov.nr	WordPress
Nepal	nepal.gov.np	Joomla
Netherlands	government.nl	Drupal
New Zealand	govt.nz	SilverStripe CMS
Nicaragua	presidencia.gob.ni	WordPress
Niger	presidence.ne	WordPress
Nigeria	nigeria.gov.ng	WordPress
North Macedonia	vlada.mk	Joomla
Norway	regjeringen.no	Drupal
Oman	oman.om	Drupal
Pakistan	pakistan.gov.pk	Joomla
Palau	palaugov.org	WordPress
Palestine	palestinecabinet.gov.ps	WordPress
Panama	panama.gob.pa	Drupal
Papua New Guinea	png.gov.pg	WordPress
Paraguay	presidencia.gov.py	Drupal
Peru	gob.pe	Drupal
Philippines	gov.ph	WordPress
Poland	gov.pl	Drupal
Portugal	portugal.gov.pt	Drupal
Qatar	hukoomi.gov.qa	Drupal
Romania	gov.ro	Drupal
Russia	mos.ru	Drupal
Rwanda	gov.rw	Drupal
Saint Kitts and Nevis	gov.kn	WordPress
Saint Lucia	govt.lc	WordPress
Saint Vincent and the Grenadines	gov.vc	WordPress
Samoa	govt.ws	Drupal
San Marino	sanmarino.sm	Custom PHP
Saudi Arabia	my.gov.sa	Drupal
Senegal	presidence.sn	WordPress
Serbia	srbija.gov.rs	Drupal
Seychelles	statehouse.gov.sc	WordPress
Sierra Leone	statehouse.gov.sl	WordPress
Singapore	gov.sg	Drupal
Slovakia	slovensko.sk	Drupal
Slovenia	gov.si	Drupal
Solomon Islands	solomon.gov.sb	WordPress
Somalia	mfa.gov.so	WordPress
South Africa	gov.za	Drupal
South Korea	seoul.go.kr	Drupal
South Sudan	mfa.gov.ss	WordPress
Spain	moncloa.gob.es	Drupal
Sri Lanka	president.gov.lk	WordPress
Sudan	mofa.gov.sd	WordPress
Suriname	gov.sr	Drupal
Sweden	sweden.se	WordPress
Switzerland	admin.ch	Drupal
Syria	egov.sy	Joomla
São Tomé and Príncipe	saotome.st	WordPress
Tajikistan	parlament.tj	WordPress
Tanzania	statehouse.go.tz	WordPress
Thailand	thailand.go.th	WordPress
Timor-Leste	timor-leste.gov.tl	Drupal
Togo	presidence.tg	WordPress
Tonga	gov.to	WordPress
Trinidad and Tobago	ttconnect.gov.tt	Drupal
Tunisia	tunisie.gov.tn	Drupal
Turkmenistan	turkmenistan.gov.tm	Drupal
Tuvalu	gov.tv	WordPress
Türkiye	ktb.gov.tr	Drupal
Uganda	statehouse.go.ug	WordPress
Ukraine	kmu.gov.ua	Drupal
United Arab Emirates	u.ae	Drupal
United Kingdom	food.gov.uk	Drupal
United States	whitehouse.gov	WordPress
Uruguay	uruguay.gub.uy	Drupal
Uzbekistan	gov.uz	Custom PHP / Laravel
Vanuatu	gov.vu	WordPress
Venezuela	minci.gob.ve	WordPress
Vietnam	chinhphu.vn	Laravel / Custom PHP
Yemen	mofa-ye.org	WordPress
Zambia	statehouse.gov.zm	WordPress
Zimbabwe	gov.zw	WordPress

Named PHP Projects

The table above names these PHP frameworks and CMSs. It excludes generic “Custom PHP” entries, which aren’t a single named project:

Project	Home Page
Drupal	drupal.org
Joomla	joomla.org
Laravel	laravel.com
SilverStripe CMS	silverstripe.org
SPIP	spip.net
Symfony	symfony.com
TYPO3	typo3.org
WordPress	wordpress.org

Notes

Caribbean and Central American nations, Bahamas, Guatemala, Honduras, show a strong preference for WordPress, likely due to ease of use and lower maintenance costs for smaller IT departments.
China’s inclusion might seem surprising, since the central government in Beijing relies heavily on custom enterprise Java. But many municipal and provincial portals, including the English-language Beijing government site, utilize Drupal to handle multilingual content and international public relations.
Estonia is famous for its advanced digital society, called e-Governance. While much of its backend infrastructure is custom-built, its main government web portal uses Drupal for frontend content management.
European Microstates: Liechtenstein relies on Drupal, while Andorra uses TYPO3, sharing a tech affinity with Switzerland and Germany. Monaco’s official portal is a beautifully executed Drupal site.
Francophone Africa is heavily represented by WordPress. Countries like Benin, Burundi, DR Congo, Djibouti, and Haiti all rely on it for their presidential portals, valuing rapid deployment, easy content updates, and low hosting overhead.
Israel’s single unified government portal is a major Drupal implementation, handling millions of interactions and integrating with their “Tofes Yarok” (Green Pass) systems during the pandemic.
Japan and Malaysia are great examples of major Asian governments utilizing WordPress VIP or heavily customized WordPress enterprise setups for their primary portals.
Joomla is less common than Drupal or WordPress for large federal portals, but remains in active or legacy use across the Middle East, North Africa, and parts of Asia, Iran, Pakistan, Iraq, Mozambique, Laos, and Syria all run government or e-government portals on it, often valued for its strong out-of-the-box multilingual support. Cuba and Nepal are further examples, in more budget-conscious or historically isolated tech environments.
Laravel in Vietnam: the main government portal utilizes Laravel, a robust PHP framework. This shows that governments don’t just use “out-of-the-box” CMSs, some build highly customized, bespoke applications using modern PHP frameworks.
The Middle East has heavily embraced Drupal. Qatar’s “Hukoomi” portal and Saudi Arabia’s “My.gov.sa” are massive, highly customized Drupal implementations serving millions of citizens and expats in multiple languages.
Oman stands out in the Gulf region. While many of its neighbors use custom enterprise Java or .NET setups, Oman’s central portal has heavily leveraged Drupal to manage its massive digital transformation and Arabic/English content.
The post-Soviet sphere (Belarus, Kazakhstan, Kyrgyzstan) shows a strong trend of utilizing Drupal for e-government modernization, favoring its ability to handle Cyrillic alphabets and complex user permissions securely.
Russia’s capital city, Moscow, runs one of the largest and most complex Drupal installations in the world. mos.ru handles tens of millions of users and integrates hundreds of city services: a premier example of enterprise-level PHP at massive scale.
Rwanda continues its reputation as a tech-forward African nation by running its main portal on Drupal, aligning with its national strategy to digitize government services.
San Marino uses a custom PHP setup for its official portal, proving that smaller European microstates often rely on bespoke PHP applications tailored to their specific administrative needs rather than off-the-shelf CMSs.
The shift towards Drupal across Eastern Europe (Czechia, Latvia, Lithuania, Romania, Slovakia) is particularly strong due to its native support for multilingual content and complex user role management.
Small Island Developing States (SIDS) across the Caribbean and Pacific, with Grenada, São Tomé and Príncipe, Guyana, Marshall Islands, Micronesia, Nauru, Palau, Samoa, Solomon Islands, Tuvalu, Tonga, Vanuatu, and Saint Vincent and the Grenadines, overwhelmingly favor WordPress and Drupal. Both platforms let small IT departments deploy modern, secure government sites without needing large in-house development or server teams.
Singapore is a fantastic example of a highly developed, secure digital government portal running on Drupal.
South Korea might seem like an unusual entry, since the central government often relies on custom Java-based platforms. However, local and major municipal portals, like the Seoul Metropolitan Government, heavily utilize Drupal for their public-facing websites, particularly for their multilingual expat portals.
SPIP powers Burkina Faso: the presidency site uses this highly respected PHP CMS, originally created in France. It has historically been very popular in Francophone Africa for its multilingual and structural capabilities, though many sites are now migrating to WordPress or Drupal.
Sweden’s official informational portal runs on WordPress, demonstrating how different branches of a government, informational vs. administrative, might use different stacks.
Türkiye: the linked site is the Ministry of Culture and Tourism. Many Turkish government ministries rely on Drupal, though some specific e-service gateways use custom or .NET backends.
Ukraine is a massive success story for Drupal. Despite the ongoing war, their highly robust Drupal-based government portal has remained online and functional, showcasing the CMS’s resilience and decentralized capabilities.
Uzbekistan is a standout, utilizing a custom Laravel backend for gov.uz. Laravel is increasingly popular for bespoke government applications that need highly specific API integrations and business logic that a traditional CMS might not handle gracefully out-of-the-box.

Methodology and Caveats

The country list is based on current UN member states, plus Palestine as a UN observer state.

For each country, sites were searched roughly in this order, stopping once a PHP-powered site was found:

The main government portal (e.g. a .gov / .gob / .gouv domain, or an official national portal).
The presidency site, or equivalent head-of-state site, where the main portal wasn’t a good match.
The prime minister’s office and the Ministry of Foreign Affairs.
Major city or capital-city government sites, for countries where no suitable national-level PHP site was found.

Government tech stacks are occasionally migrated, and the sites listed above are historically or currently powered by PHP-based frameworks/CMSs (such as Drupal, WordPress, TYPO3, SilverStripe, SPIP, Symfony, or Laravel).

These sites change fast, and availability is not guaranteed: government domains can go offline, get redesigned onto a different stack, or become unreachable for stretches of time: particularly around elections, coups, sanctions, or armed conflict. Treat this list as a snapshot, not a live status check.

This list has a related repository called php-in-the-world, that can accept more insights, domains and recept updates.

The post PHP-Powered Government Websites by Country appeared first on Exakat.

The Evolution of WSL Support in JetBrains IDEs - PhpStorm : The IDE that empowers PHP developers | The JetBrains Blog

2026-09-09T10:39:49.000Z

JetBrains IDEs have worked with WSL for many years, and over time, several ways of using it have emerged across our products. Depending on the entry point, the IDE could rely on a different underlying architecture, leading to a different experience.

Starting with the 2026.2 release, there is one recommended entry point. In IntelliJ IDEA, WebStorm, and PhpStorm, opening a project that lives in WSL runs the IDE in what we call Native mode. The IDE stays a Windows application, while a small agent inside WSL handles files and processes on its behalf.

Below is how Native mode works, how our approach to WSL integration evolved to get here, and – since we tried three other approaches first – why we’re confident it’s the right foundation for your work.

What it takes to support WSL in an IDE

We’ll start with an idealized picture in which the IDE functions seamlessly inside WSL while being operated from Windows. In practical terms, “seamlessly” means you should be able to use any of the IDE’s capabilities – terminal, run and debug configurations, profiling, etc. – against a project that resides in a Linux environment. Not only that, but this must incur as little latency as possible for the coding experience to feel quick and natural, as if the project files and the IDE itself resided in a single operating-system environment.

We’ll trace how this challenge has been addressed, beginning with the earliest implementation, in which the IDE interacted with WSL through the 9P transport protocol. We will then cover Remote Development and WSLg before examining Native mode – the currently preferred mode for how IDEs work with WSL.

Toward native IDE execution in WSL

9P filesystem access and GeneralCommandLine

For the IDE to function, it needs access to the basics of a project, which are plain files. This is where the 9P filesystem protocol comes in. It provides the mechanism that allows Windows-side processes access files inside WSL. In practice, project-related file I/O performed by the IDE – scanning, indexing, archive access, and similar operations – is routed through the 9P-based filesystem layer to the Linux virtual machine.

Once file access is accounted for, the next challenge is process execution. While running on Windows, the IDE must be able to invoke tools inside WSL with the correct Linux paths, working directories, executables, environment variables, and arguments. The IDE-internal GeneralCommandLine class manages this by normalizing command execution in the WSL environment.

While this architecture enables the IDE to operate against WSL, it introduces significant trade-offs in both file access and process execution.

The 9P protocol is known to be problematic for several reasons:

Limited symlink handling – 9P does not properly expose Linux symbolic links to Windows through \\wsl$. As a result, the IDE may detect an entry but be unable to resolve or index the linked directory tree. This affects pnpm workspaces, Python virtual environments, PHP Composer path repositories, and other environments that rely on symlinks.
Microsoft Defender scans – on-access scanning over 9P can stretch WSL file reads by tens of seconds.
Latency and degraded throughput – 9P-backed filesystem access adds latency, and throughput can degrade significantly, especially in workflows involving many small files. Core IDE operations such as indexing follow this pattern, generating numerous separate requests that cross the Windows/WSL VM boundary through 9P.

The situation was no less challenging on the GeneralCommandLine side. The pipeline added a maintenance burden, as developers had to account for WSL-specific execution semantics across the codebase.

As a consequence, the approach became increasingly difficult to scale and maintain, and it surfaced persistent issues with symlink handling and performance.

Running the IDE inside WSL with WSLg

What if, instead, the IDE itself resided inside WSL, close to the project it works with? This is where WSLg comes in. It provides a way to run Linux GUI applications whose visual output is integrated directly into the Windows desktop.

Here’s why we do not recommend the WSLg approach:

From a product perspective, if the IDE is displayed on Windows, it is preferable for it to behave as a Windows-native application rather than as a Linux GUI application projected into the Windows desktop. This preserves greater control over the IDE experience and avoids dependence on an additional GUI-remoting layer.
In a WSLg setup, the IDE may run on the native Wayland path, where JetBrains Runtime uses WLToolkit against WSLg’s Wayland compositor. This path carries known limitations in rendering, popups, window management, input methods, and desktop integration.

No first-class product experience was ever built around this setup. Although running the IDE through WSLg is technically viable, it has never been considered the preferred direction, and no dedicated out-of-the-box installation or onboarding flow was provided. It remains an ad hoc workaround rather than a supported IDE workflow.

The Remote Development approach

Another approach was Remote Development, which addressed the same fundamental challenges of file access and process execution from a different angle. Rather than extending the Windows-based IDE across the WSL boundary, it moved the IDE backend into WSL and kept only the client on Windows. This architecture solved the underlying integration problems more directly, but introduced a different set of trade-offs.

The main technical challenge of this configuration is establishing and maintaining communication between them while ensuring that the UI accurately reflects user actions and the IDE continues to function as a coherent whole. At the same time, placing the backend inside WSL provides the clear advantage of direct access to Linux files and processes.

In this setup, the two IDE parts communicate over the JetBrains RD protocol. The protocol is a structured, bidirectional stream of IDE models and events that keeps the thin client and the backend IDE logically in sync, while all heavy work, such as indexing, analysis, builds, debugging, VCS operations, and so on, happens on the backend.

The client, in its turn:

Renders all windows and editors, and handles user input.
Mirrors the project and editor state it receives from the backend over the RD protocol, and sends back edits, caret moves, refactoring commands, debug actions, and so on.
Loads UI-level plugins.

The elephant in the room, however, is the cost of this split architecture. The IDE backend is a heavyweight component in its own right, requiring roughly 2 GB of additional disk space and time to download and install inside WSL. The split also introduces an inherent performance penalty, as UI-event state, user input, and other interaction data must travel continuously between the local client and the backend.

It also adds development overhead, as the code has to be split into client and server parts. Leaving specific modules undivided can cause delays and freezes in highly dynamic UIs. The associated engineering effort therefore becomes a constant and unavoidable cost.

Native mode and the IJent agent

The current design – now integrated into most of our IDEs – represents the culmination of this work and addresses many of the shortcomings of earlier approaches to WSL.

To provide access to the Linux filesystem, processes, and other environment resources without relying on 9P, GeneralCommandLine, or other second-class communication mechanisms, we developed a small agent named IJent. Because it is designed specifically for IDE scenarios, we can shape its behavior, protocol, and capabilities according to our requirements.

Together, the IDE and IJent form a client–server pair. This may resemble the Remote Development model, but the server component is much thinner and, at the same time, more versatile. Installing IJent into a WSL environment is merely one of several possible configurations; the same model can also apply to Docker and Dev Containers.

By choosing this particular technology stack, we address a broad set of concerns:

Rust implementation – Rust keeps the executable slim. By avoiding Java/Kotlin for the agent, we eliminate additional runtime dependencies inside containers or WSL.
Transport layer – Stdio gives us a portable, firewall-friendly transport across all environments. Hyper-V sockets on WSL offer a faster path, which is especially beneficial for large or numerous filesystem transfers.
Correct filesystem semantics – IJent executes filesystem operations on behalf of the IDE inside the target environment. As a result, path resolution, including symbolic links, follows correct Linux semantics rather than being mediated through 9P. Third-party plugins also benefit from this model, since their file operations are routed through IJent.

EelApi: one interface for any environment

For the IDE to fully benefit from IJent, changes on the IDE side are also required. Enter EelAPI.

EelApi is an API designed to abstract away the distinction between local and remote environments for everyone writing IDE-related code – plugin authors and platform contributors alike. With EelApi, the underlying environment against which the IDE operates should no longer matter, removing the need to account for these concerns explicitly in code. In this sense, EelApi is platform-agnostic, and the IDE can remain unaware of whether it is working locally, in WSL, in Docker, or in a Dev Container.

In general, IJent implements the EelApi interface, providing the actual functionality that EelApi exposes to the IDE and plugins.

If you’re interested in a more detailed explanation of EelApi, together with a practical introduction to the topic, head over to the article The Dev Containers Story: Introducing EelApi for Plugin Authors.

What this means in practice

There are two ways to open a WSL project today:

Opening the project directly gives you Native mode in IntelliJ IDEA, WebStorm, and PhpStorm, and more IDEs are adopting the IJent and EelApi architecture as we speak.
The Remote Development entry point on the Welcome screen still works, but it is no longer the recommended way to open a WSL project.

We conducted performance tests in order to compare 9P mode and Native mode. The results show a clear performance gain in favor of the new approach:

Cold-open benchmark

IJent cuts 38% off the wait for a large WSL project

9P IJent

Ready to work

18.5 s

11.5 s

38% less

Scan project tree

8.1 s

3.7 s

54% less

Index files

10.8 s

8.4 s

22% less

Read file content

12.2 s

5.7 s

53% less

Where this applies: A cold first open of spring-framework, with 23 subprojects and 8,191 source files. A small project with few source files showed no measurable difference.

Test setup: Median of five measured runs on Windows 11 with WSL 2, Ubuntu 24.04, and IntelliJ IDEA Ultimate 263.SNAPSHOT.

Beyond performance, this architecture places development in WSL within the broader context of development in non-local environments, allowing them to be approached through the same underlying model. The same IJent agent already backs our work on Docker and Dev Containers.

Thank you for reading and for all the feedback that helped us reach this point. Tell us how Native mode holds up against your projects in the comments below.

Generate an image of a stereotypical PHP developer - Exakat

2026-09-08T08:43:06.000Z

Generate an image of a stereotypical PHP developer

That was a popular toot on Bluesky, by Justin Jackson.

I thought it would be interesting to make it again, in 2026, so here we go.

ChatGPT in 2024

The original image, below, was produced on ChatGPT. It is a cartoon, with quite a number of references to IRL memes: I PHP, the laptop, the cables and the coffee. The beard is already here.

ChatGPT in 2026

Same prompt in 2026, and we get the same vibe (no pun intended). I PHP is gone, but coffee and laptops are still here. It is also a graphic picture, rather than a cartoon.

“It works on my machine” meme appears, along with a todo list and books: they are actual titles!

Also, why is the screen behind the developer?

Note the poor elephpant, which is both an actual plush toy and has the PHP logo tattooed on its face!

Logos for PHP 8, Composer, Symfony and Laravel, with mentions of Docker, Linux, HTML, and Git. No comb in sight.

Gemini

Gemini also goes with a realistic picture, and a much more sanitized work environment. The developer is still on their laptop, but now correctly facing the screens. The book is used, and it looks like an old one, indeed.

Here, no more PHP elephpant, but Mario and Zelda. So much for the enterprise space…

Grok

The world is very gloomy with Grok. Errors and bugs, and despair in the eyes. Again, lots of books, with related technologies such as HTML, JavaScript.

No more laptop, but screens and coffee.

Claude

Low effort from Claude, but it provided some explanations, leaving us to finish the job with our imagination.

“The joke is affectionate and aimed at the language’s reputation rather than at anyone in particular: the elePHPant plushie, mysql_query that should have been replaced fifteen years ago, and a TODO comment nobody has touched since 2009.

Worth saying that the stereotype is well out of date. Modern PHP has typed properties, JIT compilation, and frameworks like Laravel and Symfony that look nothing like the tangled 2009 code on that screen. Happy to redraw it as the “PHP 8 developer” version if you want the contrast.”

Lumo

Lumo, from Protonmail, made the developer a lot younger than the previous pictures. He is without a beard, but he features a classic three hand posture.

The code on the screen is very indented, and this time, the coffee mug does not say it loves PHP.

Mistral

Mistral went also for the clean cartoon style. Here, we find the longest beard of all, and many, many PHP words. The keyboard is finally a real one, though it might be an ergonomic (or not) one.

Glasses and coffee are a constant.

The last try was to set a context for the picture, and I went… medieval. This works well: no screen, books, keyboard, glasses, or coffee in sight.

But still, this beard…

More sterotypical PHP developers?

I tried some other LLM, such as z.ai, and deepseek.com, which have no image generation in the chat.

Could you generate other PHP developers pictures? Share them

The post Generate an image of a stereotypical PHP developer appeared first on Exakat.

13 Modern PHP Tips & Tricks from 2015 - Exakat

2026-09-07T20:04:14.000Z

13 Modern PHP Tips & Tricks from 2015

PHP has undergone a massive transformation over the last decade. If you’re still writing PHP like it’s 2015, you’re missing out on massive performance gains, cleaner syntax, and better security.

I ran into a nice blog post 13 PHP Tips That Make Development Faster from Linet M. that covered tips for PHP of that era: that was PHP 7.0 at that time. It is interesting to discover the way we have covered since that moment, so I read the whole piece. That was really good, and it also showed a bit of age. Probably like myself anyway.

Let’s take a modern look at the tips that still matter in 2026, the ones you need to forget, and the new tricks you should be using today.

🗑️ The “Dead and Buried” Tips

Before we get to the good stuff, let’s clear out the obsolete advice from older blog posts:

“Use single quotes instead of double quotes for performance”. Modern PHP engines parse both equally fast. Use double quotes for string interpolation ("Hello {$name}") and single quotes when you don’t need interpolation. Readability matters more than micro-optimizations.
“Use echo instead of print“. First, nobody is using print anymore anyway, and the performance difference is non-existent in PHP 8.x.
“Avoid require_once because it’s slow”. Everyone use Composer and PSR-4 autoloading for classes now, so manual require/require_once for classes is indeed obsolete — though bootstrap files and front controllers still require things on purpose, even in fully Composer-driven apps.
“Pre-increment ++$i is faster than $i++“. The PHP engine optimized this years ago. Use whichever makes sense in terms of readability.
“Suppress errors with @“. This one is actually harmful. Never do this, or in well monitored situations. Modern PHP prefers typed errors and exceptions over a silenced failure (though not everything became an exception in PHP 8 — plenty of E_WARNING/E_DEPRECATED notices still exist the old-fashioned way). Suppressing errors hides bugs and makes debugging a nightmare.

✅ The Modern, Updated PHP Tips

The numbers is the reference in the original article.

1. Always Use Strict Types

In 2026, loosely typed PHP is a thing of the past. Always declare strict_types at the very top of your PHP files. This forces PHP to enforce the types you declare in function signatures, preventing sneaky bugs caused by automatic type coercion.

2. Use `===` for Strict Comparison

This was true a decade ago, and it’s true today. Use === to check both value and type. PHP’s == (a.k.a. relaxed comparison) still has weird edge cases — null == false is still true, for one. The classic 0 == "a" example, though, is no longer one of them: since PHP 8.0’s “saner string to number comparisons”, a number is compared against a non-numeric string as a string, so 0 == "a" is false today. That old chestnut belongs in the “dead and buried” pile above, not here — but the edge cases that remain are reason enough to keep using === and not leave it to chance.

3. Leverage the Nullsafe Operator (`?->`)

Stop writing deeply nested if statements just to check if an object property exists. The nullsafe operator allows you to chain method calls or property accesses. If any part of the chain evaluates to null, the entire chain short-circuits and returns null safely.

getAddress();
    if ($address !== null) {
        $country = $address->getCountry();
    }
}

// 2026 way (clean)
$country = $user?->getAddress()?->getCountry();
?>

4. Use Enums Instead of “Magic Strings”

Before PHP 8.1, developers used constants or “magic strings” to represent states. Now, use Enums — or, as here, a backed enum when each case needs a scalar value attached. They are type-safe, readable, and prevent typos.

5. Use `match` Instead of `switch`

The switch statement is verbose and prone to bugs, like forgetting a break. The match expression is shorter, uses strict comparison ===, returns a value directly, and throws an error if no condition is met.

 'User is active',
    'inactive' => 'User is inactive',
    default => 'Unknown',
};
?>

6. Stop Counting in Loops

This tip survived the update amd it is worth repeating: Do not put function calls inside loop conditions.

7. Use `str_contains`, `str_starts_with`, and `str_ends_with`

Stop using strpos() !== false to check if a string exists within another string. PHP 8 gave us dedicated, highly readable functions for this, starting with str_contains().

8. Use Readonly Properties and Classes

Immutability is key to bug-free code. Use the readonly keyword for class properties that should only be initialized once. This is especially useful for Data Transfer Objects (DTOs) and value objects.

name = 'Bob'; // Throws an Error! Cannot modify readonly property.
?>

9. Take Advantage of Property Hooks

If you are using PHP 8.4 or newer, you no longer need to write verbose getters and setter methods for every property. Property hooksallow you to inline access logic directly in the property declaration.

 strtoupper($this->name);
        set => $value;
    }
}
?>

10. Use Named Arguments

You no longer need to pass null for optional parameters just to reach the one you actually want to change. Named arguments allow you to pass values by their parameter name — the real name from the signature, mind you, or PHP throws Unknown named parameter.

(The original draft named that third parameter expires_or_options — a plausible-looking guess, but setcookie()‘s actual parameter is $expires; the array-based overload’s parameter is $options, not a portmanteau of the two.)

11. Use PDO with Prepared Statements

The golden rule of database interactions hasn’t changed: Never put user input directly into an SQL query. SQL injection is still the #1 web vulnerability. Always use PDO (or a modern ORM like Eloquent/Doctrine) with prepared statements.

prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(['email' => $userInput]);
?>

You might also consider going one step further with an ORM. But that might be overkill for a PHP tips.

12. Use Arrow Functions for Simple Closures

Writing multi-line function() use ($var) closures is clunky for simple array operations. Arrow functions (fn()) automatically capture variables by value and allow one-line expressions.

 $n * $factor, $numbers);
?>

13. Rely on OPcache and JIT

Instead of spending hours trying to optimize string concatenation or array syntax, ensure your production server has OPcache enabled. Furthermore, if you are running CPU-heavy applications, like math processing or image manipulation, enable JIT (Just-In-Time) compilation in your php.ini. This compiles PHP code into native machine code — worth knowing, though, that the “massive performance boosts” mostly show up on CPU-bound, numeric workloads; a typical request-response web app spends most of its time waiting on a database or the network, so don’t expect JIT alone to rescue a slow endpoint. It’s OPcache, not JIT, that does the heavy lifting for ordinary apps. Either way, both make old-school micro-optimizations irrelevant.

What a decade did to this list

Going through it line by line, what strikes me most isn’t the new tips that appeared: it’s how little needed fixing at all. Thirteen tips, written for a PHP that was still years away from union types, enums, or a JIT, and eleven of them read today exactly as they did then, no asterisk required. === over ==, prepared statements over string concatenation, don’t call count() from inside a loop condition: these aren’t PHP 7 tips that happened to survive, they’re just good engineering advice that PHP’s version number was never going to change. That kind of stability is rare, and it says something about the original instinct for which parts of a “tips” article age like the language and which parts age like a haircut.

The post 13 Modern PHP Tips & Tricks from 2015 appeared first on Exakat.

Rebuilding Taipan! with an AI Pair Programmer in PHP - Exakat

2026-09-06T17:01:43.000Z

Rebuilding Taipan! with an AI Pair Programmer in PHP

Taipan! was one of the games that hooked me on computers. My brother and I would play it on the Apple ][c bitmap font and the original’s line-drawing art still aren’t ported: a reminder that “faithful clone” has a visual dimension too, and it’s the one still outstanding.

Dogfooding as the real division of labor

The pattern that emerged: AI was fast and reliable at mechanical porting: reconciling sources, adding a new mechanic once specified, keeping the implementation clean enough to sail through static analysis at the strictest settings. What it couldn’t do was tell me the pirate encounter rate felt wrong, or that a status line was truncating, or that a fight was tedious rather than tense. That took playing.

This is dogfooding in miniature, and it’s a discipline that professional teams already know the value of. Using your own product is one of the most reliable ways to surface the problems a spec review never will. What this project made obvious is how much more that matters once AI is doing a large share of the implementation. The bottleneck didn’t disappear, it moved: from writing the code to actually using the thing you built.

Playing as work

There’s a strange side effect to using play as your QA process: at some point, finding a bug stops being a happy accident and starts being the point of the session. You end up running two modes at once. Playing to enjoy the game, and playing to break it. And those two modes aim at different targets. That’s a slightly schizophrenic way to spend an evening with a game you loved as a kid, and it’s worth naming as a real cost of this workflow, not just a funny anecdote.

Where this could go with Taipan! 2026 on PHP?

Where could this go next? First, it is playable, so get your PHP, clone the repository and run php bin/taipan. Have fun! Report bugs, submit PR, etc.

Some of it is easy and mostly cosmetic: more goods, or different ones to avoid explaining that Opium is the best good to trade at the next family dinner, more ports, more flavor, larger warehouses. I actually added a feature where the Hong Kong shipbuilding company offers to upgrade the warehouse by 10000 more unit. I can now buy enough Silk to have the entire production since prehistory in my warehouse. And sell it next month.

Some of it is more ambitious: a networked version where several Taipans trade in the same world at once, or an economy with real constraints instead of infinite cargo moving between randomly fluctuating prices. It is quite astounding to realize that the whole mechanics of the game was built on random numbers: for prices, for events, etc. Not a single real life impact of flooding a city with enough Arms to start a revolution.

There’s probably real room in the market for games in this register: simple, old-school shapes, but richer and more modern underneath than what 1982 hardware could support. Taipan! was built around the constraints of its era. Rebuilding it in 2026 is a chance to ask which of those constraints were the game, and which were just the Apple II.

The post Rebuilding Taipan! with an AI Pair Programmer in PHP appeared first on Exakat.

Post on Exakat - Exakat

2026-09-04T10:08:48.000Z

I Have a Dream of a PHP Preprocessor

What if PHP could be faster, stricter, and more expressive, without waiting for PHP 9? What if we could preprocess PHP code into something more optimized, more elegant, or even a completely new dialect? The name itself hints at the possibility: PHP: Hypertext Preprocessor. But here, we’re imagining a preprocessor for PHP itself.

This is the dream of the PHP preprocessor: a tool to transform PHP code before execution, adding macros, type safety, or even a new syntax. The idea is to automate tightening at the source code level, so developers don’t have to do it manually. Over the years, at least five brave souls tried, and almost succeeded, in making this happen. Their attempts may not have changed the world, but they proved that innovation is always worth pursuing.

Let’s take a whimsical tour of their journeys, with real examples of what they aimed to achieve and where they ran into truly difficult problems. Then, let’s gaze into the crystal ball: what would a PHP preprocessor look like today?

Attempt #1: PHP-preprocessor by gizmore

Goal: Create a preprocessor that adds macros, compile-time evaluation, and even a new syntax layer to PHP.

Gizmore’s php-preprocessor, or PP, was an ambitious attempt to give PHP compile-time superpowers. It promised:

Macros for repetitive code blocks.
Compile-time evaluation of expressions.
A custom syntax for easier metaprogramming.

For example, imagine writing a macro to auto-generate getters and setters:

This would be transformed into:

name; }
    public function setName(string $name): void { $this->name = $name; }
    // ... and so on for each property
}
?>

The idea was to reduce boilerplate and make PHP feel more like a language with first-class metaprogramming. However, PHP’s dynamic nature made it hard to predict macro behavior: static analysis could be bypassed at runtime. The tool remained a fascinating experiment.

Attempt #2: PHP Preprocessor by ircmaxell

Goal: Create a preprocessor that adds compile-time optimizations, strict typing, and better error messages.

In 2016, ircmaxell’s PHP Preprocessor aimed to make PHP faster and safer by preprocessing code into optimized, strictly-typed versions. The goals included:

Enforcing types at compile time (e.g., ensuring a function only accepts integers).
Optimizing loops and function calls based on static analysis.
Adding better error messages for common mistakes.

For example:

The preprocessor caught the error before runtime, making PHP feel more like a statically-typed language. Ultimately, the complexity of integrating this into existing PHP 7 projects proved to be a major hurdle.

Attempt #3: PHP Plus by stevenkellow

Goal: Create a stricter, more modern dialect of PHP, with better type handling and syntax.

PHP Plus was designed as a stricter, more modern version of PHP. It introduced:

Stricter type coercion for better predictability.
A new syntax for arrays and objects.
Better error handling for undefined variables.

For example, PHP Plus aimed to allow:

And for functions:

The project started in 2016, and version 2 was released in the last days of August 2026. It may be time to take a closer look.

Attempt #4: PHP+ Proposal (InfoWorld, 2011)

Goal: Create a new, stricter dialect of PHP called PHP++. In 2011.

InfoWorld’s 2011 article proposed PHP+ (or PHP++) as a stricter dialect, with: – Stricter type checking(no more silent type juggling). – A cleaner syntax for arrays and strings. – Better error handling for undefined variables and functions.

For example, PHP+ would:

And:

The proposal was bold at the time of writing, and it remained mostly a thought experiment. It included early assessments from Zeev Suraski about feasibility and ended without support from the PHP Group. Interestingly, many of its ideas were later adopted in PHP 7 and 8: strict operators, typed variables, and more.

Again, being stricter about coding is an important aspect of a preprocessor.

Attempt #5: Plus-1 by Nuno Maduro

Goal: A preprocessing tool that adds modern features (like arrow functions, typed properties) to older PHP versions.

Nuno Maduro’s Plus-1 was a transpiler for older PHP versions. It aimed to: – Add arrow functions to PHP 5.6+. – Support typed properties before PHP 7.4. – Enable modern syntax for older projects.

For example, you could write:php $getUsers = fn(array $filters) => User::where($filters)->get(); And have it automatically transformed into:php function ($filters) { return User::where($filters)->get(); } Plus-1 was a pragmatic way to bridge the gap between PHP versions: use modern PHP syntax on older PHP versions and transpile it to the target version. PHP’s rapid evolution made it obsolete.

There might also be a philosophical argument: instead of adapting modern PHP features to older engines, why not adapt older codebases to modern PHP features? That would help with PHP migration toward newer versions. That might be a consideration when preparing new PHP versions: what abandoned PHP features from previous versions can be transpiled to a new PHP version?

So… What’s Relevant Today?

All five attempts eventually stopped. It’s not a failure, though there are no actual successes either. They didn’t stop because the idea was bad. They stopped because PHP itself evolved. The PHP core team added many of the features these tools aimed to provide: strict typing, arrow functions, typed properties, and even JIT compilation.

So, why build a preprocessor in 2026? What is left to experiment with?

Because innovation isn’t about winning: it’s about experimenting.

A modern PHP preprocessor in 2026 could focus on:

Generics: Of course. This feature is still in high demand for PHP. With a preprocessor, you could simulate them today. And then, you could go further with dependent types.
Simplicity: Making PHP more like its early, forgiving self, even in stricter contexts. You have a better view of what should and shouldn’t be done: can we encode that in the syntax?
Leaner and fitter: Reduce boilerplate by offloading it to the preprocessor. No need to write getters, setters, and withers: one attribute and let the engine produce it. Less code for you to read, and for AI too!
Extra strict: You like strict code? Go all in with mathematically provable code that cannot fail, right from the start. It might go against business rules that need to be flexible and sometimes fuzzy, so where is the middle ground?
Validation: Try new approaches before they get an RFC and into the language itself, like experimental syntax, macros, or standardization of function names (str_len() and str_join(), anyone?). Just compare PHP to other languages and bring in more ideas!
Operators: Add more operators with strange Unicode symbols (≣ ≩ ≶ ⊂ ⊗ ⊞), include imaginary numbers, tetration, Roman numerals, and quaternions… OK, you get the point.

The Lesson: Innovation is Always Worth It

The attempts to build a PHP preprocessor may have faded into history, but their spirit of experimentation lives on. Innovation isn’t about creating the next big thing; it’s about pushing boundaries, trying new ideas, and learning from failure. Sometimes, you have to learn what you can’tdo, because what’s left is what you can do.

The post appeared first on Exakat.

This post explores two distinct ways PHP and tree-sitter interact. Both pull in opposite directions.

From Rust, parsing PHP: building fast PHP developer tools in Rust, with tree-sitter doing the heavy lifting of understanding PHP source code.
From PHP, parsing everything else: using tree-sitter as a library inside PHP to parse other languages such as JavaScript, Python, JSON, or any of the 100+ supported languages.

Building PHP Tools in Rust with Tree-sitter

Why Rust?

PHP’s ecosystem of static analysis, linting, and code formatting tools is mature, but it has a structural problem: they run on the PHP runtime itself. A large scan can take tens of seconds. Sometimes, developers reach for --parallel flags just to get bearable CI times.

Rust sidesteps the issue entirely. A native binary has no interpreter startup, no garbage collector pauses, and can spread work across all available cores without coordinating through a VM. The only thing still needed is a way to understand PHP code: that is exactly what the tree-sitter-phpcrate provides.

The `tree-sitter-php` crate

The official grammar lives at tree-sitter/tree-sitter-php. It ships bindings for Node.js, Python, Go, Swift and Rust via crates.io/crates/tree-sitter-php.

In Rust, integrating it is minimal:

use tree_sitter::Parser;fn main() {
let mut parser = Parser::new();
parser.set_language(&tree_sitter_php::LANGUAGE_PHP.into()).unwrap();let source = r#""#;
let tree = parser.parse(source, None).unwrap();
let root = tree.root_node();println!("{}", root.to_sexp()); // prints the S-expression CST
}

The resulting tree contains every token, including whitespace and comments: useful for a formatter that must be lossless.

Mago: The Flagship Example

The most ambitious PHP tool currently built on this stack is Mago, by Carthage Software.

Mago is a full PHP toolchain in a single Rust binary: linter, formatter, static analyzer, and architectural guard. Its feature surface overlaps with PHPStan, Psalm, PHP-CS-Fixer, exakat and PHPCS: all at once, without having to run four separate PHP processes, and in a fraction of the execution time. Just make sure your favorite rule is actually included.

The performance numbers are striking. On a 500 files project, mago check completes in under a second. PHPCS on the same project takes 8–12 seconds. On a 2400 files project the gap widens to 30 or 40 times.

Mago does not use tree-sitter directly for its deepest analysis: it ships its own handwritten fault-tolerant parser for more control over error recovery. This demonstrates exactly the category of tool that tree-sitter enables: fast, multi-pass PHP analysis written entirely outside the PHP runtime.

Interestingly, Mago is now in its version 1.4 (August 2026), with versions coming out every other week. Quite impressive for a new tool.

ast-grep: Structural Search Across 100+ Languages

ast-grep, or sg for the initiated, is a Rust CLI that uses tree-sitter to power structural code search and rewriting. Think grep, but pattern-matched against the AST rather than raw text.

# Find every call to shell_exec() in a PHP codebase
sg --lang php -p 'shell_exec($CMD)'

Because the pattern matches the tree, it finds the call regardless of whitespace, line breaks, or irrelevant surrounding tokens. It supports over 26 languages out of the box, PHP included, making it a practical replacement for fragile regex-based code searches in CI pipelines.

php-rust-tools/parser

Worth mentioning: php-rust-tools/parser is a handwritten, fault-tolerant, recursive-descent PHP parser in Rust. It is not a tree-sitter dependency. It is the foundation for several emerging Rust-based PHP tools and offers finer-grained control over error recovery than a grammar-generated parser. Not tree-sitter, but part of the same wave of Rust-native PHP tooling.

Using Tree-sitter from Within PHP

The reverse direction is less obvious but equally interesting: bring tree-sitter into PHP as an extension, and use it to parse other languages from PHP code.

Why Would You Want This?

Build a custom linter for a domain-specific language without leaving PHP
Analyze JavaScript, TypeScript, or Python files from a PHP application
Extract function signatures, imports, or dependency graphs from a polyglot codebase
Write automated codemods that operate on non-PHP source files
Write a transpiler that convert languages to PHP source code

The most useful feature is to write a custom linter: tree-sitter can work from manual written grammar, that you can tailor to your format needs. From the grammar, the engine gets the tree for you.

PHP’s own tokenizer token_get_all only speaks PHP. Tree-sitter speaks everything. Why not build static analysis tools for other languages in PHP? After all, static analysis tools for PHP in other languages do exist.

tree-sitter-language-pack: Batteries-Included, Polyglot

The most complete option is xberg-io/tree-sitter-language-pack, a native PHP extension, built in Rust via ext-php-rs, not hand-written C, that ships pre-compiled grammars for 371 languages (PHP, HTML, CSS, JavaScript/JSX, TypeScript/TSX, JSON, Python, F#, R, Fortran, …) behind an API shared with the project’s Rust, Python, Node.js, Go, Java, C#, Ruby, and Elixir bindings. Parsers are downloaded on first use and cached locally, so installing the package doesn’t pull all 371 grammars onto disk at once. It ships pre-packaged binaries and is PIE-compatible, so no local Rust toolchain is required. Note: the project was previously published as kreuzberg-dev/tree-sitter-language-pack; the org renamed to xberg-io in 2026 and the old GitHub URL now redirects: it’s the same package, not a competing one.

composer require xberg-io/tree-sitter-language-pack

The API is clean and OOP:

setLanguage('php');
$tree   = $parser->parse('rootNode();

echo $root->kind() . "\n";          // object... actually "document" at the root
echo $root->childCount() . "\n";
echo $root->toSexp() . "\n";

This gives the following result:

>program
2
(program (php_tag) (echo_statement (binary_expression left: (encapsed_string (string_content)) right: (encapsed_string (string_content)))))

Tree-sitter never throws on malformed input: it parses through the error and marks the offending region as an ERROR node instead. Check for it explicitly, so you can easily validate code in any of the supported languages:

$invalidPHPcode = 'parse($invalidPHPcode);
if ($tree->rootNode()->hasError()) {
    echo "Syntax error detected\n";
} else {
    echo "Valid syntax\n";
}

echo "\n--- positional data ---\n";

$start = $root->startPosition();
$end   = $root->endPosition();
echo "start: row {$start->getRow()}, column {$start->getColumn()}\n";
echo "end:   row {$end->getRow()}, column {$end->getColumn()}\n";

This shows the following result:

--- error detection ---
Syntax error detected

— positional data —
start: row 0, column 0
end: row 0, column 30

Every node exposes positional data: startPosition() and endPosition() return a Pointwith row and column. This makes it straightforward to produce diagnostic messages with precise line numbers.

Side note: on Mac OSX, I had to install it with PHP 8.4, not 8.5.

Traversing the Tree: A Practical Example

Suppose you want to extract every import statement from a TypeScript file. With tree-sitter inside PHP, the walk is explicit but mechanical:

setLanguage('typescript');
$source = file_get_contents($argv[1] ?? __DIR__ . '/app.ts');
$tree   = $parser->parse($source);

function findImports(Node $node, string $source): void {
    if ($node->kind() === 'import_statement') {
        $start = $node->startByte();
        $end   = $node->endByte();
        echo substr($source, $start, $end - $start) . "\n";
    }

    for ($i = 0; $i < $node->childCount(); $i++) {
        findImports($node->child($i), $source);
    }
}

findImports($tree->rootNode(), $source);

No regex, no fragile string manipulation. And the tree is structurally sound.

Other Binding Options

If you prefer not to install a native extension, one alternative exists:

talbergs/php-tree-sitter: FFI-based bindings, valid with PHP 8.0+ and ext-ffi. Pure PHP installation via Composer, loads the tree-sitter shared library at runtime. Lower performance ceiling than a native extension, but zero build step.

The Performance Caveat: Tree-sitter vs `token_get_all` for PHP

Tree-sitter is impressively fast: it was designed to re-parse large files on every keystroke in an editor. But when your target language is PHP, and all you need is a flat token stream, PHP’s native token_get_all(), or its object-oriented successor PhpToken::getAll() introduced in PHP 8.0, will beat tree-sitter consistently.

The reason is structural: token_get_all is a thin wrapper around the same C lexer PHP uses to execute your code. It runs in-process with zero FFI overhead, produces a flat array rather than a tree, and does no grammar inference. For straightforward tokenization: counting strings, scanning for function names, detecting encoding declarations. This is unbeatable.

Tree-sitter’s value for PHP analysis lies in the tree, not the tokens. If you need to understand scope, resolve variable references, detect unreachable branches, or navigate the structural relationship between a method call and its arguments, the CST pays for itself. For a flat scan, it does not.

A rough rule of thumb from the field: tree-sitter PHP parsing runs about 2–5× slower than token_get_all on the same source. The gap narrows on incremental re-parses (tree-sitter’s speciality), but for a single-pass bulk scan of a codebase, token_get_all / PhpToken::getAll() is still the PHP-native winner.

Summary

Direction	Approach	Key Tools
Rust to PHP	Parse PHP in Rust via tree-sitter	`tree-sitter-php` crate, Mago, ast-grep
PHP to Everything	Parse any language inside PHP	xberg-io/tree-sitter-language-pack, talbergs/php-tree-sitter, ext-treesitter

Tree-sitter sits at an unusual intersection: it is fast enough for editors, expressive enough for static analysis, and portable enough to be embedded almost anywhere. The PHP ecosystem is discovering this from both ends simultaneously. Rust tools are consuming PHP grammars to build the next generation of blazing-fast developer tooling, while PHP itself is gaining the ability to understand every other language in the stack.

Whether you are writing a PHP quality tool in Rust or analysing your JavaScript bundle from a PHP script, tree-sitter is the parsing layer worth knowing.

Sources and further reading:

carthage-software/mago: Mago PHP toolchain
tree-sitter/tree-sitter-php: official PHP grammar
soulseekah/ext-treesitter: PHP C extension
talbergs/php-tree-sitter: FFI bindings
xberg-io/tree-sitter-language-pack: 371 grammars for PHP (formerly published as kreuzberg-dev/tree-sitter-language-pack)
ast-grep/ast-grep: structural code search in Rust
php-rust-tools/parser: handwritten Rust PHP parser

The post Tree-sitter and PHP: Two Directions, Endless Possibilities appeared first on Exakat.

Adding the last types to PHP code in 2026 - Exakat

2026-09-03T10:01:52.000Z

Adding the last types to PHP code

2026 update note: This is an update of the original 2022 article, with annotations added locally to flag what’s changed in the PHP language since: mainly PHP 8.4’s property hooks and asymmetric visibility, which give native answers to several problems the article works around by hand.

Adding the last types to PHP code

Adding types to PHP code is a staple of any PHP code refactoring. With a code base crawling towards 10 years and over 2000 classes, Exakat is quite a consistent piece of software, with a lot of parameters, methods and properties. Covering everything with types was long, and, at time, tortuous.

I have to admit, it also feels like 100% test coverage. Somewhere, between 90 to 95% of type coverage was the confortable spot. Yet, going beyond that level required a lot more effort, and at the same time less spectacular rewards. The challenges it posed were interesting, so I wanted to share them and the adopted solutions.

Some of the issues revolved around adding invisible types, handling the default values, managing temporary values, deciding when to use union types, wrestling with resources and juggling with cache mechanisms. Let’s go!

At first, typing is very easy

Before the last leg of the journey, there was the first leg : obviously. It was the easy part, and, in the retrospect, possibly the least useful. Typing code that already works well doesn’t change anything : it keeps working well.

Adding the first types consists in looking at the best maintained part of the source, and saying : yep, I know this is a string or an array, or an object of type A, for sure. And then, adding the type. And of course, there are very little mistakes at that stage.

There are multiple ways to guess the correct type : knowing the code and its intent, incoming argument, returntype of methods, PHP native support, usage of methods and properties, comparison to literals, usage with operators, type propagation,… I have already made several conferences about automated typing, where the code can be typed with very little human intervention. Even, Exakat is capable of guessing and adding such types to any code.

During this phase, the types flow naturally, and rarely lead to any surprise error. The code was under control, and adding the type doesn’t really change anything. A rough estimate is that until 2/3 of typing coverage, there is no real challenge, nor, any rewards. A.k.a., so special case is discovered.

In fact, I suspect that any ambiguous decision about types was inconsciously set aside for later. The obvious cases are quickly added, and any hesitation leaves the property untyped. When the coverage is still 32%, and there are still several thousands of them to add, no one notices an untyped property.

Then, came the hard phase

When the easy types started to become rarer, the harder to decide types had to be added. This stage covers situations that were not obvious. Sometimes, it took running the tests and some examples to see a fatal error emerge. Trust in the type system was now crucial : adding a type could mean an error later.

Null is not a default value anymore

This one is very easy to understand, and, for some reason, it kept coming back. It really looks like fighting an stubborn habit.

Look at the code below : there is an obvious type for the argument, which later is used to call a method. Adding the type A is a no brainer.

Now, let’s see the same situation for a property, which later is used to call that same method. Adding the type A is also a no brainer. But there is a catch.

When adding null as default value to a parameter, the null type is also silently added to the type. In the first code, it is possible to call foo without argument, with a null or an A object. Even when the type is not explicitely nullable.

When adding a type to a property, nullis not automatically added. It has to be explicitely done. Which means that the default value cannot be null.

To be helpful, PHP checks the default value compatibility for properties and arguments at compilation time, so the feedback is quite fast. The repeated errors where definitely the sign of a change of habit.

Removing the default value to keep type single

The first solution is to remove the default value altogether. In particular, when the property is assigned at constructor time, there is no need to provide a default value.

Note that when moving the property to the promoted properties, that property becomes a parameter, and, as such, the hidden null type may apply too.

Cache mechanism with null

Now, removing the null type is not always possible. In particular, when the default value is needed to set up a caching, or lazy loading mecanism.

Here, the constructor will not initialize the property, and the object simply waits for the method to be called once. Then, the argument is cached, and later, reused.

The default value null is used to detect the empty cache, so it is needed. This is a case where the nullable type is useful.

One obvious solution is to add the nullable type to the property. This turns the type is a union type. Indeed, it is a type A or null. In a sense, union types where available before PHP 8.0, but just for null.

Property hooks come with superpower

PHP 8.4 added property hooks, which give this exact pattern a native, non-nullable public surface. The backing storage can still be an two-headed type ?A, but the hook getter may only return one.

 $this->aCache ??= $this->buildDefaultA();
    }
}
?>

Callers of $consumer->a never see a nullable type: the union-type-for-null compromise described below becomes an implementation detail rather than part of the public contract.

This also applies to the setter, which may accept more types than advertized at the property level.

 $this->a = $a ?? $this->buildDefaultA();
    }
}
?>

Setting $consumer->a accepts the null, but it is never set. Later, this reduces the number of tests when dealing with that property.

NullPattern alternative

An alternative to the usage of null is to create an Null Object Pattern for the Aclass, and to use it for default detection.

This approach prevents the code to using the null type : only an A class is needed. It may be tested with instanceof, and created anywhere, thanks to the parameterless constructor.

On the other hand, it forces the creation of an extra empty class. This class acts as a simple placeholder, and uses more memory than a single null. Also, an extra class introduces extra code, albeit a very simple one.

This extra class will also prevent usage for the final keyword with the class A, since A class now has a child. And also, every parameter with the A type now needs to check for NullA, or face mayhem.

Null or null class?

The nullable type is a lot easier, and it gives actual value to the null value (sic). The Nullclass allows for single typing the property : it comes with some rare edges cases, and adds extra coding to the source. So far, we opted for the nullable version, with its less surprising Fatal Errors.

As of PHP 8.4, there’s a third option beyond “nullable” vs. “Null Object Pattern”: a property hook with a single-typed public property and a nullable private backing field (see the note above). It avoids the extra class the Null Object Pattern requires, while keeping the public type non-nullable: arguably the better default now for the specific cache/lazy-init case this section is about. The Null Object Pattern remains the right call when you need instanceof-testable “empty” objects passed around as values, not just lazy-computed properties.

Temporary values in properties

Let’s go back to property typing. We already mentioned that they behave differently than arguments for the type of the default value. They also enforce the type at each step of the life of the property, which means that the property cannot handle temporary values of different types anymore.

This is a concern when acquiring data from sources that needs validation. Here is an example:

Even after testing the incoming variable x as a non-zero positive integer, values in $_GET are string. This will conflict with the early assignation of $ito $this->int.

With this example, the solution is simple : rewrite some of the $this->i with $i. This is sufficient.

In other situations, the temporary value stays a lot longer before being processed into its final form. Then, the type system forbid that the property hold something else than the expected type, even for a short time.

That is one of the most interesting error to catch: it literally cleans the code and makes it a lot more robust.

Property hooks also give a place to put the normalization step instead of scattering casts across every call site. A set hook runs on assignment and can accept a looser input type, cast it, and store the validated final type:

 (int) $value;
    }
}
?>

This doesn’t remove the underlying tension the article describes — the property still can’t silently hold a different type at rest — but it centralizes the cast in one declared place instead of at every assignment site, which is closer to what the “rewrite $this->i to $i” workaround below was trying to approximate by hand.

More casting values in properties

For scalar types, the simplest processing of the temporary value might be a type cast. This would be the case here :

This happens a lot with decoded values from JSON or YAML, or incoming values from the Web, ($_GET, $_POST, …). This is definitely a side effect of typing with scalars, and it doesn’t happen so much when typing with classes.

Unveiling hidden types

Adding class types to properties had a minor annoyance : adding the type in the list of use expressions. In typeless code, it was completely hidden. Now, those types are needed. Look at this code :

Obviously, the property $sqlite3 will now wear a nice Sqlite3 type : this will avantageously replace the typing by naming previous convention. The important part here is to not forget the use Sqlite3 line at the top of the file, since the namespace is not the global one.

Nothing spectacular, and very easy to detect… when one is paying attention. Otherwise, it is easy to add Sqlite3 as a type, and get an Unknown class MyNamespace\Sqlite3for that file. Believe me, it is as obvious as it is easy to forget and curse about it. Also, using an IDE was helpful.

In the end, this process makes internally used classes appear in the use list of use expression. This list of use is now getting even bigger than previously, and it is turning into a list of dependencies for the class. This might be useful.

Another situation that make those types appear is with return types. In the example below, a factory is declared with the expected type. Until now, this return type was not explicitely used in this code. It was hidden.

resource is not a type

This leads to the impossible to type case : resource. This is a special and soft reserved keyword : PHP has reserved it, but it is not enforcing it (yet). There is no way to type anything as a resource. So, we have this situation:

The solution for this specific case was provided by Tim Bond : use SplFileObject. This handy little class uses a OOP syntax and exposes all the classic functions, such as fwrite(), fgets(), etc. as methods. There is only a classic remove the resource and make it a methodrewrite.

The call to fopen() is now an instantiation. Note that we also forgot the use SplFileObject to make this run : I told you it was easy to forget!

And now, the class is typed.

2026 update: resource is still not a declarable type as of PHP 8.6 (in beta, targeting Nov 2026) — no RFC has changed this since the article was written. The SplFileObjectworkaround remains the best available advice for file handles specifically.

Not all resources are ready

This trick doesn’t work with stream_socket_server(), which also returns a resource. That resource has no direct alternative, although there might be some solution when looking at the Socketsextension. Who knows, since there is already a dedicated Socket class. If you have experience with this, please give us a shout!

This is still the state of things: the ext-sockets Socket class covers socket resources, but there’s no general-purpose typed replacement for arbitrary resource values. For example, from curl_init(), which itself moved to a CurlHandle object in PHP 8.0, quietly fixing this exact complaint for that one function without a language-level fix for resource as a concept.

Conclusion

The journey to 99.9% typing was longer than expected, and it revealed some light traps :

invisible types
Casting more than before
handling the default values
managing temporary values
wrestling with resources
juggling with cache mechanisms

Initially, it is easy to postpone typing and only focus on the easy one. Later, typing gets harder, and let some unclean code situation emerge. Dectecting them, thanks to tests, and fixing them along the way is the best way to go.

In case of unsolvable typing situation, leaving the property, parameter or return type empty, or mixedis a good strategy. The practise shows that such situation tends to simplify itself, by adding the other types in the code. So, just let the hard one on the side, and come back to them later : tightening the code elsewhere do help.

Happy PHP code auditing!

The post Adding the last types to PHP code in 2026 appeared first on Exakat.

setlocale() and Its Six Personalities - Exakat

2026-09-02T14:28:23.000Z

setlocale() and Its Six Personalities

What does setlocale() actually do? It changes the date format, right? It’s a fair guess, and it’s wrong in an interesting way: setlocale() doesn’t touch one behavior, it touches six, and most of them have nothing to do with dates. Under the hood it’s a thin wrapper around the C library’s setlocale(3), which means PHP inherited not just the feature but the entire category structure glibc invented for it in the 1990s. It is a global state that happily outlives the request that set it, if your SAPI happens to keep the process around.

Six LC_* categories, one call. LC_ALL sets them all at once, which is convenient right up until the moment it silently reaches into a category you forgot existed.

Six categories, one entry point

Constant	Controls	Key functions
`LC_COLLATE`	String comparison order	`strcoll()`, `usort()`
`LC_CTYPE`	Character classification, case conversion	`strtoupper()`, `strtolower()`, `ctype_*`
`LC_MONETARY`	Currency formatting	`localeconv()`, `NumberFormatter`
`LC_NUMERIC`	Decimal point, digit grouping	`localeconv()`
`LC_TIME`	Date and time formatting	`strftime()` (deprecated)
`LC_MESSAGES`	Translated system responses	`gettext()`, `_()`

LC_ALL sets every row in that table with one call. That’s the whole design tension of setlocale() in one sentence: it’s grouped by what glibc happened to ship together in 1993, not by what a PHP developer would actually want to change together. Wanting French date formatting has nothing to do with wanting French decimal separators, but LC_ALL will hand you both whether you asked or not.

Note that is the source of a classic bugs, where calling setlocale() with LC_ALL has far reaching impacts that break the rest of the application. Nothing like changing the date format to Spanish, and see the sorting of customer names go awry. Connecting theses dots is quite a challenge.

LC_COLLATE: string comparison order

strcoll() orders strings the way a human from that culture would alphabetize them, not the way their byte values happen to sort. In English that’s mostly invisible. In Swedish, ö sorts after z. In German, ä behaves like ae for collation purposes. Your “alphabetical” sort was only ever alphabetical for one alphabet.

Same array, same usort() call, same strcoll callback, two completely different orderings, because the only thing that changed is a global the sort function silently consults. If a user ever files a bug titled “sorting is wrong” and can’t say how, check the locale before you check the algorithm.

Rank	C (byte order)	de_DE	sv_SE
1	a	a	a
2	ä	o	o
3	o	z	z
4	ö	ä (sorts as “ae”)	ö (after z)
5	z	ö (sorts as “oe”)	ä (after ö)

LC_CTYPE — character classification and conversion

strtoupper() and strtolower() don’t have a fixed idea of what “uppercase” means — they ask the current LC_CTYPElocale. Under the plain C locale, anything outside ASCII is invisible to them; accented letters pass through untouched. Give PHP an actual language locale, and accented characters finally get treated as letters instead of noise.

Input	C locale	fr_FR locale
`é`	`é` (unchanged)	`É`
`ü`	`ü` (unchanged)	`Ü`
`ï`	`ï` (unchanged)	`Ï`
`c`	`C`	`C`

And then there’s Turkish, which every locale-aware string function eventually has to apologize for. Under tr_TR, uppercasing "i"produces "İ" (dotted capital I), not "I", and lowercasing "I" produces "ı" (dotless), not "i". This is entirely correct Turkish orthography and entirely fatal to any code that assumed strtolower($username) === strtolower($input) was a safe way to compare identifiers. Somewhere there is a login form that only breaks for users named İbrahim, and nobody on the team can reproduce it from their desk in Amsterdam.

LC_MONETARY: currency formatting is out

This is the section for the older code bases. money_format(), the function every LC_MONETARY tutorial reaches for, was deprecated in PHP 7.4 and removed outright in PHP 8.0. If you’re running anything newer, the function simply doesn’t exist. You can skip this section.

If you stay with me, I have to let you know setlocale(LC_MONETARY, ...) still works, but nothing in the engine uses that configuration anymore. In particular, number_format() is not affected, because it doesn’t have any currency symbol.

We can recommend using the brick/money component, or read PHP Number Format Currency – How to Format Currencies in PHP.

The most accessible replacement is NumberFormatter and it isn’t locale-dependent at all. It works with the intl extension, which takes a locale as an explicit argument instead of an ambient global.

formatCurrency($amount, 'EUR');
// 1 234 567,89 €

$de = new NumberFormatter('de_DE', NumberFormatter::CURRENCY);
echo $de->formatCurrency($amount, 'EUR');
// 1.234.567,89 €
?>

Locale	Formatted output
en_US	$1,234,567.89
de_DE	1.234.567,89 €
fr_FR	1 234 567,89 €
ja_JP	¥1,234,568
hi_IN	₹12,34,567.89 (Indian digit grouping)

Notice what changed structurally, not just cosmetically: NumberFormatter takes the locale as a constructor argument. setlocale() doesn’t have an argument for “which call this applies to”: it applies to the whole process until you call it again. That difference is the entire second half of this article.

LC_NUMERIC: the one that bites the old

LC_NUMERIC swaps the decimal point and the digit-grouping separator: 1,234.56 in the US becomes 1.234,56 in Germany. Reasonable enough for display.

The localisation used to happen whenever a number had to be cast to a string, until PHP 8.0. Before that, the conversion string to integer did not agree with the conversion integer to string.

Since PHP 8.0, all conversion are locale independent, so the above doesn’t happen anymore. In fact, the only leftover of that era is the %F format of the *printf() family.

So, the trap is that PHP’s own number parsing doesn’t get the memo: floatval(), (float) casts, and JSON encoding/decoding all assume a period, always, regardless of locale.

floatval() stops reading at the first non-numeric character. It doesn’t consult LC_NUMERIC to figure out what “the decimal point” means this week; it only ever knows .. So the moment you set a European locale, "3,14" doesn’t parse as 3.14 — it parses as 3, followed by a comma it discards. No warning, no exception, just a number that’s wrong by a factor that depends on where the comma was.

This is the trap worth memorizing about LC_ALL: calling it with any European locale drags LC_NUMERIC along for the ride even when all you wanted was French month names. If you must set LC_ALL, immediately pin LC_NUMERIC back to C:

And as a side note, please, upgrade to PHP 8.3 and more recent.

LC_TIME: and the dates too

strftime() reads LC_TIME for month names, weekday names, and AM/PM markers.

Locale	`strftime('%A, %B %d, %Y')`
en_US	Saturday, March 15, 2025
fr_FR	samedi 15 mars 2025
de_DE	Samstag, 15. März 2025
ja_JP	土曜日, 3月15日, 2025
ar_SA	السبت، 15 مارس 2025 (right-to-left)

strftime() was deprecated in PHP 8.1 and is scheduled to leave core entirely, following the exact path money_format()already walked. The replacement, IntlDateFormatter, again takes its locale as a constructor argument rather than reading an ambient global — the same pattern NumberFormatter uses, which is not a coincidence. Every LC_*-dependent function the intl extension has replaced has been replaced with one that stops trusting setlocale().

LC_MESSAGES: translations, when gettext is here

gettext() looks up translated strings in .mo catalogs, keyed by whatever LC_MESSAGES currently says. This is the one category that isn’t really about formatting at all: it’s entirely internationalization, or i18n. It’s also the one most likely to simply not be there: it only works if PHP was built --with-gettext. And if you don’t have a distinct system for translations.

setlocale(LC_MESSAGES, 'fr_FR.UTF-8') sets the lookup locale.
_('Welcome!') triggers a lookup by msgid.
PHP searches ./locales/fr_FR/LC_MESSAGES/myapp.mo.
It returns the translation — or silently falls back to the original English string if the catalog or the entry is missing.

That silent fallback is the sting: a missing .mo file doesn’t error, it just serves English to a French user and waits for someone to notice. Always guard with function_exists('gettext') before relying on this category; it’s the one part of setlocale() that can be entirely absent depending on how PHP was compiled, not just how it was configured.

important points about setlocale() and its constants

They’re not six independent settings: they’re six views onto one process-wide value. setlocale() doesn’t take a scope, a request ID, or a callback context. It mutates the same C global every other request in the same process will read next, which is invisible on classic PHP-FPM (one process, one request, the state dies with the process) and very much not invisible on anything that keeps a worker alive across requests: I’m looking at you, RoadRunner, Swoole, FrankenPHP, and the others.

Set LC_NUMERIC to de_DE on request #4012 of a long-lived worker and forget to reset it, and request #4013 inherits a decimal comma it never asked for. It’s the same category of bug as leftover superglobal state in a coroutine worker, just for a global almost nobody thinks to audit.

The intl extension isn’t a replacement for the same thing: it’s the industry quietly admitting it could do something even more complex. NumberFormatter and IntlDateFormatter both take the locale as an explicit constructor argument. That single change, locale as a parameter instead of ambient global state, is why they can run correctly, one call after another, in the exact long-lived worker that makes setlocale() unsafe. Every function intl has replaced, like money_format(), and soon strftime(), was replaced with this pattern specifically.

Almost nobody restores what they changed. setlocale() returns the previous setting for exactly this reason: $old = setlocale(LC_ALL, 0) followed by a restore at the end of the function is the correct pattern: in fact, I can see #[NoDiscard] usage for this value, if it was not breaking so many codes.

Almost no code in the wild capture it and reuses it, because a locale bug doesn’t crash anything. It just makes a French invoice look slightly american state unionist, or a sort order look slightly wrong, or a float silently lose its fractional part. Nothing loud enough to fail a test suite; plenty loud enough to fail an audit six months later.

The bigger picture

setlocale() is a 1990s C API that PHP exposed more or less verbatim, and for twenty years that was a reasonable trade: one process per request meant global mutable state cost you nothing, because it never survived long enough to leak anywhere. That assumption is the part that’s aged badly, not the function itself. The locale categories are exactly as coherent as they were in 1993; it’s the execution model around them that quietly stopped matching.

Every long-lived-worker runtime PHP has grown in the last few years inherits this function completely unchanged, along with its assumption that nobody’s still using it three requests later. Auditing a codebase for stray setlocale() calls that never get restored is a fairly cheap static check to write. Whether anyone runs it before switching their app to a worker-based SAPI is a different question entirely.

The post setlocale() and Its Six Personalities appeared first on Exakat.

The Clock That Cracks Passwords - Exakat

2026-09-01T15:44:26.000Z

The Clock That Cracks Passwords

To understand what is the clock that cracks passwords, let’s start with a quizz. Which security flaw does the following PHP login check contains?

If you said “the password should be hashed with bcrypt”, you are right and you may stay. If you said “use === instead”, you are wrong and we will get to why later. If you stared at it for thirty seconds and saw nothing, you are in the majority. The bug passes a code review, satisfies a static analyser, and returns the correct answer every single time.

It just returns that answer at slightly different speeds, depending on how close the guess was.

The bug is ==. Not because it lies. Because it talks too much.

The Lie Inside ==

PHP compares strings character by character, left to right, and stops the moment it finds a mismatch. This is the efficient method: no need to continue comparing once a mismatch is found. For ordinary work, it is fine. For secrets, it is a slow-motion catastrophe.

Compare the three most common ways to check whether two strings are equal:

hash_equals() arrived in PHP 5.6, introduced specifically for this problem. It compares two strings and returns true or false, but it never stops early. Whether the very first byte mismatches or only the very last byte mismatches, the function takes the same amount of time. It has a poker face.

=== is often presented as the safe upgrade from ==. It is a safer operator in general: it avoids the type-coercion surprises that trip up many PHP developers. But for secret comparison it is no better. It does the type check, then walks the bytes and exits at the first difference. Two distinct problems, regularly confused.

The insight at the heart of this post is a simple one: the duration of a comparison is information. And in security, information is currency.

Cracking a Password, One Nanosecond at a Time

Here is the attack, stated as plainly as possible.

A server checks whether $guess == $secret. The secret is supersecret123, fourteen characters. The attacker does not know the secret. The attacker does know that the server is using an early-exit comparison, and that the server can be queried repeatedly.

So the attacker observes:

xxxxxxxxxxxxxx is rejected very quickly. The x mismatches at position 0 and the comparison halts.
sxxxxxxxxxxxxx takes slightly longer. The s matches position 0. The x mismatches at position 1 and only then does the comparison halt.
suxxxxxxxxxxxx takes slightly longer still. Two matching characters, two loop iterations before exit.

Each extra matching prefix byte adds one more step. Each step takes a few nanoseconds. The attacker measures those nanoseconds and reads the story they tell.

The algorithm that follows is almost embarrassingly simple:

Fix position 0. Try every character in the charset. Keep the one that produces the slowest rejection. That is the correct first character.
Fix that character. Move to position 1. Try every character. Keep the slowest.
Repeat until the response says “access granted” instead of “access denied”.

A small digression on the word “oracle”: in cryptography, an oracle is any system that answers yes-or-no questions about a secret. The word is borrowed from antiquity. The oracle at Delphi was famous for appearing to say very little while actually saying quite a lot. The resemblance is apt.

The mathematical payoff of this oracle is dramatic. For a fourteen-character password drawn from lowercase letters and digits, a brute-force search requires at most 36^14 guesses, which is roughly 4.8 × 10²¹. That number is approximately the number of grains of sand on Earth, multiplied by ten. The timing oracle reduces the search to at most 36 × 14 guesses: 504. The difference is not a small improvement. It is the difference between impossible and before lunch.

The attack.php script from this post’s repository makes the oracle visible:

╔══ Vulnerable: early-exit comparison ══╗
  xxxxxxxxxxxxxx     252 ns
  sxxxxxxxxxxxxx     303 ns  ██████████████
  suxxxxxxxxxxxx     371 ns  ███████████████████████████
  supxxxxxxxxxxx     417 ns  █████████████████████████████████
  superxxxxxxxxx     529 ns  ██████████████████████████████...
  supersecret1xx     916 ns  ████████████████████████████████████...
  supersecret123     983 ns  ████████████████████████████████████████...


╔══ Secure: hash_equals() ══════════════╗
xxxxxxxxxxxxxx 192 ns
sxxxxxxxxxxxxx 192 ns
suxxxxxxxxxxxx 193 ns
supersecret123 194 ns

The bar chart in the first block is the oracle rendered in ASCII. The flat line in the second block is what security looks like.

The Guessing Game

Reading about an attack is one thing. Actually holding the oracle and using it is another.

The repository includes game.php, a small CLI script that generates a random password and invites you to crack it using timing alone. No other hints are given.

php game.php             # interactive: you provide the guesses
php game.php --auto      # the solver runs itself, you watch
php game.php --length=8  # set the password length (default: 6)

In interactive mode, the script prints how long each guess took and nothing else. You use those nanoseconds to converge on the answer. There is no scoreboard, but you will feel the moment you start using the oracle deliberately rather than guessing at random. That is the point of the exercise.

The --auto mode is the more instructive one. It runs the byte-by-byte attack in front of you, printing the timing for each position as the solver locks in one character at a time:

Position 1/5  (known so far: _____)
  'h' →  173.08 ns  <-- winner
  'v' →  130.68 ns
  ...
Position 2/5 (known so far: h____)
'2' → 241.08 ns <-- winner
'z' → 173.39 ns
...

Cracked: h2c7a in 1621 oracle calls.
Brute-force would have needed ~60,466,176 guesses.

Watching the solver converge is the most convincing argument for hash_equals(). No amount of prose is as persuasive as watching a six-character password dissolve in under two thousand guesses.

The Framework Illusion

At this point a reasonable developer might push back. The demo ran each comparison 150,000 times in a tight inner loop. A real server routes the request through middleware, reads from a database, renders a template, writes a log line. The nanosecond signal is buried under fifty milliseconds of framework overhead. Surely this is theoretical?

It is not theoretical. It is slightly more expensive.

The signal-to-noise ratio is genuinely unfavourable. A typical Symfony or Laravel response takes 50 to 200 milliseconds in production. The per-byte timing difference we measured is 50 to 200 nanoseconds. That is a ratio of about one in a million.

But the attacker is not sending one request per candidate. The attacker sends ten thousand requests per candidate and computes the median response time. Framework overhead is random noise: it varies independently of the secret. The per-byte timing difference is a systematic bias: it shifts the median upward, consistently, for the correct character. Statistics are patient. Given enough samples, the signal emerges from the noise with mathematical certainty.

A historical note: the 2023 Marvin attack against RSA decryption recovered private keys over a standard TCP connection, exploiting timing differences measured in milliseconds, not nanoseconds. TLS-level timing attacks have worked against encrypted traffic. The Lucky Thirteen attack on TLS 1.2 broke the CBC padding scheme using remote timing differences on the order of a few hundred microseconds. The argument that “the noise drowns it out” has been disproved so many times that it no longer deserves to be a comfort.

The framework raises the cost of the attack. It does not close the oracle.

Time-Padding: Hiding the Clock

Replacing == with hash_equals() fixes the comparison. It does not fix the clock.

Even with a constant-time comparison, the total response time can leak. A login endpoint that returns in 2 ms when the username is unknown, because it short-circuits before ever reaching the password check, and in 15 ms when the username exists, because it fetches the user record and computes the full comparison, is leaking account existence. That is a different oracle, and it does not touch the password at all.

The fix is to floor every auth response to a minimum duration and add a small random jitter:

function timePaddedAuth(callable $work, int $minMs = 200): mixed
{
  $start = hrtime(true);
  $result = $work();
  $elapsed = (hrtime(true) - $start) / 1_000_000;
  $jitter = random_int(0, 10);
  usleep((int) max(0, $minMs - $elapsed + $jitter) * 1000);
  return $result;
}

Wrap the entire authentication flow in one call. “User not found” and “wrong password” both take the same visible time. The jitter prevents a determined attacker from cancelling out the floor by averaging it away.

Two things to keep in mind. First, this is defence in depth, not a replacement for hash_equals(). Fix the comparison and pad the response: both, not one or the other. Second, set the minimum generously. If your slowest legitimate auth path takes 80 ms on a slow day, a 100 ms floor leaves no room. Make it 300 ms. Users will not notice. The attack becomes several orders of magnitude more expensive.

The Rogues’ Gallery

hash_equals() covers ==. But == is not the only comparison function in PHP, and the others are equally talkative.

Expression or function	Early exit	Safer alternative
`$a == $b`	yes	`hash_equals()`
`$a === $b`	yes	`hash_equals()`
`strcmp($a, $b)`	yes	`hash_equals()`
`strncmp($a, $b, $n)`	yes	`hash_equals()`
`in_array($token, $list)`	yes	compare hashes of all entries
`array_search($token, $list)`	yes	compare hashes
`str_contains($s, $needle)`	yes	HMAC-based membership check
`strpos($s, $needle)`	yes	HMAC-based membership check

in_array is the one that surprises developers the most. It is common to keep a list of valid API tokens and check incoming requests against it. The call iterates the list and exits the moment it finds a match, or exhausts the list and returns false. The timing tells the attacker both whether the token is valid and, if not, how far alphabetically the closest token is. The safe pattern is to hash every candidate in the list and compare hashes: the hashes are not secret, and hash_equals() on two hashes gives away nothing.

str_contains and strpos are worth naming because they appear in security code more often than they should. A pattern like if (str_contains($apiKey, $knownPrefix)) leaks how far the prefix match extends. That information feeds the same oracle.

It Is Not Just Passwords

We have been talking about passwords. The same clock ticks on anything the application keeps secret.

Password-reset tokens are the highest-risk example after passwords themselves. They are typically random hex strings, stored in the database, compared when a user follows a reset link. A timing oracle on the reset endpoint lets an attacker forge a valid token without ever receiving the email. The fix is hash_equals() on the comparison, a hashed store in the database, and a short expiry window so the oracle has less time to be useful.

Email addresses are a subtler case. They are rarely treated as secrets, because users hand them out freely. But a login form that returns faster when an email address is unknown than when it is known is an account-enumeration oracle. The attacker does not need to guess passwords at all. She just needs to know which emails are registered, which is often enough to cause harm. Breached credential lists are built this way. The time-padding approach from the previous section handles this, since both “user not found” and “wrong password” end up taking the same visible time.

API keys and webhook secrets are long-lived, machine-generated strings. They are the most valuable timing target in a typical web application, because a compromised API key grants ongoing access without triggering any password-reset flow, and the key owner may not notice for months. Constant-time comparison on ingest, a generous time pad on the validation endpoint.

Session tokens sit in cookies and are compared against the session store on every request. Most frameworks handle this correctly in their default session handlers. Custom session handlers, or hand-rolled session logic, are where the problem tends to reappear.

The question to ask about any endpoint that receives a secret value from the outside is: does the total response time, as seen by the caller, correlate with how close the input was to the correct answer? If yes, you have an oracle.

When the Secret Hits the Database

All of the above assumes the comparison lives in PHP. But many of these values arrive via a database query first, and the database has its own clock.

Consider the classic token-verification pattern:

SELECT user_id FROM password_resets WHERE token = ? AND expires_at > NOW()

If the token column has a B-tree index, the database engine walks the index tree to find the row. The depth of that walk depends on where the sought value sits relative to the existing rows. Tokens that sort close to existing values in the index may require slightly different numbers of page accesses than tokens that sort far from any existing row. This is a fainter signal than PHP-level early exit, but it is the same category of leak: the server’s work varies with the input value.

The safe pattern is straightforward: never store raw secrets in the database. Store a SHA-256 hash of the token, and verify by hashing the incoming value and looking up the hash.

// Storing a new token
$raw = bin2hex(random_bytes(32));
$hash = hash('sha256', $raw);
// Store $hash in the DB, email $raw to the user// Verifying
$hash = hash('sha256', $_GET['token'] ?? '');
$row = $db->query('SELECT * FROM password_resets WHERE token_hash = ?', [$hash]);
if ($row && hash_equals($row->token_hash, $hash)) {
// valid
}

Notice that hash_equals() appears even here, comparing two hashes. SHA-256 hashes are not secret in the same way the raw token is, so leaking comparison timing on the hash does not directly reveal the token. But the habit costs nothing and removes the question entirely.

Passwords follow a different pattern, because you cannot verify a bcrypt password in SQL at all: the stored hash encodes a random salt and the bcrypt cost factor, and the comparison requires running the full bcrypt computation on the input. The only correct flow is to fetch the user row by email, then call password_verify() in PHP. password_verify() is constant-time by design and handles the hash format automatically. The database never sees the comparison; it only handles the email lookup.

ORM frameworks do not change any of this. Eloquent, Doctrine, and their equivalents generate the same WHERE token = ? query under the hood. They are code-generation tools, not security layers. It is not a criticism: it is a reminder that switching ORMs does not close the oracle.

A Checklist for Monday Morning

The journey from a single == covered rather more ground than expected. Here is the condensed version.

Replace ==, ===, and strcmp on any secret value with hash_equals()
Add a time pad with random jitter to every authentication endpoint
Audit every in_array and array_search call that touches API tokens, session identifiers, or other long-lived credentials
Store tokens as SHA-256 hashes in the database; never store raw secrets
Use password_hash() and password_verify() for passwords; never do password comparison in SQL
Check username and email lookups for account-enumeration timing side-channels

The attack started with a single two-character operator. The fix also starts there: one function call, hash_equals(). Everything else on the list is the same principle applied consistently, widened to cover the full surface.

The invariant to maintain is simple: the time the server spends on a request must not reveal how close the caller’s guess was. When that holds, the oracle goes silent, and a before-lunch problem becomes 4.8 × 10²¹ guesses again.

The post The Clock That Cracks Passwords appeared first on Exakat.

PHP - BlogFlock

Vale Reviews Your Comments In The Code - Exakat

Vale Reviews Your Comments In The Code

Getting Vale ready

Pointing it at real code

Teaching Vale that this is Markdown wearing a PHP hat

The first vale run is a firehose, and that’s normal

Four moves, in the order that pays off fastest

Turn off the rules that were never arguing with you

Give the project a vocabulary

Tell it that code sitting inside a sentence is still code

Exempt the paragraph nobody’s ever going to rewrite

Writing rules for docblocks specifically

Putting it in CI without picking a fight with day one

The finished config

Who read the comments anyway?

Webmention support - Blog entries :: mwop.net

Recently updated PIE extensions #7 (since September 10th, 2026) - Exakat

Recently updated PIE extensions #7 (since September 10th, 2026)

What do you mean, redeclare a property static? - Exakat

What do you mean, redeclare a property static?

First suspect: PHP 8.6

Second suspect: a new error message

Third suspect: native classes are checked differently

The actual culprit: a brand new property

Why adding a property is not free

When would it have been safe?

A private property

What about final?

The popularity factor

Fixing and detecting

Conclusion

Tracing a PHP CLI application with filo - Exakat

Tracing a PHP CLI application with filo

1. The demo app

2. Install

3. The one rule that matters for CLI

4. Turning it on

5. What’s in the trace

6. Displaying it, option A: the built-in viewer

7. Displaying it, option B: in the terminal

8. Acting on it

9. Bonus: pausing a CLI run

10. Gotchas worth knowing up front

11. Where to take it next

12. Conclusion

PHP Property Resolution Order: Class · Trait · Parent · Interface - Exakat

PHP Property Resolution Order: Class · Trait · Parent · Interface

The priority stack

A concrete example

Interfaces couldn’t join this club, until PHP 8.4

The rules that catch people out

Trait beats parent, no questions asked

Class beats trait — but only if they agree, or the class overrides

Two traits, same property: fatal only if the defaults differ

Shadowing a private property doesn’t override it — it duplicates it

Static properties: shared storage unless you redeclare

readonly blocks a subclass from re-touching an already-set property

Uninitialized typed properties throw exceptions, they don’t default to null

Calling up the chain: self:: vs static::

Side note reminder: enums

The mental model

RisingWave, PHP, and the Streaming Database Idea - Exakat

RisingWave, PHP, and the Streaming Database Idea

Setting up RisingWave

A table, same as any other

The producer: pushing orders from PHP

Reading the stream back, four ways

Everything

Filtered

Aggregated

Continuously aggregated

Putting it together

The bigger picture: fewer moving parts, not just faster ones

PostgreSQL protocol everywhere!

Anoter tool for your database architecture

When PHP Reads Something Else: Visual Traps in Source Code - Exakat

When PHP Reads Something Else: Visual Traps in Source Code

1. The classic confusables: human eyes under pressure

2. Unicode comment starters pack: the #️⃣️ trick

What about `final`?

`readonly` blocks a subclass from re-touching an already-set property

Calling up the chain: `self::` vs `static::`

2. Unicode comment starters pack: the `#️⃣️` trick

2. Use `===` for Strict Comparison

3. Leverage the Nullsafe Operator (`?->`)

5. Use `match` Instead of `switch`

7. Use `str_contains`, `str_starts_with`, and `str_ends_with`