As Roman Pronskiy's term on The PHP Foundation Board comes to an end, he is replaced by the wonderful Brent Roose, from a unanimous vote. Welcome Brent! 🚀 And thank you for your years of dedication and commitment to The PHP Foundation, Roman! ❤️🐘

Last year I shared PHPStreamServer here.

PHPStreamServer is an event-loop-based application server and process manager built entirely in PHP. It brings HTTP serving, worker supervision, scheduled tasks, logging, and metrics into a unified runtime.

Applications remain loaded between requests, with asynchronous execution powered by Revolt event loop and AMPHP.

I've been quiet publicly since my last post. During that time, I've continued using it as the primary runtime for my personal projects and improving it based on the experience. I've now released version 0.9, the project's biggest update yet.

One of the biggest architectural changes in 0.9 is that PHPStreamServer now requires FFI. This allows it to call native OS APIs directly for capabilities such as Unix-socket peer credential verification, parent-death signaling, and native file monitoring.

Some highlights:

• Workers and scheduled tasks can now be registered and removed dynamically at runtime.
• Message-bus commands are now a public API, allowing workers to send requests directly to the master process, for example, to start or stop on-demand workers dynamically.
• The Unix-socket message bus was redesigned with security as a major focus. It now validates peer credentials and enforces source authorization, preventing unprivileged local users from managing a server running under a privileged account. Deserialization is also restricted to reject unsafe payloads.
• File monitoring now uses native inotify on Linux and FSEvents on macOS, with polling as a fallback.
• On Linux and FreeBSD, workers now use OS-level parent-death signaling, so they terminate instead of continuing as orphaned processes if the master process crashes or is killed.
• Daemon startup now waits for the master process to initialize before reporting success.
• Worker startup, shutdown, crash reporting, and log delivery are now more reliable.
• The supervisor now reports non-zero worker exits and termination by operating-system signals.
• The scheduler now supports named weekdays and months, presets such as @daily, and uses fractional-second delays for more accurate execution.
• The public API now uses consistent worker terminology across all components.
• Console and log output were redesigned to give PHPStreamServer a distinct and consistent visual identity.
• Per-process network traffic monitoring now batches and sends only traffic deltas through the message bus, reducing inter-process communication overhead.

I also refreshed the documentation website with a redesigned landing page. You can check it out here:

Documentation:
https://phpstreamserver.dev/

GitHub:
https://github.com/phpstreamserver/phpstreamserver

Version 0.9 release notes:
https://github.com/phpstreamserver/phpstreamserver/releases/tag/v0.9.0

PHPStreamServer is still experimental and not yet recommended for production use.

I'd especially like feedback from developers working with long-running PHP applications, async PHP, FrankenPHP, RoadRunner, or OpenSwoole. What would you need to see before considering an application server like this for one of your projects?

The Pop PDF library has been around for a while and just got a major facelift to support a wider range of built-in features in v6. Personally, for most of my career, working with PDFs has been a crucial part of what I do daily. This library started as my own little project years ago, but like many out there it was suited for a small set of features. If you work with PDFs in any extensive capacity, you might find yourself reaching for multiple libraries to solve you problems. Some write, but don't read. Some read, but don't write. Some just do the HTML-to-PDF thing. Others just do the merge thing.

The Pop PDF attempts to roll all of those features into one component, plus some.

Main Website: https://www.poppdf.org/

Docs Website: https://docs.poppdf.org/

Your Laravel API and your Blade UI should not own two copies of your

authorization rules.

One command scaffolds one set of services, repositories and policies —

then a versioned JSON API, a Blade UI, or both on top. The stack flag

only changes the transport.

It's not a framework. It copies real code into your app, then you can

delete the package and everything keeps working.

Policies actually enforced, no unscoped repository queries, a login

endpoint that can't be used to enumerate accounts, two CSP profiles,

no npm. Security defaults mapped to the OWASP Top 10:2025.

Laravel 10–13, PHP 8.2+, MIT. Tell me what's wrong with it.

Install

composer require cachewraith/laravel-template-structure

php artisan cachewraith:install --stack=both

Link

https://packagist.org/packages/cachewraith/laravel-template-structure

Join us for The PHP Foundation Community Hour, an interactive podcast that helps you understand how you can contribute to the PHP ecosystem! Shout-out to PHP Architect for providing the infrastructure, platform, and technical support to enable us to host these episodes. 🧡

