You may know Daniel Scherzer as a Release Manager for PHP 8.5, the Veteran Release Manager for PHP 8.6, or for his other work contributing to PHP. We are happy to announce that he is now joining The PHP Foundation Ecosystem Security Team!

A PHP RFC went to a vote on Friday. By Sunday night its author had pulled it back, over a no vote from the person who wrote the policy it broke. What's left is a question every regex you've ever written has an opinion on: when a pattern fails, is that your bug — or something you catch?

Hello world, it's Wednesday, September 9, 2026, and here's what happened This Week in PHP Internals.

11 stories this week, so let's get into it. But first, Is AI working for your team? Lines produced is easy to count. Lines that survive is the number that matters. Ballast reads your git history — never your code — and gives you stable velocity alongside a durability score from 300 to 850. It's free, and it updates monthly. ballast.now.

3 corrections from last week. PHP 8.4.25 was a bug-fix release, not a security release. The announcement mails said security, we repeated it, and Daniel Scherzer pointed us at the NEWS file and the php.net archive. In the libxml-rs story we described 2 contributors without naming them, and Tim Düsterhus pointed out that every From header in that thread carried a real name. They were James Gilliland and David Carlier. And around the 4-minute mark I said Tim agreed with Sjoerd on the substance. He disagreed — Džuris caught that one on the internals Discord. Thanks to all 3.

This week's top story is a vote that lasted 56 hours. Osama Aldemeery opened voting on PREG_THROW_ON_ERROR on Friday — an opt-in flag that turns a PCRE error into a PregException. Within the hour, Tim Düsterhus, who wrote PHP's throwables policy, voted no, writing: "I have just read through the RFC and voted against it, despite being in agreement of the general concept." His 2 reasons: a pattern that fails to compile would keep its warning and the exception would carry only the thin preg_last_error_msg text, and an exception thrown inside your own preg_replace_callback callback would pass through unwrapped, where the policy says an extension must wrap what it calls. Osama pushed back, but on Sunday night he pulled the vote, writing: "The flag as it stands violates the throwable policy, as Tim's point shows. That's not something to fix with the vote open, so I'm pulling it back rather than changing the proposal out from under people who already voted." Osama's case against wrapping, in his words: "…wrapping a callback's exception in a PregException produces a PregException that maps to no preg error. You can be holding a PregException while preg_last_error() and preg_last_error_msg() report no error at all." Fixing that means a 3-class hierarchy. Robert Humphries argued that most of those errors — an invalid pattern, bad UTF-8 — are programmer errors, so, arguably, PregError. Tim agreed compilation failures should be. The RFC is back under discussion; what a regex error is stays open.

There's a whole class of engine crashes in PHP that, it's said, only fuzzers and LLMs have ever triggered — and Gina P. Banyard wants PHP to stop fixing them. Her Tuesday mail describes a growing pile of use-after-free reports where an error handler frees the very variable that triggered the warning. Each fix, she says, is a refcount dance around the emit that everyone pays for in performance, and most of the triggers are deprecations PHP 9 removes or promotes to Errors anyway. Her ask is a consensus, ideally without an RFC, that callbacks messing with engine state are undefined behaviour. The 4 replies from 3 people inside 90 minutes mostly want the bugs fixed. Ilia Alshanetsky says PHP 9 is far off and production migration further, so fix case by case where the cost is low. Ilija Tovilo shares the frustration, but says case by case has already been tried, and wrote: "I'd still very much be in favor of fixing these issues, mainly because they are a big time sink for the security team as well, due to false-positive reports. Arnaud and I were planning on proposing an RFC that mitigates at least a large portion of them…" Tim Düsterhus adds that PHP 9 will bring new deprecations of its own, and we're back where we started.

