PHP: The latest news in the PHP world

Weekly help thread

2026-07-06T06:00:05+00:00

Hey there!

This subreddit isn't meant for help threads, though there's one exception to the rule: in this thread you can ask anything you want PHP related, someone will probably be able to help you out!

submitted by /u/brendt_gd
[link] [comments]

Pitch Your Project 🐘

2026-06-19T08:00:29+00:00

In this monthly thread you can share whatever code or projects you're working on, ask for reviews, get people's input and general thoughts, … anything goes as long as it's PHP related.

Let's make this a place where people are encouraged to share their work, and where we can learn from each other 😁

Link to the previous edition: /u/brendt_gd should provide a link

submitted by /u/brendt_gd
[link] [comments]

This Week In PHP Internals | July 8, 2026

2026-07-09T00:53:57+00:00

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

This week's episode is brought to you by Ballast. Your team ships constantly — but how much of that work actually lasts? Ballast reads your git history and computes a deterministic durability score: does shipped code hold up, or churn and get redone? Ballast is in early access now at ballast.now.

This week's top story is still Gina P. Banyard's Deprecations for PHP 8.6 — the annual bundle where every removal gets its own ballot — and this week it caught fire twice. First fire: the long-array question. With Seifeddine Gmati's list() deprecation already on the table, Tim Düsterhus floated a draft that turns array() into a real cast function — and Michael Morris erupted at where that road leads. He asked, "Are you crazy?" — deprecating array() would, by his math, touch 3 quarters of WordPress core and nearly every plugin. Seif's counter was all receipts: the rewrite is one ast-grep command, array(...) and [...] compile to byte-identical opcodes — and, for the record, "The proposal is to deprecate list(), not array()." Then Juliette Reinders Folmer — who maintains the WordPress Coding Standards — corrected everyone: WordPress still supports PHP 7.4, and short arrays were blocked there for years by a handful of core committers, not the community.

It got personal — Morris told Seif to step out of his ivory tower; Seif kept answering with engineering. He wrote: "I've written a compiler that migrated a multi-million-line codebase from one language to another, automatically, overnight. Swapping one AST node for another that is literally equivalent to the compiler is not a feat of engineering courage." To Morris's credit, when told he was turning it personal, he replied: "I am, and I apologize." — and the thread cooled.

Then Monday it reignited — over evidence. Gina regrouped the list, folded in new items sent to her directly, and set the clock: "If none are added or amended, I will initiate a call to vote next week." Rowan Tommins counted 35 proposals and only 8 with any discussion of who'd be affected, and threatened to cast 27 blanket no votes. Gina drew her line: "You are free to do as you please." — she won't produce metrics for the sake of metrics without an agreed method. Rowan held firm: "I do not think we should be removing features without thinking about who will be affected. I'm honestly shocked that that's a controversial opinion". Juliette, once again the bridge, renewed her offer to generate real impact data with PHPCompatibility — feasible, she says, for about 25 of the 36 items. One item is on its way out: the by-reference-return-modifier deprecation — Bob Weinand recommended a complete retraction, and its proposer had already offered one. The RFC freezes July 13 — expect the call to vote next week, though with the mandatory 14-day cooldown after Gina's latest changes, actual ballots open July 21 at the earliest.

Tim Düsterhus and Derick Rethans' Time\Duration class — the stopwatch value object aimed at 8.6 — got called done this week: "we would consider the RFC to be complete". The final decisions: add and sub won an informal PHP Foundation Slack poll unanimously; the past-tense method suffixes are gone; divideInto() got pushed to future scope; and the ban on negative constructor arguments stays, on Derick's call. One naming question goes to the voters as a secondary vote: full names like multiplyBy and absolute, or abbreviations like mul and abs — with the abbreviations needing a 2-thirds supermajority.

But one fight would not close: fromSeconds(). It takes seconds plus a nanoseconds argument, capped at 999 million 999 thousand 999 — overflow is rejected, not carried. Marc B. objected: "It makes it simple to reason about for you as implementing it - it forces the burden to the one using the API." Pierre Joye brought prior art: Java and Rust both carry the overflow instead of rejecting it, and JavaScript's Temporal doesn't impose the cap either. Tim's defense: an injective constructor means one value, one spelling — a form asking for seconds should reject out-of-range input the same way June 31 should be rejected, not silently become July 1. Neither side budged — and with the RFC complete, that question rides along to the vote.