What is the best free website to use to learn basics of PHP? Thank you!

Sometime ago I was working in a Delivery Management System, we heavily incorporated the Service Repository Pattern to support all the features and capabilities of the system that was launched after 9 months of development and testing (a team of 2 developers, 1 QA tester and a project manager).

I recently started writing an article about this pattern and my opinions about it and I started to think, how would a bigger team preferablly with a software architect would go about reading the scope and coming up with a blueprint, how much architecture is worth building upfront vs overtime?

Article I have been working on: https://blaze64.dev/logs/laravel-service-repository

For a long time I have explored a lot of modern technologies from MERN to LLM and a lot more. But I remember in 2020 when chatgpt was unknown, I had learned to build web apps using PHP and built a lot of projects using PHP. But now I wonder that there are a lot of modern technologies that offers real time data ui updation dynamically. In this time creating a web application using PHP would be a great idea or not? There are a lot about php and MERN, the very first thing matters is learning curve and for php I believe that it is quite easier to learn as compared to learning react, js and nodejs. And Second is the cost to setup. Many platforms like infinity free and a lot more provides free hosting plans for php based Web apps and provide decent storage but if we compare the same with MERN, then either the cost of hosting is quite high or free tiers offers very few resources and space.

Final verdict no doubt IS going with PHP, but I want to get opinion of others.

Please share your valuable opinion and it is requested please don't use AI by copying this message to AI and Sharing AI generated answers.

Almost none of my repos are one language. A PHP service ends up carrying Blade templates, some CSS, a bit of JS, SQL files, YAML for CI, Markdown for docs. Every one of those wants its own linter, and every linter wants its own runtime.

So the setup is a PHP install for mago or PHP-CS-Fixer, a Node install for eslint and prettier, Python for whatever is left. Then a pre-commit config gluing them together, and a hook pass that takes minutes because each tool boots a process per file.

poly is one Rust binary that runs the whole set in-process. mago is compiled in for PHP. oxc for JS and TS, biome and malva for CSS and SCSS, markup_fmt for HTML and Vue and Svelte, sqruff for SQL, taplo for TOML, rumdl for Markdown, ruff for Python. No PHP, Node or Python runtime is needed for any of it.

For a PHP repo that means poly lint checks the PHP through mago and everything around it in the same pass, driven by one poly.toml.

mago's defaults are unchanged except six maintainability metrics, which I moved from error to warning: cyclomatic-complexity at 15, excessive-parameter-list at 5, too-many-methods at 10, too-many-properties at 10, too-many-enum-cases at 20, kan-defect at 1. Turning poly on should not redden a CI that was green yesterday. Everything the cross-language quality tier reports is warning severity for the same reason.

Speed on my own machines, cold cache: Django is 3,113 files in 0.82s, home-assistant is 25,000 files in 3.5s. Those are poly's own numbers, not a comparison against mago standalone or anything else. I have not run that benchmark.

Two limitations worth stating up front. The built-in ast-grep rule pack is 26 rules across C#, Elixir, Go, Java, Kotlin, Python, Ruby, Rust and Swift, and none of them are PHP, so on a .php file you get mago plus typos plus the line-count metrics and nothing more. And Go is the one language I could not compile in, so gofmt runs as a subprocess when it is on PATH.

MIT, pre-1.0, and I am the maintainer. https://github.com/Goldziher/poly

Hi everyone,

I’ve just released the first public version of PHPFlow, an open-source static flow analyzer for PHP/Symfony applications.

The idea came from a problem I regularly run into on larger applications: answering a question like “what actually happens when this route is called?” can mean jumping through a controller, several services, Messenger dispatches and handlers, repositories, database queries and external APIs.

PHPFlow analyzes the source code without running the target application and reconstructs those flows as a graph.

For example, it can help answer:

• What happens when this Symfony route is called?
• Which routes/messages can reach this database table?
• What depends on this service?
• Where is this Messenger message handled?
• Which flows call this external API?
• Where can this exception surface?

v0.1.0 currently understands Symfony routes, dependency injection, Messenger, repositories, Doctrine DBAL/QueryBuilder, external HTTP calls, exceptions and a number of control-flow patterns.

It also generates a self-contained interactive HTML viewer with search, functional lanes, Messenger boundaries, minimap, path-to-effects and critical-path exploration.

PHPFlow is deliberately conservative: if it cannot prove a relationship statically, it doesn’t invent one. It also never boots or executes the application being analyzed.