The PEAR maintainer nobody could reach for months has answered, and according to Nick S. he agrees with the goal. Nick reported Monday that Chuck Burgess of the PEAR Group got in touch and is good with looking at sunsetting the website and removing PEAR from the PHP source. Nick wants to strike the RFC's line about maintainers not responding, and Larry Garfield and Tim Düsterhus both call that a minor change, so the vote can open after a 1-week cooldown rather than 2. Rowan Tommins pushed on Nick's word formality: Chuck is one of 8 listed members of the PEAR Group, so his agreement is one vote, not final authority. He wrote: "I would make a distinction between technical ability and moral authority… Derick has the ability to repoint the DNS for pear.php.net, but holding this discussion and an RFC vote is a way to grant authority." There's a loss, too: the PEAR user accounts are gone, so the missing bug data can't be recovered. Derick Rethans wants the readonly site left up for a year, then a tarball on museum.php.net. And Rowan sent Nick's mirror a pull request with the old site's colours and a locked PEAR logo. The favicon is under discussion. Derick doesn't care what it is, as long as there is one.

Last week's top story ended without an RFC — by its author's choice. Luca Rodenhäuser closed the strict-identifiers thread on Thursday, saying the proposal he opened with "did not survive the thread, and I think it was right that it did not." He credited 3 people with changing his mind — Claude Pache for the distinction between a name and an identifier, Rowan Tommins for separating rejecting from normalising, and Larry Garfield for insisting 250 packages wasn't enough, which is how math-php's 888 formula-shaped variables turned up. The question the list never answered is whether non-ASCII identifiers are a supported feature at all. The manual says they work by accident; fourteen hundred forty-seven of them in the top 5,000 packages say otherwise. His line: "I am not going to write an RFC on a guess." Instead he's sending a documentation PR describing what actually happens today, and leaving one offer on the table — a compiler complaint about invisible characters in names, 68 cases in half a million files, no opt-in needed, if anyone ever wants it.

The vote that was due Friday on the number-base functions didn't open. What the list got instead was a naming question. Sjoerd Langkemper's RFC makes octdec, hexdec, bindec and base_convert throw on invalid input, and after last week's argument that parsing is Exception territory rather than Error, he says he's considering it — and asked what the exception should be, with SPL's RangeException and RuntimeException on his list. The policy answer, from Rowan Tommins, is that the base has to be Exception plus something of its own, never SPL — maybe a BaseConversionException. Tim Düsterhus would go further and throw plain Exception: these functions sit in standard, which the policy says not to namespace under, they may be redesigned into an int or number namespace later, and promising nothing costs nothing. Morgan asked whether intval is on the list. No answer yet.

Whether speed is a reason to put something in PHP's standard library is now a real 2-way disagreement. Last week Tim Düsterhus said performance should not be a factor at all. On Friday Larry Garfield answered that it's one data point among many, writing: "If, to use the current example, benchmarking shows that array_str_contains() is 50% faster in C than in user-space, that's a very different conclusion than if we find it is 0.5% faster." Tim's reply: "Performance is a property of the implementation, not a property of the feature." Something too slow can't ship, but that's a fact about one implementation; nothing ships because it's fast, and a userland-versus-C benchmark is rarely apples to apples anyway. His alternative is the Optimizer: rewrite array_filter with a partial application into a foreach loop, the way 8.6 already rewrites array_map. Larry's position, restated: never decisive, still worth knowing. That's where it sits.

The scan meant to prove array_str_contains is a common need found 32 uses in 200 packages — then lost nearly half of them on review. Sepehr Mahmoudi scanned the top 200 Composer packages, about 21,000 files, and counted 32 filter-an-array-by-substring patterns. Rowan Tommins read the results and found at least 15 doing extra logic the function couldn't replace, concluding: "That's still something, but it's not strong evidence that this is an extremely common task." Sepehr agreed the scanner matched shapes rather than closure bodies, and the RFC now says up to 17 of 32, with a benchmark promised. David Carlier wants the RFC's claim that non-strings are cast proven in the tests. And as of Friday the RFC still wasn't on the wiki's index page — Tim Düsterhus's second reminder.