Function autoloading now has 2 competing designs, and they met in the same inbox on the same day. Paul M. Jones updated his mark-5 RFC — that's attempt number 5 — adding a declare(strict_namespace=1) directive to kill the global-fallback edge case, plus research across the top 1000 Packagist packages: exactly 2 packages and 8 call sites would misbehave. Meanwhile, Michael Morris — fresh off the deprecations thread — had floated an idea on July 2, saying: "An idea that popped into my head an hour ago, that I don't have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?" Five days later that spitball was a formal draft: autoloader callbacks that take 2 arguments — the class and the namespace — firing the first time the engine meets a namespace. And within hours of Paul's update, Morris was in Paul's thread advertising his rival.

The reason the spitball grew legs is Rowan Tommins. His endorsement became the backbone of Morris's draft — he wrote: "This really nicely side-steps the global-vs-namespace sequence problem that function autoloading always runs into: by the time the engine reaches an unqualified name, the namespace loader has already run for the current namespace, and defined any functions it wants." Not everyone's sold. Aleksander Machniak flagged that passing null to existing string-typed autoloaders is itself a BC break, and Alex Rock argued the draft bundles 2 different proposals and called it overkill. Morris's reply had some edge: "And you've misread the proposal entirely."

The busiest brand-new thread: Matheus Martins revived typed closures — write Closure(int): bool as a parameter type, and a mismatched callback fails at the boundary with a clean TypeError instead of exploding deep inside your filter(). The reception was warm — Matthew Weier O'Phinney would find it "very useful", and Larry Garfield is in favor, to nobody's surprise. Rob Landers suggested waiting for generics; Seif pointed out that would need variadic generics, which have never appeared in any proposal — waiting for generics means waiting indefinitely. Larry was blunter: "Generics syntax is the wrong format to use for this, full stop." The real villain is the lexer: inside Closure(int), that (int) is a cast token. Osama Aldemeery, who's been down this exact tunnel, put it memorably: "So the natural spelling is, unfortunately, the engine-hostile one."

Where it landed: inline signatures first, named type-aliases later, and neither blocks the other. Larry pre-empted the objection everyone could see coming — if someone gets fussy about long signatures, the answer should be "that's nice, go work on aliases then and don't block this RFC". By Monday he'd added just one ask: invokable objects should fit through the same door, not get squeezed through closures.

Rob Landers' primary constructors — the constructor hoisted onto the class line — spent June fighting over whether it may carry a body. This week that fight hit its endgame, in a single day of posts. Rowan Tommins came off the fence — with a body bolted on, he'd be a definite no. Rob, the author, declined to relitigate: "All I can say is that I reject it for future scope, repeatedly." Nick Sdot stood down under protest, warning: "We don't need more half finished, half not working, confusing features in PHP." And then, quietly, the week's one unreserved fan — a reader who wrote that extending third-party classes and calling the parent constructor by hand "always felt dirty". The thread's been silent since July 1.

Michal Kral's scalar object methods — (3)->pow(2), dispatched at compile time — came back for round 2, and the room steered it somewhere new. Michal gave real ground: he'd restrict or drop the file-order-dependent form, and lean on typed locals for safety. Seif stayed unmoved, arguing: "Seeing $s->trim() where $s is a string, I should know it works. A construct where identical AST dispatches or doesn't depending on file position, a redundant cast, or whether a declaration sits above or below the call is not something people can reason about." Then Larry Garfield reframed the whole conversation: a small curated set of methods, he said, "is bikeshed bait, and needlessly limiting" — and counter-pitched Kotlin-style extension functions on any type, from a design he drafted with Sara Golemon. Michal's response? Genuinely interested. They're talking off-list once Larry's back from vacation.

To the scoreboard — one ballot closed, one never opened. Jordi Kroon's third-party extension documentation RFC is in: 26 to 1, with 1 abstention. The secondaries settled too: the docs land on a php.net subpath rather than a new subdomain, 15 to 8, and the old user notes get dropped in the move, 21 to 4. Meanwhile the grapheme_mask vote that was announced for July 3? As far as we can tell, it never opened — the RFC page still says draft, and the feedback stayed kind but firm. Yuya Hamada wrote: "Thank you very much for your RFC. But move to voting phase is too fast." The pipeline ahead is stacked: deprecations expects its call to vote next week, and Duration finishes its cooldown just in time for the mid-August freeze.