There’s a bundled Symfony demo, so after cloning:

make setup
make demo

I’m especially interested in trying it against real-world Symfony applications now. If you give it a try and it misses a pattern used by your project, I’d really like to hear about it.

GitHub: github.com/patryyyck/phpflow

Feedback, bug reports and criticism are very welcome.

bun-php allows you to run PHP functions seamlessly in Bun by exposing them as ESM imports. Uses a WASM build of PHP under the hood, no need to install PHP or native deps. Supports Composer and servers. https://www.npmjs.com/package/bun-php

TL:DR: Static analysis tools are fantastic for IDE hints and catching syntax bugs, compile time type errors in CI, but you still need runtime verification to guarantee end-to-end type safety against dynamic payloads, compiled DI containers, and database hydrations. And PHP is not slow, its a fast language..

Sorry, English is not my native language.

I started programming in PHP for my job and I saw something that I'm not sure how to do and that is adding a new mathematical formula. To give a little context I will say that we use a simple formula to calculate something (quantity * price), now we have added two new ways to calculate.

When you create a transaction, regardless of the type, it will go through a specific function, then the first formula and the 2 new ones will go through the same place, being and serving very different things. My question is, what is the best way to handle different mathematical operations that will go through the same controller and ensure future additions?

Edit: I'm going to add an example that I gave in the comments, I hope it helps with clarity, and also writes the post better. Sorry for the inconvenience, I'm still learning from being here:

Currently the total is calculated by multiplying quantity by price. Now a function has been added, let's say for the check calculation example, where you multiply the amount by the price but the latter for this operation will be a percentage that will be divided by 30 and finally multiplied by the days that you give to this check. And let's say at the same time your partner adds a third function where the price is a percentage but not a check and you add 1 to this and then divide by the amount. We have 3 formulas in this example, the original quantity per price and the 2 new ones.

What is the way to handle the different mathematical operations of a software ensuring that more can be added in the future?

In my latest video I try and build Ai using PHP instead of python

Doctrine's FAQ says that fetching the inverse side of a one-to-one association requires an additional query because Doctrine cannot know whether the association is null or which ID to use for a proxy.

In Teradion, practice management software for accounting firms, a frequently loaded entity has three nullable inverse-side one-to-one associations. The entity is used in several list and export queries, so I am reviewing whether this mapping is still a good fit.

The options I am considering are moving ownership to the central entity where the model allows it, joining the associations explicitly on read-heavy queries, or changing the model to avoid these one-to-one associations.

If you have dealt with a similar mapping on a frequently queried entity, what did you choose? What tradeoffs showed up later?

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

10 stories this week, so let's get into it. But first, You shipped a lot of code this quarter, but do you know how much of it is actually still there? Ballast reads your git history — never your code — and scores what survives. Stable velocity, plus a durability rating between 300 and 850 — like a credit score for your codebase — updated every month, and it's free. ballast.now.

This week's top story isn't really about PHP. It's about how the internals list talks to itself. Messages have been arriving that were clearly written or heavily assisted by a large language model — that flat, over-professional register that thanks you warmly and then restates your own point back at you — and somebody finally said the quiet part in plain text. 24 messages followed, about where the line actually sits. Nobody argued against translation. English is a second or third language for a good part of that list, and that is a real accessibility question rather than a laziness one. What people object to is authorship — the argument itself being handed to a machine — and the harder problem underneath, which is that there's no reliable way to tell the difference from the outside. Nothing's been written down yet. But if you want a say in what does get written down, the community Discord is at phpc.chat, and there's an internals channel there. It's a community server, not an official PHP one. There's a thread in it working on exactly these guidelines. So if you want to head there and argue with us about what should be in the guidelines, feel free to join the discussion.

A new RFC opened on Saturday, from the same contributor whose last one had just been withdrawn. Sepehr Mahmoudi proposed array_match(), which filters an array down to the values containing a substring, implemented in C so you don't have to pay for a closure on every element. Yuya Hamada replied within the hour, asking whether array_filter() isn't already enough, pointing at a GitHub search full of userland functions already named array_match that don't all behave alike, and noting that the str_icontains RFC was declined, so an ASCII-only case-insensitive flag is a hard sell. Then Tim Düsterhus pointed out that in 8.6 this is already 1 line, because partial function application lets you drop str_contains into array_filter() with a placeholder. Christian Schneider noted that preg_grep() has done basically the same job for years.

