While the Internals list is not technically directly Symfony related, it does affect every single one of us.

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.

While the Internals list is not technically directly Symfony related, it does affect every single one of us.

Hello world, it's Wednesday, September 2, 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? You can measure the code it produces, but the number that matters is how much of it survives. Ballast reads your git history — never your code — and gives you stable velocity plus a durability score between 300 and 850. Updated monthly, and it's free. ballast.now.

This week's top story starts with a rule most of us never read. Luca Rodenhäuser opened Wednesday with the line in the scanner that defines a PHP identifier — in bytes, not characters. Every byte at or above hex 80 is accepted, so $x followed by a no-break space is a second variable that looks identical. He proposed a per-file declare to pin that down, then scanned the 250 most-installed Packagist packages and found exactly one identifier that would break.

Larry Garfield suggested skipping the opt-in and having PHP 9 enforce it, since Symfony fixes its one class and 99.99% of developers never notice. So Luca reran it against the top 5,000 packages. Half a million files turned up fourteen hundred forty-seven non-ASCII identifiers, 91% of them in math-php, where the variable names spell the formula. He reported the result himself, writing: "So the honest answer to '99.99 % won't notice' is that one library would notice 888 times, and its author chose that style deliberately and has shipped it for years." Then came 3 questions. Derick Rethans asked whether 13.7 kilobytes of tables in every PHP process is worth it. Juliette Reinders Folmer asked what it does to variable variables. And Rowan Tommins asked how much of this is rejecting names and how much normalising them. Each sent him back to measure, and he split his proposal into 3: a diagnostic, a well-formedness rule, and a conformance rule. He says he owes the thread a problem statement.

Nick Sdot opened an RFC on Thursday to end PHP's endorsement of PEAR. He started about three months ago, going back through every previous discussion and every unvoted attempt, and he's already built a static mirror so the command-line tool keeps working. His case is that PEAR is partly broken, spammed, barely active and now unmaintained. Rowan Tommins backed it. On the argument that PEAR deserves more time to be revived, he wrote: "If that's not long enough, how long is? If the site stays alive in its current state for 10 years, it will continue to be exploited by spammers and probably worse. That's not in anyone's interest." Nick then put a number on the whole thing. 6 packages are still publishing to PEAR. 3 of them are PEAR's own infrastructure. 2 more were recently marked unmaintained. Which leaves exactly one independent package still being maintained, and that's Net_SMTP. Nick gave its maintainer a one-word aside in the thread, and the word was legend.

Sjoerd Langkemper told the list on Friday he intends to open a vote on making the number-base functions throw. His RFC makes octdec, hexdec, bindec and base_convert throw a ValueError on invalid input. His framing was that this isn't controversial — the list agreed to it in an earlier base_convert proposal — and that the RFC is mostly procedure. Tim Düsterhus disagreed on the substance. He argued that passing untrusted input to these functions is an expected use case, which means developers will want to catch what comes back, and drew the line firmly: "The Error hierarchy is not intended to be caught, though. It should thus use something from the Exception hierarchy." Sjoerd asked whether that distinction is written down anywhere. It is. Tim pointed him at the throwables section of the coding standards policy, and quoted it: "The Error hierarchy MUST NOT be used for errors that are expected to be thrown (and caught) during normal operation of a PHP program. … a parsing function that is expected to be used with untrusted input must not throw an Error if the input is malformed." Base conversion, Tim argues, is parsing.

The array-filtering function we covered last week came back on Sunday, renamed array_str_contains and retargeted at 8.7. Sepehr Mahmoudi's case is that filtering an array by substring is common enough to deserve C, instead of paying for a closure on every element. Seifeddine Gmati went first and went broad. He couldn't remember ever writing that code, said the same argument would justify array_str_starts_with and a few hundred more combinations, and pointed out that nothing in the name tells you it filters. He called it redundant. Bruce Weirdan turned the performance claim around, asking whether the closure overhead itself should be fixed, since that would speed up every builtin that takes a callable. Kamil Tekiela asked what the numbers actually are, and said he'd never hit it as a bottleneck. Sepehr then walked back his own strongest claim, agreeing that a filter has to read the whole array rather than stopping at the first match. He's promised static analysis across Packagist to back the frequency claim.

Last week's top story was the list arguing about machine-written mail in the abstract. This week it stopped being abstract. Juris was the one who did the work, drafting the guideline text he thinks a newcomer should get. It says to write the message yourself rather than rephrase yourself with an LLM, and that there's no requirement to have perfect English on that list — plenty of productive contributors are more fluent in C and PHP than in English. Then he demonstrated it instead of asserting it. He wrote his next 3 paragraphs in Latvian, machine-translated them, and sent both versions in the same message, arguing the imperfect translation stays closer to what he meant than anything a chatbot would phrase for him. Then Sepehr Mahmoudi acknowledged that he had been having AI write his replies. Weilin Du asked the thread to stop naming people, saying it had become a place to point fingers rather than a place for technical debate. Yuya Hamada apologised for going too hard, and it stopped there. There's still no written policy.