Quick hits — and there are a lot, so this is a 2-slide round. July 2 was patch day: security releases for 8.2, 8.3, 8.4, and 8.5, and 8.6.0 alpha 1 is out for testing. Eric Norris and Tim Düsterhus published the minimum-supported-versions RFC — newer autoconf, and MySQL 5.7.3 or MariaDB 10.2.4 for persistent connections — and an anonymous tester promptly found a real connection leak on old MySQL, declaring: "There is connection leak here!" — Eric's tracked down the cause and is weighing a fix. Nicolas Grekas redesigned serializable closures and offered a slimmed-down fallback, nudging the list that 8.6 won't wait. Osama Aldemeery floated a PREG_THROW_ON_ERROR flag — implementation already built. And Nick Sdot posted a tiny RFC: default values on readonly properties, a 5-line removal — zero replies so far.

Still going. Literal scalar types turned into an enums-versus-literals standoff, where Nick warned: "We should not make PHP another TypeScript." Ben Ramsey added a Foundation-SIGs section to Working Groups and wants feedback before he votes it — or withdraws it. The DTLS experiment graduated to a working 1.2 branch; Jakub Zelenka wants a draft PR. Pierre Joye synced bundled GD with libgd 2.4 and is untangling Windows dependencies. Pratik Bhujel's terminal helpers got Derick's blessing — ship it via PIE, since PECL takes no new packages. And Pratik also asked whether fixing sscanf's %c whitespace bug — in place since PHP 4.3.2 — breaks anyone on master.

So that's the week: a deprecations list that fought about WordPress and then about evidence, with the call to vote days away; a Duration RFC wrapped up and waiting out its cooldown; 2 rival answers to function autoloading colliding in real time; typed closures winning the room while the lexer holds the door; and the one ballot that closed, passing 26 to 1. Links to every thread are below. We're Artisan Build. See you next week.

submitted by /u/ProjektGopher
[link] [comments]

RFC: Function Autoloading (mark 5)

2026-07-08T02:51:15+00:00

submitted by /u/jmp_ones
[link] [comments]

Immutable Versions on Packagist

2026-07-07T21:28:27+00:00

submitted by /u/naderman
[link] [comments]

PHP Map 4.0: Arrays and collections made easy!

2026-07-07T10:25:16+00:00

PHP Map version 4.1 is now available, the PHP array/collection package for working with arrays and collections easily.

https://php-map.org

The release is mostly about improving performance of edge cases in the collection internals, plus stricter behavior around malformed input.

Some benchmarks from the release commits:

Method / path	v4.0	v4.1	Improvement
`isList()`	857.993 ms	0.643 ms	99.93%
`tree()` 20k chain	8523.8 ms	47.6 ms	99.4%
`diff()` array fallback	376.1 ms	3.5 ms	99.1%
`intersect()` array fallback	390.5 ms	13.2 ms	96.6%
`find()` reverse	417.330 ms	47.152 ms	88.70%
`findKey()` reverse	416.939 ms	47.737 ms	88.55%
`suffix()` string	259.5 ms	93.1 ms	64.1%
`flat()`	338.8 ms	123.8 ms	63.5%
recursive `walk()`	277.0 ms	103.9 ms	62.5%
`suffix()` callback	318.1 ms	124.5 ms	60.9%

The release also adds broader callable support, better iterable handling, clearer null-vs-missing behavior for nested paths, stricter invalid-key validation, and a more robust tree() builder.

Why PHP Map?

Instead of:

$list = [['id' => 'one', 'value' => 'v1']]; $list[] = ['id' => 'two', 'value' => 'v2'] unset( $list[0] ); $list = array_filter( $list ); sort( $list ); $pairs = array_column( $list, 'value', 'id' ); $value = reset( $pairs ) ?: null;

Just write:

$value = map( [['id' => 'one', 'value' => 'v1']] ) ->push( ['id' => 'two', 'value' => 'v2'] ) ->remove( 0 ) ->filter() ->sort() ->col( 'value', 'id' ) ->first();

There are several implementations of collections available in PHP but the PHP Map package is feature-rich, dependency free and loved by most developers according to GitHub.

Feel free to like, comment or give a star :-)

Documentation: https://php-map.org
Repo:https://github.com/aimeos/map