The case against it was mostly one case, made 5 ways. Ayesh Karunaratne went after the premise, writing: "I have worked on Drupal, WordPress, Silex, and bespoke code bases, spending enough time profiling them. An array string search has never been a bottleneck." Larry Garfield called it an XY problem and said huge in-memory arrays are a code smell to begin with. mickmackusa offered the alternative nobody else had — make str_contains() polymorphic, the way str_replace() already takes an array. Sepehr has since dropped the case-insensitive flag, renamed it array_str_contain(), and moved the target to 8.7, since 8.6 is frozen. Nobody's argued in favour of it so far. The proposal, so far, contains no support.

Nick Sdot brought a documentation question to the list on Thursday. He's restructuring PHP's internals book, the docs that live inside php-src, and his first pull request converts the pages from reStructuredText to Markdown — a light 1,100-line mechanical diff that nets out 86 lines shorter. Ilija Tovilo, who set the book up, called it churn, and answered that the source is neither pure Markdown nor reStructuredText but MyST, so renaming files fixes some rendering and breaks the reStructuredText-flavoured parts. His real objection was the diagnosis. He wrote: "None of this is wrong, but I don't think the docs have stalled because the syntax is too hard. Rather, more time should be designated to them." Weilin Du and Calvin Buckley both said the effort belongs in the content. Nick's clarification explains the thread. The old docs folder he's merging in is already Markdown, so a conversion happens in one direction or the other. It's still open.

Robert Chapin spent the week working through an old RFC. Deprecate Fuzzy Type Casts, by Alexandre Daubois and Nicolas Grekas, dates to January, is still under discussion, and still targets 8.6 on the wiki — which Robert would like changed, given there's been no discussion since. His objection is that the RFC's own migration guidance doesn't hold up. He points out that with the string 1.5, is_numeric() returns true, so the validate-before-casting example still triggers the deprecation, while is_int() and is_float() return false for every numeric string. He says the filter_var() alternative doesn't guarantee an integer back either. He asked: "Are developers expected to replace a sing[le] type cast with 8 lines of code for PHP 8.6?" Nobody has answered him.

A process question opened yesterday morning. Sepehr Mahmoudi noticed that some RFCs proposing new functions include a userland polyfill and some don't, and asked whether the RFC template should recommend one wherever that's feasible. His reasons are that a polyfill pins down the exact behaviour, edge cases and all, without anyone reading the C, and that it gives teams like Symfony's polyfill maintainers an accurate head start. Larry Garfield called recommended-where-relevant-but-not-required a reasonable policy, and added a second use for it, saying: "And it would also give us a target to benchmark against to see if putting it in C really has a performance benefit." Which is exactly what 2 people spent the weekend asking Sepehr for on his other proposal.

Gina P. Banyard posted a correction on Friday to an already-accepted RFC. Steven Wilton's SNMP improvements proposal states that its target is the next stable release for all currently supported PHP versions. Gina's point is that this runs against the release process policy on patch versions, so the changes will land in 8.6 only. She also asked for a design change — the new integer constants in the output-controls section would become PHP enums instead, which improves type safety in userland and translates the C enums SNMP already defines into PHP ones. The plan is to have it merged in time for 8.6.0 beta 2.

Weilin Du, who maintains the intl extension, spent part of the week handing out work. He'd like some of the extension's constants turned into enums, proper namespaces on its classes so they stop colliding, and the remaining gaps between PHP's APIs and the underlying ICU APIs filled in. He was blunt about the error handling, writing: "the error state stuff in the extension is, frankly, bad, in my opinion, and could be optimized since it has caused a lot of very stupid bugs." He suggested the enums and namespaces could be an 8.7 RFC if somebody picks it up. Yuya Hamada added the reason it matters. Feedback from right-to-left language users is thin across the whole industry, not just PHP, and PHP's internationalisation depends on getting it.

Quick hits. array_search_range(), last week's top story, is officially withdrawn — mickmackusa posted a 7-point review hours after we recorded, and Sepehr Mahmoudi pulled it on Thursday and called it a valuable learning experience. Weilin Du's extension-name case sensitivity proposal is going to a vote, eventually. A core developer objected, which under policy makes it an RFC, and he'll open that after the 8.6 branch is cut on September 22, with both behaviours on the ballot for 8.7. And Zachary DuBois introduced himself on Thursday, asked whether adding missing libsodium functions needs an RFC or just a pull request, was told to open the pull request, and had it up by Sunday. It adds X-Wing and ML-KEM-768 bindings to the sodium extension. Post-quantum key encapsulation, arriving as somebody's first pull request. Quantum-resistant, and so far review-resistant.