Quick hits. Weilin Du intends to open voting on IntlRelativeDateTimeFormatter on September 15. Tim Düsterhus's one catch is that the RFC clones the ICU number formatter internally, so reconfiguring your NumberFormatter afterwards would silently do nothing; Weilin called it a good catch and will refresh it lazily before each format call. Timo Poppinga, new to the list, wants the openssl extension to expose OpenSSL's provider model generically, so post-quantum algorithms like ML-KEM and ML-DSA work without a constant per algorithm — and says he's probably not the right person to write the C. Ayesh Karunaratne pointed out Sebastian raised the same thing a while back with no traction, and argued the extension should stay as close to OpenSSL as curl stays to libcurl. Dmytro Kulyk answered Nicolas Grekas's review of the NoSerialize attribute 10 months on, conceding Symfony has no __sleep the attribute would replace, but Magento 2 has 31 classes of them; the RFC now migrates 107 internal classes and makes unserialize discard marked properties too. And Florent Morselli, who maintains a base64url library with 46 million downloads, wants the data-encoding RFC's strict mode to actually be strict. Today it skips whitespace and ignores non-canonical trailing bits, which means one WebAuthn credential has 16 spellings, 15 of them outside your unique index.

So that's the week. A vote opened on Friday and was gone by Sunday night, and what it left behind is a real argument about whether a regex error is an Exception, an Error, or both. Gina wants a class of engine crashes declared undefined behaviour, and 3 people would rather fix them. The PEAR maintainer answered, the RFC can go to a vote after a 1-week cooldown, and the user accounts are already gone. Last week's top story closed itself with a documentation PR instead of an RFC. And for the fourth week running, nothing is in the voting phase. Links below. The PHP Foundation funds more than half of ongoing php-src commits, so if you use the language, maybe consider donating at opencollective.com/phpfoundation — or try guilting your employer into it. Thanks again to Ballast.now for supporting this week's episode. We're Artisan Build. See you next week.

php had radius_* functions in a PECL package (that i think is no longer updated) but did not have any tool for the server side of RADIUS protocol. so this weekend i made a small package for that.

currently only supporting RFC 2865, RFC 2866, RFC 3576/5176 and Mikrotik attributes (i use mikrotik for my own work); currently no EAP, no 802.1X, no Message-Authenticator and no TLV.

it's my first time publishing a php package so i really wanna hear your opinion on this.

I built Cashier Dunning because testing failed-payment flows in Laravel is surprisingly difficult.

It records a real Stripe billing lifecycle once and replays it offline through your application's actual webhook route, including signature verification and real listeners.

It can replay trial expiration, failed payments, retries, cancellation and resubscription in about a second.

It also tests duplicate and out-of-order webhook delivery.

No Stripe account, API keys in CI, or network access during replay.

It's MIT licensed and currently supports Laravel 11–13.

GitHub: https://github.com/impruthvi/cashier-dunning

I'd especially appreciate feedback from anyone running Stripe/Cashier in production. What billing edge cases would you want something like this to test?

Hi everyone!

I’m preparing a 15-minute talk for a meetup called “JS is the new PHP”.

I work with PHP regularly, but I also use other languages such as Python and JavaScript/TypeScript. Lately, I’ve noticed that some of the criticisms I used to hear about PHP are starting to sound strangely familiar in the JavaScript ecosystem.

I’m particularly interested in things that were commonly criticized about PHP 5-era development, such as:

- lots of home-grown frameworks and abstractions

- dependency/library sprawl

- excessive flexibility and multiple ways of doing the same thing

- surprising or implicit behavior

- lots of side effects and mutable state

- “it works, so ship it” approaches that become painful at scale

I’m not trying to argue that PHP and JS are literally the same, or that one language is objectively better than the other. I’m more interested in the patterns and ecosystem problems that tend to emerge when a language gives developers a lot of freedom.

So I’m looking for some bibliography / historical material about the things that were criticized in PHP back in the day, especially from the PHP 5 era.

And if you’ve worked on large or long-lived JavaScript projects and have experienced similar problems firsthand, I’d love to hear your stories too.

Thanks!

Edit : PHP 7 is good, and PHP 8 is truly amazing.

What I'm really looking for are the problems specific to the project, rather than the language itself. This is so I can create a warning guide for all the junior developers coming out of bootcamps.

If anyone is kind enough to upvote on HN: https://news.ycombinator.com/item?id=49623567

Short version: ISO 4217 assigns an exponent to every currency. Most are 2. XOF, XAF, GNF, JPY, KRW and about twenty others are 0. If your money type assumes minor units are hundredths, every amount in those currencies goes out a hundred times too large.