submitted by /u/aimeos
[link] [comments]

Getting started with PHP: looking for feedback

2026-07-07T08:57:10+00:00

Hi /r/php

A common question we see on this subreddit (and many other places) is people asking how to get started with PHP. Especially on this sub we often link to PHP the right way. It's definitely a good reference that links to many other resources, but I recently read through it and realized is not designed to be a proper "getting started guide".

Having done lots of educational content in the past, I'm really longing for something that teaches modern PHP in a written form, that people can read on its own which makes them feel comfortable actually picking up PHP. I don't think PHP currently has that: all current options are either outdated, video-only, or paid courses (but feel free to tell me I'm wrong).

So I've started a new project: a proper "getting started with modern PHP" guide that I feel confident pointing beginners to when they ask "how to learn PHP?". You can read the first eight chapters today: https://stitcher.io/php/the-basics/hello-php and I'm planning on adding many more in the near future.

Now, here's what I need help with: I'm only one person. I dare say I'm experienced in PHP, but I'm also sure I'm making mistakes and oversights. I'm hoping enough experienced PHP developers share my longing for something better, and want to help out. Either by reviewing what's written, pointing out or fixing mistakes, or maybe even by writing drafts for upcoming chapters.

Looking forward to hearing your thoughts!

submitted by /u/brendt_gd
[link] [comments]

I keep trying other languages... and somehow always end up back in PHP

2026-07-07T20:12:38+00:00

Over the years I've worked with Java, Python and a few other languages.

They're all good at different things, but somehow I always end up writing PHP again. I guess it just feels like home. Open the project and everything feels so familiar. ))

That gave me the idea to make a funny parody of the one classic hit song (from the 70s), but for PHP developers.

Nothing serious, no language wars – just a bit of fun for anyone who's ever left PHP and then came back.

🎬 https://youtu.be/SoqAP4gSDac

Has anyone else had the same experience like me?

submitted by /u/Few-Mycologist7747
[link] [comments]

Lattice 0.17 now supports Notifications

2026-07-07T17:15:26+00:00

submitted by /u/bambamboole
[link] [comments]

Just shipped Laravel Doctor: the Laravel checks your static analysis misses

2026-07-07T19:19:53+00:00

submitted by /u/3liusef
[link] [comments]

I built a fast, lightweight web server for Android (No root required)

2026-07-06T19:30:19+00:00

I've been working on a project that turns an Android phone into a lightweight local web server using Termux.

It runs Nginx + PHP-FPM + MariaDB and includes a web-based control panel, one-click WordPress installation, virtual hosts, Tiny File Manager, browser-based terminal access, and built-in Cloudflared tunnels for sharing local sites.

The main goal was to keep it fast, lightweight, and easy to use—no root, no PC, and no Docker required. Everything is managed with simple commands like "ms start" and "ms stop".

If anyone is interested in running a portable PHP development environment or hosting small projects directly from an Android device, I'd love to hear your feedback.

GitHub: https://github.com/SayfullahSayeb/mobile-server

submitted by /u/FantasticTourist5935
[link] [comments]

My Symfony page made 87 queries. This profiler tab found the N+1 in 2 seconds.

2026-07-07T12:09:16+00:00

Before: page felt slow, no idea why.

After: opened the profiler, it pointed straight at the N+1. 87 queries → 3 after the fix. It's a bundle that reads your Doctrine queries in the Web Profiler and flags N+1s, slow queries, and missing indexes, with the fix suggestion right there.

Repo: https://github.com/ahmed-bhs/doctrine-doctor

submitted by /u/Total_Ad6084
[link] [comments]

Looking for feedback on Abstrax, a CLI for common PHP server admin tasks

2026-07-06T21:39:00+00:00

Hey all,

I manage a few servers for my day job, and we’re not able to use something like Forge. Managing a server isn’t the most complicated thing in the world, but there are a few tasks where I always struggle to remember the exact syntax, or where I just want something a bit quicker than digging through notes.

I know aliases and scripts could solve a lot of this, but I started wondering whether it would be useful to have a small CLI abstraction layer for common server admin tasks.

So, admittedly with a little help from our good friend AI for some of the more complicated Go sections, I put together a CLI app and started using it to manage servers, SSH keys, projects, nginx, PHP, SQL, and a few other bits.

I ended up really liking it, showed it to a friend, and he suggested I tidy a few things up and open source it.

So I did that, and it has grown a bit since then. It now has a plugin system (although no production ready plugins exist yet), and full documentation for the commands it currently supports.

One thing I’d like to add eventually is support for other Linux distros that do things differently. That will probably come later, but I do have a few servers that would benefit from it.

I know a lot of people will prefer working directly with Linux, or using a platform like Forge or Ploi, but I thought this might be useful to some people who want a memorable CLI for common server tasks.

If you’re interested, you can check it out on GitHub:

https://github.com/useabstrax/abstrax

Or the main site:

https://useabstrax.com

submitted by /u/snsmurf
[link] [comments]

I tried FrankenPHP on our (externally heavy I/O) workload and it wasn't worth it

2026-07-05T14:31:06+00:00

I spent a few hours playing around with FrankenPHP on a fleet of servers that run as a microservice, their sole purpose was getting a request in, making external calls to 3rd party APIs/websites, and returning the result (the kind of microservice that should really be rewritten in something like Golang, but that's for later).

I wanted to test if we could speed things up by moving from PHP-FPM to FrankenPHP, but after intensive testing, it isn't worth it for us. I could've predicted this, but wanted to test it anyway :D

tl;dr: if you only spend < 1% of the PHP lifecycle bootstrapping the framework, and the other 99% waiting on external I/O (whether that's database/cache/api), you're not going to see the gains.

More details are up on my blog: https://ma.ttias.be/laravel-octane-vs-php-fpm-lessons-learned/

submitted by /u/Mojah
[link] [comments]

PHP 8.5.8 and 8.4.23 are out - important fixes

2026-07-05T10:46:39+00:00

PHP pushed maintenance releases for its two active development branches on July 1–2, 2026. PHP 8.5.8 and 8.4.23 are out. Neither is a major feature release, but they fix issues that can cause real harm to production servers. If you’re hosting PHP applications, patch now.

https://blog.kalfaoglu.net/posts/2026-07-05-php-8423-858-security-patches-en/

submitted by /u/Grumpy-Man19
[link] [comments]

Keep Composer dependencies up-to-date with Dependabot

2026-07-06T09:06:58+00:00

This new guide explains how you can use GitHub's Dependabot to keep your project's Composer dependencies up-to-date.

Dependabot can create PRs to update your dependencies, both for routine version updates as well as for security updates (which patch a vulnerability).

Setting up Dependabot with a minimal configuration is not much work, but this article dives deeper in how you can optimize the configuration to keep the work of reviewing and merging the PRs manageable. It also goes into some specifics about handling Symfony version updates, Private Packagist (and other private Composer registries) and how Dependabot can help reduce the risk of supply-chain attacks.

https://nth-root.nl/en/guides/keep-composer-dependencies-up-to-date-with-dependabot

submitted by /u/nicwortel
[link] [comments]

I got tired of copy-pasting the same PHPStan/Pint/Pest setup into every Laravel repo — and my AI agent kept ignoring the rules anyway. So I fixed both.

2026-07-05T22:14:55+00:00

The problem

Every time I spun up a Laravel project, I'd do the same dance: copy phpstan.neon from the last repo, copy pint.json, wire up Pest, set up a pre-commit hook, write a CLAUDE.md full of engineering rules… and then drift would set in. Repo A was on PHPStan level 5, repo B on 7. One had architecture tests, the others didn't. The "rules" lived in my head.

Then I started leaning on AI agents (Claude Code, Cursor, Copilot) and a new problem showed up: the agent would happily ignore the conventions. It'd write untyped code, skip tests, invent patterns the rest of the repo didn't use. A CLAUDE.md full of rules helps, but rules a model can choose to skip aren't guardrails — they're suggestions.

What I wanted

One command to set up a fresh Laravel repo with the same guardrails every time.
A quality gate the agent literally cannot skip — not just docs it might read.
The same gate running everywhere: at commit time, at the end of every AI turn, and in CI. If it passes locally it passes in CI, no surprises.

What I ended up building

A small Composer dev package. You run:

```bash composer require --dev mohamed-ashraf-elsaed/claude-kit php artisan claude-kit:install

It detects your frontend stack (Inertia+Vue, Inertia+React, Blade/Livewire, or API-only), asks what you actually want (PHPStan? which level? strict-rules? Pest or PHPUnit? coverage threshold? arch tests? git hooks?), and scaffolds it — without clobbering existing files (composer.json / package.json get merged, not overwritten).

The part I care about most: the quality gate is one shell script (Pint + PHPStan level 7 + strict-rules + Pest with an 80% coverage gate + frontend lint) that backs three things — the git pre-commit hook, Claude Code's Stop hook, and the CI workflow. So the AI agent's turn doesn't "finish" until the gate is green. Same script everywhere = no "works on my machine, red in CI."

There's also a hybrid update model: the machinery (the gate script, the hook) is referenced from vendor/, so a composer update propagates fixes to every project. The content you own (CLAUDE.md, linter configs, skills) is written into your repo so you can edit it freely.

It's MIT, PHP 8.2–8.4, Laravel 11/12/13. Repo + docs: github.com/mohamed-ashraf-elsaed/claude-kit

The actual question I'm curious about: for those of you using AI agents on real codebases — how are you enforcing conventions? Just prompt/CLAUDE.md, hooks like this, CI-only, or something else? Genuinely want to hear what's working, because the "agent skips the rules" problem feels underrated.

submitted by /u/MissionArea990
[link] [comments]

I built a static analysis tool that finds require_once statements your Composer autoloader already covers

2026-07-04T14:56:40+00:00

Working on legacy codebases, I kept running into the same thing: hundreds of

require_once statements that predate Composer, still sitting there years after

autoloading was set up. Deleting them by hand means answering "is this class

actually autoloadable?" for every single line — so nobody does it.

So I wrote depone: https://github.com/lll-lll-lll-lll/depone

What it does:

- Tokenizes every PHP file and statically evaluates each require_once path

(concatenation, __DIR__, dirname(), define()'d constants)

- Checks the resolved target against your composer.json autoload config

(psr-4, psr-0, classmap, files, autoload-dev)

- Reports what's redundant — and just as importantly, reports what it

*couldn't* resolve and why, so nothing is silently skipped

- `--trace` shows reverse require-paths from entrypoints, for a final sanity

check before you delete anything

PHP 8.1+, MIT licensed, installable via Composer. It deliberately does one

thing only. Would love feedback, especially weird require_once patterns from

real legacy projects that break the evaluator.

submitted by /u/OutrageousMeringue43
[link] [comments]

Ran real PHP applications as TypeScript on Bun 1.3.14; migration from Node was mostly a non-event

2026-07-05T09:59:06+00:00

submitted by /u/Typical_Ad_6436
[link] [comments]

AI insulted my ancient PHP code 😁

2026-07-03T18:36:04+00:00

A couple of years ago I posted about an old website that I coded in the early-mid 2000s and wanted to start up again via some ancient unmaintained Docker containers. The main conclusion of that thread was that it might be possible to resurrect it with some work, but that it would be better to just (hu)man up and update the code so it would run in modern PHP versions.

Well, a couple of days of vacation and a whole bunch of free Github Copilot tokens later, it's up and running on the home network under PHP 8.2 and MySQL 8.0. According to Copilot, this was the furthest it could go with minor changes.

When I asked Copilot about how my code looked, it gave me the following opinion

The main gap is not PHP 8.2 compatibility anymore; it is that the app is still built like a 2000s-era script. [...] In short: the app needs a structural refactor, not just syntax updates.

Darn AI, no one asked for your honest opinion! /s

submitted by /u/peperazzi74
[link] [comments]

I set out to argue against deprecating PHP's metaphone(). Then I read the RFC.

2026-07-03T13:21:13+00:00

A while back an RFC landed on internals to deprecate metaphone(). My first reaction was the reflex of an old release master: leave the legacy string functions alone, people depend on them, deprecation churn is its own tax. I was ready to argue against it.

Then I read the reasoning and looked at what phonetic name matching is supposed to do in 2026, and I changed my mind. metaphone() is the original 1990 algorithm: English-only, single-key, tuned for one accent of one language. It was superseded by Double Metaphone in 2000, which emits a primary and an alternate key. Core shipped the first version and never moved. soundex() is older still, a 1918 patent. For the one job these functions exist to do, collapsing names that sound alike but are spelled differently, they are the weakest tools in the drawer. The deprecation is defensible.

Where I part ways with the RFC is the replacement. It points at userland Composer libraries. But phonetic encoding is a hot inner-loop operation, run over every name in a dataset to build a match index. A pure-PHP implementation pays interpreter overhead on every character. The honest replacement for a native C string function is another native C string function. That performance gap is the whole reason this code lived in core to begin with.

So I built the thing the RFC should have recommended: iliaal/phonetic, a native extension with the five encoders core never had, plus a comparison helper per algorithm.

php double_metaphone_match("Catherine", "Kathryn"); // 2 (primary keys agree) dm_soundex_match("Moskowitz", "Moskovitz"); // true (one surname, two transliterations) bmpm("Garcia", BMPM_SEPHARDIC, BMPM_EXACT); // "garsia|gartSa"

Double Metaphone is the fast general default. Beider-Morse (BMPM) is language-aware and matches across transliterations and scripts. Daitch-Mokotoff is the genealogy standard for Eastern-European and Ashkenazi surnames. NYSIIS and Match Rating are cheap English second keys. The helpers matter because each encoder answers "do these sound alike" differently (two keys, a code set, or a threshold), which is exactly where userland code quietly gets it wrong.

BMPM is slow, roughly 60x a Double Metaphone call, so you pick it for recall, not throughput. These are heuristic, culture-bound, Latin-script encoders, not a universal global-name solver.

One aside r/PHP might appreciate: the BMPM rule data is a licensing trap. The canonical PHP reference and the abydos Python port are both GPL-3.0 because of that data. I vendored the identical tables from Apache Commons Codec under Apache-2.0 to keep the extension BSD/Apache-clean.

sh pie install iliaal/phonetic

Repo: https://github.com/iliaal/phonetic

Happy to answer questions, especially from anyone doing record linkage or dedup across messy person data.

submitted by /u/Ilia0001
[link] [comments]

I built a Laravel-inspired framework for structuring WordPress plugins: Nikogin (open source)

2026-07-04T13:20:41+00:00

submitted by /u/PhPWellphant
[link] [comments]

I built a small PHP package for reversible text transformations

2026-07-03T14:44:31+00:00

submitted by /u/Omar_Ess
[link] [comments]

PhpStorm Light — experimental lightweight build

2026-07-02T19:39:47+00:00

submitted by /u/thejoyofbeing1
[link] [comments]

I built a modern, open-source PHP code obfuscator (YakPro alternative)

2026-07-04T11:41:31+00:00

About four months ago, my release pipeline suddenly broke because the official repository for YakPro Obfuscator simply vanished.

I was looking for a simple, effective way to add a layer of protection to my suite of AI-driven WordPress plugins before distributing them. I didn't want to rely on something like Ioncube because not every hosting provider supports the extension.

Since I couldn’t find a maintained alternative that reliably supported modern PHP syntax, I decided to build one.

I've been using it successfully in my own production pipelines for the last few months. It became pretty stable, so I wanted to announce it to the world.

Features

Full Modern PHP Support: Built on nikic/php-parser v5.x, supporting named arguments, enums, match expressions, readonly properties, intersection types, and even PHP 8.5's pipe operator and (void) cast.
Deobfuscation Resistance:
- Opaque Predicates: Hard-to-analyze expressions in control flow flattening.
- Dead Code Injection: Branches that never execute but confuse static analysis.
- Per-file XOR Encoding: String literals are encoded using unique random keys.
Incremental Processing: Only process changed files since the last run.
Multi-pass Analysis: Scrambles symbols consistently across your entire project.
Clean Architecture: Modern PSR-4 OOP codebase with 100% test coverage for core components.

Ready for CI/CD, not just local machines

I included a ready-to-use GitHub Action, making it easy to integrate into your existing CI/CD pipeline. Every tagged release or production build can produce consistently obfuscated code without anyone remembering to run another command.

Add it to your release Github Action to obfuscate your code automatically:

steps: - uses: iserter/php-obfuscator@v0.1.7 with: source: 'src' output: 'dist'

Available on Packagist/Composer too.

Install:

composer require iserter/php-obfuscator --dev

Use:

vendor/bin/obfuscate src/ -o dist/

Or use via Docker

If you’re a hygine freak for your host system, then here’s how you can use via Docker:

docker run --rm -v $(pwd):/app iserter/php-obfuscator src/ -o out/

See it on Github:

Repository:

github.com/iSerter/php-obfuscator

submitted by /u/iSerter
[link] [comments]