So that's the week: no RFC in the voting phase for the second week running; a long argument about who is actually writing the mail on the internals list; a new array_str_contain() proposal with 5 people against it and nobody for it; a documentation pull request that turned out to be a consolidation question rather than a format preference; unanswered holes in the fuzzy casts migration path; and post-quantum crypto arriving as somebody's first pull request. Links to every thread are 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 to Ballast.now for supporting this week's episode. We're Artisan Build. See you next week.

Hey everyone, I want to show you https://echoc.dev and give some context on it :)

I'm not here to tell you "oh, this is the new shit, this is going to change PHP development." It's obviously not, and that's also not the goal.

This started as a "recreational programming" project I mostly worked on during holidays when my kid was sleeping. And I really, really enjoyed working on it.

The initial concept was:

Metal-PHP is a PHP dialect that transpiles to C++ and is compiled to a native binary.

And this is nothing new, it's pretty much what Hack was/is, and I'm sure a couple of others.

At some point I kinda just asked myself "who I was creating this for", and as the answer crystallised, "for myself", I completely shifted course.

This is not meant as PHP replacement!

I love PHP, I spent probably a thousands of hours working on php-glfw..

PHP does exactly what PHP needs to do. I personally would not migrate an existing PHP project to what I was in the process of making. And to be honest (I'm really curious how others feel here), I have not yet had a performance issue with PHP where the language itself was the problem. It always was the architecture...

It became clear to me: I want something fun, something opinionated, something I actually wanna play around with, and so it became its own language.

TL;DR: Echo does not, and will not ever run PHP.

Why am I sharing this now?

I'm having a blast writing small tools and programs with Echo, and I believe some traits of the language resonate with what some PHP devs enjoy too. (As I am primarily a PHP dev..)

But please take this as the toy it is. Don't build your startup on it and scream at me when your app is leaking customer data because of a memory leak.

What can it do?

Well its a programming language, the docs will do a far better job at explaining it then I can here.
But a few cool things that are already there:
- a tiny standard library
- basic multi threading
- generics
- simple bridging to c
- a tiny package manager
- etc..

Hey everyone. I'm pleased to announce that Qbix webserver has now reached version 1.0
It's MIT licensed and free. Try it in your own sites! Just launch it with one command, e.g.:

php qbixserver.php --port 8080

It's a standalone server that can serve
* static files without nginx (though you can still put a CDN in front)
* dynamic PHP requests (it can handle 100x more workers than PHP-FPM!!)
* web sockets (yes, it's compatible with the latest socket.io on front end)
* web socket rooms (it can handle up to 100,000 online users, on one machine)
* cron (it has a built in ability to run periodic jobs)
* certificates (it can manage certificates for you)
* even decentralized applications (server can communicate encrypted via https)

What's more, it does all this with pure PHP, without needing nginx. If you use SQLite, you won't even need Postgres or MariaDB or any other external database. Just use PHP for everything.

The server also comes as standalone binaries, so if you distribute those, you won't even need your users to have PHP installed! It *just works out of the box*. In v1.1 you'll be able to just bundle your entire app inside a standalone binary, but for now you can just distribute your apps as files alongside the webserver.

Handle 100x More Traffic than NGINX + PHP-FPM

How is this possible? Well, mostly because this server actually forks your processes using pcntl_fork (everywhere except Windows) allowing children to *share memory* of the parent webserver process. This causes the children to NOT take up any new memory pages, unless they declare new global/static variables or modify variables, in which case the operating system forks only those pages (maybe 4KB per page... rather than 50MB per worker).

So you can run 100x as many workers, and since most PHP web apps are I/O heavy, the operating system can efficiently orchestrate the rest. If you happen to also install amphp in your apps, then your apps switch from stream_select to epoll, which makes them even faster!

It's come a long way...

People here may remember when I originally announced it several weeks ago, as being able to handle 10x as many workers as NginX + PHP-FPM. Well, since then we've had various people run it in production, we optimized it to 100x as many workers, and I addressed all the issues and bugfixes that came my way. At the same time, I've enhanced the dashboard and control panel to be more user-friendly, they even now use our real-time websocket functionality.

Who am I?

Are you sure you want to know?
I'm Greg Magarshak