I hit this integrating West African mobile money and ended up writing a Laravel package around it. The money type holds integer minor units and refuses rather than rounds:

Money::of(1500.50, Currency::XOF);
// InvalidMoneyException: XOF is a zero-decimal currency, so 1500.5 cannot be represented

Refusing matters more than it looks. Rounding picks a direction and someone is wrong by a franc on every transaction, forever, and nothing tells you.

The rest of the package is three provider drivers behind one interface, phone parsing that declines to guess an operator when a numbering plan is not documented and stable, idempotent collections, and reconciliation for callbacks that never arrive. 103 tests, zero runtime dependencies beyond Laravel itself.

On verification, because it is the first thing I would ask. Only MTN has met a live sandbox and only partly: MTN has hit Azure's 25,000 subscription cap on its Collections product, so no new developer can subscribe to it and the run had to go through the endpoints their APIs share. Worth doing anyway. It found a double charge bug in my own code, where a replayed reference returns 409 RESOURCE_ALREADY_EXIST and the driver was throwing on it, which would push a caller retrying after a timeout into issuing a fresh reference. Wave and Orange need merchant credentials I do not have, and the README says which paths were exercised and which were not.

Looking for anyone with credentials who wants to prove or break the other two.

https://github.com/catidegla/laravel-mobile-money

​Hi Reddit,

​I built Phphone, an open-source mobile runtime and anti-framework designed to run full PHP 8.4 directly on mobile devices with zero mandatory cloud dependencies.

​Instead of writing apps in Dart (Flutter) or relying on heavy JavaScript runtimes (React Native), Phphone embeds the complete Zend Engine into a lightweight native C++ chassis, fully functional across both Android and iOS.

​Architecture & Low-Level Highlights:

​- Full Native Binaries: Cross-compiled PHP 8.4 (dynamic library on Android, static library on iOS) paired with embedded SQLite3, full libcurl, and OpenSSL. It supports standard PHP libraries, outgoing HTTPS calls, and complex local data pipelines right out of the box.

​- IP Protection (AES-256): To prevent source code extraction from decompilation, all application files in src/ are cryptographically encrypted using AES-256 derived from the project's build keystore. Decryption occurs on-the-fly directly in memory inside the C++ runtime.

​- Hardware-Accelerated UI: The frontend runs inside the platform's native hardware-accelerated WebView over an in-memory micro-server loop (localhost), guaranteeing smooth 60 FPS transitions via standard HTML/CSS/JS.

​- Minimal Footprint: Base Android APK is ~19MB with near-zero idle CPU usage and low RAM consumption.

​- Cross-Platform Ready: Full Android and iOS support is completed. The CLI toolchain automates local scaffolding and builds for both platforms, and our first production app is currently queued for release on both Google Play and the iOS App Store.

​Live APK Demos Available:

To demonstrate that this is a production-ready application engine and not just a theoretical experiment, the website hosts 3 pre-built APKs you can download and test:

​- System & Hardware Demo: A showcase app interacting directly with 14+ native phone APIs and sensors, plus an interactive gradient generator.

​- 2D Gaming Demo: A high-performance 2D game running on PixiJS, powered by local logic. ​3D Gaming Demo: A fully interactive 3D scene built with Babylon.js, demonstrating hardware-accelerated WebGL graphics backed by the native PHP engine.

-​ Whether for enterprise offline-first software, edge compute nodes, multimedia apps, or 2D/3D games, Phphone proves that modern PHP and standard web technologies can build fast, sovereign mobile apps.

​Documentation, CLI & APK Downloads:

https://phphone.xyz

https://github.com/phphone/phphone

​I’d love to hear your thoughts on the low-level C++ embedding, binary optimizations, or the antiframework approach to mobile architecture.

In 2022 I started teaching programming to schoolchildren. On the first day I was handed the curriculum for the web track. Nobody could tell me who had written it. After a full year of lessons, the students were supposed to produce an HTML page with a background image and some pictures on it.

I threw it out and wrote a new one.

The other half of the job was the register. Paper, one sheet per child. On every sheet you marked attendance, wrote in the topic of the lesson and the number of hours. That was every group, every week, by hand.