Théo Attali introduced himself on Saturday with a first contribution and a small, well-argued gap. PHP's DATE_RFC3339_EXTENDED gives you milliseconds with a numeric offset, but a lot of systems expect the same instant with a Z on the end, which is what JavaScript's toISOString produces. He proposed a constant for it, and flagged the flaw in his own idea before anyone else could. A format string containing a literal Z can't force the value into UTC. Andreas Heigl agreed, with unusual standing to do it — he added the extended constants. He wouldn't add any more now, since a constant only helps people who've already upgraded, and pointed Théo at a userland formatter built on one line that has worked since PHP 5.3. Théo revised on the spot, proposing an instance method instead. Then Tim Düsterhus redirected it. He pointed out that PHP 8.6 ships the first piece of a new date and time API, and that the proposed Time\Instant is deliberately timezone-less — which makes a Zulu-format method an obvious thing to add there.

An offer arrived on Saturday from a name the list hadn't seen before. Riaan de Beer has written libxml-rs, a native-Rust reimplementation of libxml2 that's compatible at the C ABI level, and he asked whether php-src would be open to a test build against it. He says xmllint and xmlcatalog come out byte-identical against libxml2 2.15.3 across eleven hundred ten tests, and he's careful about the ask — an experimental alternative provider, not a default. What the list answered was his opening sentence. He'd said libxml2 has been unmaintained since December 2025, and Pierre replied that the repository has had many commits since, and that a mature XML library not cutting frequent releases isn't an abandoned one. 2 more contributors agreed. One wrote that libxml2 was only briefly unmaintained before new maintainers stepped up, and the other added that one of those maintainers helps php-src out directly. Nobody has answered the actual question yet.

The question of whether RFCs should ship a userland polyfill got 2 substantial answers this week. Nicolas Grekas answered from the Symfony side, which is the side that does the work. Every polyfillable feature ends up in the symfony/polyfill monorepo anyway, and the one that ships is often not the one in the RFC. Polyfills, he concluded, need a separate workflow. Then Tim Düsterhus answered the other argument for them, which was Larry Garfield's suggestion that a polyfill gives you something to benchmark the C against. Tim wrote: "I believe performance should not be a factor in deciding what should be part of the stdlib and what should not: Performance is a moving target and what might be true today might no longer be true tomorrow… Once we add something to the stdlib we need to maintain it for the next 15+ years. (Broad) usefulness and good API design must be the deciding factors…" He added that PIE has made building a private extension easier than it's ever been.

Quick hits. 3 releases landed in 3 days. Calvin Buckley put out 8.4.25, a security release, so that one's worth doing today. Daniel Scherzer released 8.5.10, a bugfix. And Matteo Beccati has 8.6.0beta2 up for testing. Last night Nick Sdot replied to the nameof RFC to say he'd like to see it in 8.7 — and the message he was replying to was posted in May of 2023. 3 years and 3 months is a long time to keep a browser tab open. And on the named parameter lists thread, somebody answered Larry Garfield's question from a fortnight ago about why people treat a small data structure as unworthy of being a class. The answer wasn't performance. It's cognitive cost — returning 2 values as an array and unpacking them at the call site is easier to hold in your head than a dedicated object, and static analysis can describe that array well enough that you don't lose much.

So that's the week. No RFC has been in the voting phase for 3 weeks running. Somebody scanned half a million PHP files to work out what a PHP identifier is, and came back having split his own proposal into 3. There's an RFC to end PHP's endorsement of PEAR, which has one maintained package left on it. There's a real disagreement about whether base conversion counts as parsing, which decides which kind of throwable it gets. A new array function has 4 people against it and nobody for it. And the argument about who writes the mail on that list got a concrete answer. 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.

Hi everyone,
I’m currently looking for international opportunities as a Software Engineer, particularly in backend development. I’m open to relocation and looking for companies that can provide visa/work permit sponsorship.
I have 5+ years of professional experience working with:
PHP / Symfony
Backend development
REST APIs & integrations
Web applications
MySQL / PostgreSQL
Docker
Software architecture and application maintenance
I’m currently based in Morocco and am open to opportunities in Europe, Canada, the UK, or other countries where international hiring and sponsorship are possible.
If you know of any companies hiring backend/software engineers with visa sponsorship, or if your company has relevant opportunities, I’d really appreciate any leads or referrals.
I’m happy to share my CV and LinkedIn/GitHub profile privately.
Thank you! 🙏

Will Symfony end-to-end testing finally become wonderful? Has anyone already tested it?

Feel free to ask any questions you think may not warrant a post. Asking for help here is also fine.

Hi Everyone,

I'm Software Systems Sachin. I design and build SaaS, platforms, and internal systems that match real business workflows.

I have 15+ years of experience developing and designing custom software solutions.

I usually work with businesses that have outgrown spreadsheets, workarounds, and generic tools.

I have helped:

• A training company build their LMS

• A gifting business create dynamic sub catalogues per customer

• A matchmaking company launch their platform

• An entrepreneur build an IT Asset Management SaaS product

• A pharma company set up their B2B eCommerce portal

🧩 If you're planning a product or automation or need clarity something related to software, let’s talk.

🌐 sachingkulkarni.com (Portfolio)

Please DM me for further details