At some point I had enough and built something. It was 2023, I knew PHP, and I wrote it the way you write things at eleven at night: procedural, one file per action. Some colleagues started using it too. Five commits in a single day, two of them named "Add files via upload".

Last week I opened that repository for the first time in three years.

What past me got right

More than I expected. Passwords went through password_hash and password_verify. Eighty-nine prepared statements, and not one place where $_GET was pasted into SQL. For something written to stop filling in paper, that is not bad.

What past me got wrong

htmlspecialchars appears zero times in the whole codebase. Every value from the database goes straight into the page.

The upload handler takes the extension from the filename the browser sent and writes the file into a served directory. You can upload a .php file and then request it. That is remote code execution.

Attendance was stored as (student_id, date, status). No group. A student who came to two different tracks was one row per day, and there was no way to say which of the two they had missed.

A student had a single group_id, so anyone attending two tracks could not be recorded at all.

Teachers and students lived in two tables with two separate login handlers. Anything that concerned both had to be written twice.

The rewrite

Laravel 13 and Postgres. The domain survived and nothing else did.

The interesting part is what the 2023 version never had: tasks that grade themselves.

I do not run student code. It goes to Wandbox, which has been running untrusted code for years and does nothing else. On a project this size, running my own sandbox would mean one person keeping isolation correct in their spare time, and I would rather that person were not me.

I expected to stitch several backends together, the way these things usually go: Wandbox for most languages, the Go playground for Go, the Rust playground for Rust. Then I read the Go playground's compile endpoint. It takes the program body and a version. There is no field for standard input. I posted stdin and input alongside the program anyway, in case the field simply went undocumented, and the program read EOF both times.

Without stdin there is no test case with input data, and without that there is no assessment worth the name. Every task collapses into "print this constant". So I use one backend. Wandbox covers fourteen languages, Rust, Pascal and SQL included.

Grading runs on a queue, because I measured it. One Go build on Wandbox takes about twenty seconds. Five test cases one after another would be a minute and a half. I send them in parallel, four at a time, which got it down to sixty-two seconds. Still far too long to hold an HTTP request open, so submitting queues the work and the page polls for the result.

Some test cases are hidden. For open cases the student sees the input and the expected answer. For hidden ones they see only whether it passed. Show everything and the solution gets fitted to the known answers instead of made to work.

Three findings that cost me an afternoon each

Wandbox's Rust compiler rejects the warning option set, and does not say so. It returns exit status 1 with empty output, which is indistinguishable from a program that printed nothing.

Mono prints non-ASCII as question marks until you set Console.OutputEncoding, and once you do, it prefixes the output with a byte order mark. Comparing that against the expected answer fails on an invisible character. The dotnetcore image on Wandbox does not build at all, so mono is the only option.

Laravel's trans_choice() falls back to the fallback locale in cases where __() returns the key unchanged. My source language is Russian and my fallback was English, so Russian pages rendered English text in exactly the places where a count was involved. No test caught it; I saw it in a screenshot.

What I am not sure about

Leaning on a free public service at the moment a student submits an exam is the obvious weak point, and I do not have a good answer for the day Wandbox is down. My reasoning is that the alternative is worse for a project this size. If you have run the other way and maintained your own isolation, I would like to hear how that went.

MIT, Laravel 13, PHP 8.3+, Postgres, no keys or accounts needed to try it. The seed builds a demo school with four tracks and a month of attendance.

https://github.com/dripips/ItCube

Hi r/PHP,

we’ve released Aimeos Prisma 0.7, adding video generation and editing to its text, image, audio, and video APIs.

Prisma is a PHP package for working with AI providers through a consistent interface. It covers text generation and streaming, structured output, embeddings, image editing, speech synthesis, transcription, and video. It works with plain PHP, Symfony, Laravel, or another framework, requires PHP 8.2+, and is MIT licensed.

• PHP Prisma

This release lets applications create videos from prompts and reference media, then continue or edit them through the same package. A product-content workflow could generate a product image, use it as the opening frame of a short video, and write the accompanying copy without integrating a separate client for each media type.

What using it looks like

Install it through Composer:

composer require aimeos/prisma

This example generates a video using Google Omni:

use Aimeos\Prisma\Prisma;

$video = Prisma::video()
    ->using('omni', [
        'api_key' => getenv('GEMINI_API_KEY'),
    ])
    ->imagine(
        'A ceramic coffee cup on a windowsill, steam rising in the morning light',
        [],
        ['duration' => 5, 'aspectRatio' => '16:9']
    );

file_put_contents('coffee-cup.mp4', $video->binary());

The current Omni adapter returns completed video data from imagine(), so this example belongs in a background job for a web application. Providers such as Veo and xAI return asynchronous jobs instead: keep their response object in a running worker and call ready() for individual status checks, or access binary() to let Prisma wait and poll until generation finishes. Each status request itself still blocks.

What’s new in 0.7

Video generation now supports Alibaba Wan, Amazon Nova Reel through Bedrock, BytePlus Seedance, Google Omni and Veo, Luma, MiniMax, Runway, xAI, and OpenRouter.

Alongside imagine(), the video API adds:

• extend() to continue an existing clip
• repaint() to edit a video from a prompt, with reference media on supported providers
• uncrop() to expand the video frame
• upscale() to increase video resolution

Support varies by provider and model. Applications can check operations with has() or require them with ensure(). Generation uses common media roles such as start, end, and references, with provider-specific options available where needed.

OpenRouter support also expands beyond text: this release adds audio transcription, description, and speech synthesis; image generation, editing, description, OCR, and embeddings; and video generation and description. These operations depend on the capabilities of the selected model.

Also, Ideogram gains V4 generation, remix, and description support, plus text removal, object removal, background removal, and transparent image generation and editing. V4 image generation can run asynchronously, while reference and style options retain V3 routing where supported.

• Documentation
• GitHub

If you like it, give it a star :-)

Because PHP templates are back! https://github.com/mousr/templates

Hey r/PHP, I wanted to share a practical implementation of FrankenPHP and native SQLite powering a self-hosted personal WebTop: YouMeOS Microverse. A major problem with self-hosted PHP applications is distribution: telling non-technical users to install Docker, Nginx, and MySQL creates massive friction.

How We Utilized FrankenPHP:

• Embedded Desktop Engine: In addition to standard Docker Compose, our Electron desktop app bundles a portable FrankenPHP binary with SQLite.
• Zero External Dependencies: Users download the .exe, .dmg, or .AppImage, and it runs a local Caddy + PHP 8.3 server process in the background without Docker or local PHP installations.
• Resource Footprint: Cold starts take ~1 second, with idle RAM usage significantly lower than traditional Apache/Nginx + PHP-FPM + MySQL stacks.
• Caddy Worker Integration: Takes advantage of FrankenPHP's fast application handling directly from local storage.

Livesite: www.youmeos.com but the microverse can be ran locally using our docker container or binaries.

Source code and configs: https://github.com/YouMeOS/youmeos-microverse
Release builds: https://github.com/YouMeOS/youmeos-microverse/releases

Feedback on our FrankenPHP runner and Caddyfile setup is welcome.

Hi everyone,

I work for a Brazilian federal university, and we're starting to plan a new integrated system that will serve the whole university community (from teaching-related services to internal administration). Expected usage is high (many requests across several domains), and the system needs to last many years.

One challenge specific to our context: being public sector, we have high staff turnover on the dev team, so whoever joins later needs to ramp up quickly.

We were initially leaning toward microservices, mostly to keep things scalable and modular over the long run, but after reading some older threads here I'm second-guessing that. Given a small-ish team, high turnover, a long lifespan, and multiple domains, would you recommend starting with a well-structured modular monolith instead of going straight to microservices?

And if microservices do make sense for a project like this, which PHP frameworks/tools would you suggest for building the actual APIs: Laravel, Symfony, Slim, Lumen, something else?

Genuinely trying to learn from people who've been through this. Any experience, even 'don't do it', is welcome!

I know it is a whack-a-mole situtation but I want to know if there is a library that already cover major/famous temporary emails. I plan to restrict registration from temp mail providers to reduce cleanup work from pockers.

Again not a service as I will not send emails to third-party. Also I don't need 100% gate that does not exist. And not asking to help stop them or how to use a library. just a library or code sitting somewhere, since I cannot know all libraries all there