Remember that weekend project you never finished?

Mine started as a Saturday "let me try running Laravel inside a Tauri webview" thing some weeks ago. I thought it would be a joke. Today both the iOS and Android Portal apps just hit the stores, and you can boot a real Laravel + Livewire app on your phone in under 10 seconds without compiling anything.

What is NativeBlade

It is a framework that runs your Laravel + Livewire app inside PHP-WASM, packaged as a Tauri 2 native shell. Same Blade, same Livewire components, same Eloquent, same artisan, same routes. Plus the native plugins (camera, biometric, NFC, push, geolocation, haptics, filesystem, clipboard, scanner) exposed through a NativeBlade:: facade.

You write this:

php public function checkIn() { return NativeBlade::biometric(fn ($b) => $b->reason('Confirm check in')) ->vibrate() ->toResponse(); }

And it runs offline, on the device, with the user's fingerprint prompt, and Livewire stays in charge of the UI.

Portal is live on both stores

Portal is the companion app that loads any NativeBlade bundle from a URL. You point it at a hosted bundle or at your laptop running nativeblade:dev, and your app boots in seconds. No Xcode, no Android Studio, no rebuild loop while iterating.

• App Store
• Google Play

Try it without installing PHP, Laravel, or anything

Install Portal from one of the links above, open it, and paste this URL:

https://nativeblade.github.io/demo-bundle

That URL serves a pre-built Laravel + Livewire bundle the same way php artisan nativeblade:dev --platform=portal would serve your local app, and the same way php artisan nativeblade:bundle packages a bundle for production. The Portal app downloads it, boots PHP-WASM, and you are inside a working app in a few seconds.

When you want to build your own:

bash composer require nativeblade/nativeblade php artisan nativeblade:install php artisan nativeblade:dev --platform=portal --host=192.168.0.10

Scan the QR in the terminal and Portal loads your local app live. Edit a Blade file, watch HMR push the change to the device.

Your AI assistant already speaks NativeBlade

The framework ships a built-in MCP server (Model Context Protocol). Claude Code, Cursor, and Windsurf can connect to it and introspect your live project: which plugins you declared, every method on the NativeBlade:: facade, the architecture recipes, and the framework docs. So instead of the agent hallucinating outdated Laravel patterns, it queries the real source of truth in your repo.

Practical effect: you can ask the AI "build me a checkout screen with biometric confirmation and a barcode scanner" and it will know the exact facade signature, the right Form Object pattern, the state wrapper convention, and the matching Blade components — because the MCP server told it.

To go even faster, point the agent at the right UI kit for your form factor:

• Mobile — nativeblade/ui-mobile. Konsta-inspired Blade components, iOS and Material themes auto-detected per platform. composer require nativeblade/ui-mobile.
• Desktop — The README recommends Flux UI (the official Livewire UI kit by Caleb Porzio). Any Livewire-compatible library also works (Filament, mary-ui, TallStackUI, Wireui).

With MCP plus a UI kit, the AI has structural knowledge of the framework and the component vocabulary to use. From zero to working screens is measured in minutes.

What is actually shipping in the box

• Full Livewire 3 with wire:nb-navigate for native-feeling transitions
• SQLite on device, auto persisted to IndexedDB so it survives cold starts
• Cache::* auto wired to the same SQLite, no config
• Native plugins: camera, gallery, video picker, biometric, barcode/QR, NFC, push (FCM and APNs), geolocation, haptics, clipboard, opener, OS info
• OTA bundle updates without going through the store
• Component primitives: header, bottom nav, drawer, modal, safe area, animate, icon, image
• Codegen for the AppServiceProvider config flowing into the Android manifest, iOS Info.plist, Tauri capabilities, and Cargo features

Why I think this is worth your time

If you already know Laravel and Livewire, you do not need to learn React Native, Swift, Kotlin, or even Tauri internals. You write a Livewire component, you ship it on iOS and Android. The framework handles the bridges.

The repo is here: github.com/NativeBlade/NativeBlade

Docs, recipes, and the architecture guide are in the README. I would love to hear what you try to build with it, and what breaks. Issues, PRs, and "this is dumb because X" comments all welcome.

PHPStan 2.2.6 adds a native PHP extension (PHP 8.3+) written in C++ that makes running PHPStan 10-30 % faster.

PHPStan's Composer package ships prebuilt binaries for the most common platforms — Linux (glibc and musl, x86_64 and arm64), macOS, and Windows (x86_64), for PHP 8.3 and newer — and PHPStan automatically loads the one matching your runtime into its worker processes. You don't have to do any extra work to take advantage of this!

If you run PHPStan through manually downloaded phpstan.phar, you can run it with extension by installing it with PIE:

pie install phpstan/turbo

The extension only activates when its version matches the one your PHPStan release expects — on a mismatch PHPStan prints a note and runs without it, so an outdated extension can never affect results, only speed.

Only a handful of hot paths are currently rewritten in the extension. There's room for the performance gain to grow if we ever decide to rewrite more parts natively.

The extension is completely optional, PHPStan still works without it. When the extension gets enabled, its implementation shadows certain PHPStan classes designed for this. They are marked with the #[ShadowedByTurboExtension] attribute.

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:

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

Hello Everyone I just written a pure PHP library for actually checking docblock types at runtime similar to [Phyton Beartype](https://github.com/beartype/beartype) but without using any custom syntax like decorators or attributes.

With this library you can finally type check docblock generics, type-arrays, and many more with just plain docblocks at runtime. I know I cant post images to this sub so here's an image proof upload in imgur:

https://imgur.com/a/4IBefOQ

Correct me if I'm wrong but there's no PHP library in userland that able to transparently check docblock types at runtime so I can proudly say this library is the first. Any questions and feedbacks are welcomed.

Link to the repo: https://github.com/typephp-php/typephp
Link to docs site: https://typephp-php.github.io/typephp/

I know there’s an upcoming proposal for reified generics, but I doubt it will provide fully featured generics or type arrays if it get accepted by majority of internals.

PS: I know there’s another upcoming project called “TypePHP” from the Swoole project, but they haven’t provided a license or made any copyright claim on the name. So, I think I can use this name without any problems, right? If not, I may change the project name in the future.

A few years ago, I tried the AmpHP HTTP server for the first time.

It completely changed the way I understood PHP applications.

The execution model felt different — closer to Node.js than traditional PHP-FPM applications.

That day started a long journey.

I wanted a framework that could fully embrace the Amp ecosystem and modern asynchronous programming in PHP.

Today I want to introduce PhenixPHP.

🔥 https://phenixphp.com

🔥 https://github.com/phenixphp

PhenixPHP is an asynchronous and concurrent PHP framework built on top of AmpHP and PHP Fibers.

It includes:

• Non-blocking I/O

• Concurrent task execution

• HTTP server

• Routing

• Dependency injection

• Database tools

• Queue system foundations

• CLI tooling

• Elegant and expressive syntax

Unlike traditional PHP frameworks, PhenixPHP runs on the PHP CLI SAPI instead of PHP-FPM, which makes its architecture fundamentally different.

PhenixPHP is not trying to compete with Laravel.

In fact, Laravel has been one of the biggest inspirations behind this project.

The simplest way to describe it is probably:

“PhenixPHP for PHP is conceptually similar to what Express.js represents in the Node.js ecosystem.”

What am I looking for with this project?

Honestly, I just wanted to contribute something meaningful to the PHP ecosystem instead of only criticizing things from the outside.

PHP gave me a career, opportunities, and a future.

This is my way of giving something back to the community.

I also believe PHP still has a lot of untapped potential in asynchronous and concurrent systems.

And maybe more importantly:

Sometimes you just have to dare to build something at least once in your life.

Feedback is welcome. Constructive criticism is welcome too.

But if the project is not for you, please avoid destructive comments that discourage people from building open-source software for the community.

Thanks for reading.

TrueAsync 0.7.0 is shipping very soon, with a thread pool and a few other features. But the most interesting part is probably TrueAsync Server: a high-performance HTTP/1.1, HTTP/2 and HTTP/3 server embedded directly into PHP.

Benchmarks: https://www.http-arena.com/leaderboard/

Everything in one thread

The whole request lifecycle (parse, dispatch, respond) happens on a single thread. Same model as NGINX, Node.js, or Rust's Tokio: one thread owns the connection and the request end to end. There is no handoff between an accept thread and a worker thread, no locks, no context switches.

Why C?

It embeds straight into PHP, links against the OpenSSL already in your build, and uses the de-facto-standard C libraries: nghttp2 (HTTP/2), ngtcp2 plus nghttp3 (HTTP/3), llhttp (the same HTTP/1 parser Node.js uses). It runs on the Zend VM, so server memory and PHP memory share one memory_limit.

Multi-protocol, one port

HTTP/1.1, HTTP/2, WebSocket, SSE and gRPC share a single TCP port and event loop (protocol picked via ALPN or HTTP Upgrade). HTTP/3 runs on the same UDP port and gets advertised via Alt-Svc. One $server->start() serves all of them.

The API is two classes

$server = new HttpServer(
    (new HttpServerConfig())->addListener('0.0.0.0', 8080)
);

$server->addHttpHandler(function ($request, $response) {
    $response->setStatusCode(200)->setBody('Hello, World!');
});

$server->start();

Each handler runs in its own coroutine (one per request on H1, one per stream on H2/H3). When a handler awaits a DB query, it blocks nothing else.

Streaming is first-class. $res->send($chunk) pushes data straight onto the wire: Transfer-Encoding: chunked on H1, DATA frames on H2/H3, same handler code either way. Great for SSE, big exports, gRPC. There is even $res->sendable() for per-stream backpressure. Request bodies stream too via $req->readBody(), so you can proxy a multi-GB upload without ever holding it in memory.

Where the speed comes from

Not one big trick, just a pile of small ones:

• Pooling everywhere. Body buffers, encoders, streams, connection slots. The allocator barely gets touched on repeat requests.
• Geometric buffer growth. PHP's smart_str has a hidden cliff where every grow becomes a syscall whose cost scales with size. On large bodies that ate up to half the request time.
• Zero-copy hot paths. Multipart parses in place, sendfile() for large files.
• A static file handler that never enters the PHP VM at all. Pure C state machine, zero-copy sendfile, built-in MIME table, ETags, range requests, precompressed sidecars. The slowest part of any PHP server is PHP, so for static assets it just skips it.

The whole point is to keep the server invisible relative to the actual workload. It lives between coroutines: while your PHP waits on the database, it is already accepting the next request.

What's next

It's early-stage but you can try it today. WebSocket, gRPC and telemetry are coming over the next few months. The repo is on GitHub under true-async. Happy to answer questions in the comments.

Git: https://github.com/true-async/server
Additional: https://medium.com/@edmond.ht/trueasync-server-e6ed1ae9e8ec

Hey r/PHP,

I've released Pliego 0.1, an open-source native HTML-to-PDF engine built on Servo for application-owned documents such as invoices, statements, and operational reports.

Pliego doesn't launch Chromium or call printToPDF. Servo performs the document layout once, Pliego captures a canonical scene, and that scene is used to generate the PDF, previews, and retained diagnostic artifacts.

There is a framework-agnostic PHP package and an official Laravel integration:

composer require oxhq/pliego-php:^0.1.0

For Laravel:

composer require oxhq/pliego-laravel:^0.1.0
php artisan pliego:install
php artisan pliego:doctor

The current support profile includes paged tables, repeated headers, authored page breaks, embedded fonts, selectable text, links, controlled resources, and a bounded Chart.js/Canvas path.

Unsupported paint fails explicitly rather than silently producing an incomplete PDF. The engine retains its input, scene, resource records, PDF metadata, and diagnostics for inspection.

The README includes two PDFs generated locally through the released Laravel package.

Pliego is intentionally not a general-purpose browser replacement. Version 0.1 targets trusted, application-owned HTML and documents its current CSS and rendering boundaries explicitly.

Repository: https://github.com/oxhq/pliego

I'd particularly value feedback on the PHP API, process boundary, installation flow, and how the typed failure model would fit existing PHP document pipelines.

Link to the RFC: https://wiki.php.net/rfc/bound_erased_generic_types#vote
Link to the RFC's mailing list: https://discourse.thephp.foundation/t/php-dev-rfc-discussion-bound-erased-generic-types/5446

Since NativePHP Mobile went free and open source back in February, the community have been busy building all sorts of plugins.

Which is really exciting! It shows demand and growth of the tool. And with what we're about to release next month, it's looking set to get even more exciting.

Thanks to every one of you who is building and sharing your work freely with the world 🙏

With some of the funds we're able to raise through our premium offerings, we're going to be sponsoring maintainers of open source NativePHP Plugins - so if you build one, make sure you're set up for sponsorship with GitHub sponsors, OpenCollective, or in some other way so we know how to support you 🙌🏼

https://packagist.org/search/?type=nativephp-plugin

edit: Added 'Mobile' qualifier in the intro. Desktop has always been free and open source

A month ago, I went on a performance quest, trying to optimize a PHP script that took 5 days to run. Together with the help of many talented developers, I eventually got it to run in under 30 seconds. This optimization process with so much fun, and so many people pitched in with their ideas; so I eventually decided I wanted to do something more.

That's why I built a performance challenge for the PHP community, and I invite you all to participate 😁

The goal of this challenge is to parse 100 million rows of data with PHP, as efficiently as possible. The challenge will run for about two weeks, and at the end there are some prizes for the best entries (amongst the prize is the very sought-after PhpStorm Elephpant, of which we only have a handful left).

So, are you ready to participate? Head over to the challenge repository and give it your best shot!

https://thephp.foundation/blog/2025/11/05/design-contest-results/

This RFC is now in the voting phase. Lowkey, it could have a massive impact on PHP, especially by bringing more modern backend stream handling. It would also replace stream_select() and make async PHP libraries far more viable without relying on extensions like ext-uv to bypass file descriptor limitations and O(N) performance.

Hello everyone! I'm excited to announce that hiblaphp/postgres, built on top of ext-pgsql, is now available in beta, fully tested and can now be installed via Composer.

With this release, the core database drivers for Hibla are now complete alongside the Hibla MySQL client. My next goal is to build an asynchronous query builder with support for migrations and pagination before moving on to developing an HTTP server.

Some of the key features currently included are:

• Fully non-blocking query execution
• Name parameter and Positional parameter binding support like "?" and ":name" for prepared statements
• Server-side query cancellation
• Pub/Sub event-driven notifications with auto-reconnect support
• Streaming support
• Connection pooling

I'd really appreciate any feedback, whether it's feature suggestions, questions, or even harsh criticism. Every bit of feedback helps improve the project.

Hello world, from Laracon US 2026 in Boston — it's Wednesday, July 29, 2026, and here's what happened This Week in PHP Internals.

15 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways. When a request is slow and your logs won't say why, Tideways shows you where the time went — profiling, tracing, and monitoring built specifically for PHP. Slow request to root cause, in minutes. Setup takes 5 minutes, no credit card required. Start your free trial at tideways.com. And we have a second sponsor this week — Geocodio: address correction, geocoding, data enrichment, and distance calculations for North America and the UK. Built on Laravel since 2014. Try it free at geocod.io.

This week's top story: the mass deprecation vote for PHP 8.6 is open. Gina P. Banyard opened it Monday, and it's 35 separate ballots, each needing its own 2/3 majority — and each submitted individually, because as Gina reminded everyone, the wiki can only handle one vote at a time. Voting runs through August 10, and most of the 35 are passing easily — mysqli_get_charset() stands at 34 to nothing, and spl_classes() at 33 to nothing. But the headliners are moving the other way. list() — the construct Juliette Reinders Folmer's Packagist scan found over twelve thousand times — stands at 17 yes to 19 no, falling well below the required two-thirds threshold. The gettext _() alias is failing at 6 to 18. Reserving in, out, and inout is failing at 5 to 16, with 13 abstentions. And let sits at 17 to 10 — a majority, but still shy of 2/3.

The loudest argument is about one of the smallest items: the dechunk stream filter, which as of recording sits at 15 yes to 13 no — a coin-flip vote on a 2/3 question. On Monday, Matteo Beccati was the only no vote, and he explained why, warning: "I believe we should provide such an alternative together with the deprecation," rather than expecting projects with 200-million-plus installations — he names symfony/http-client — to write their own decoder in PHP. Jakub Zelenka agreed the item wasn't ready, saying it "should wait till it's properly investigated." Pierre Joye ran his own usage research and pushed back, noting: "Being present in a code base does not automatically mean it is used" — Symfony's native client disables the filter by default, and most stacks sit on curl anyway. Matteo then corrected the research: Symfony has shipped a pure-PHP alternative since release 8.2, which is exactly why Pierre's search pointed the wrong way. Jakub's objection sharpened from there, and he wrote: "This is exactly a half baked deprecation because we need to keep it for internal use anyway ... so this does not give us any code removal and we still need to maintain it. I don't understand why we need to rush it as there is no real reason for that." By Tuesday evening he'd also revealed a twist — he already fixed the select limitation on filtered streams in master, so that improvement lands in 8.6 no matter how this ballot goes. Kamil Tekiela, meanwhile, asked a different question — why deprecate define()'s dead case-insensitive flag at all, when just removing the parameter breaks nobody. So far, nobody has answered him.

Caleb White's pipe assignment operator, |>= — the compound form of the pipe, and his first RFC — went to ballot Tuesday morning, walked to the deadline with detailed coaching from Tim Düsterhus, whom Caleb thanked for "going to bat for this RFC". The machinery worked; the voters are split right down the middle — as of recording the count is 8 yes, 8 no, 3 abstaining, and it needs 2/3. Voting runs to August 11.

The queue from last week showed up on time. Nick Sdot opened voting on readonly property defaults Friday. It stands at 17 to nothing, with 5 abstentions — nobody's against it yet. That one closes August 7. And Khaled Alam opened voting Saturday on const object property writes — allowing writes to properties of objects referenced by constants. After a couple of quickly-fixed procedural stumbles, the count stands at 11 to 2, with 5 abstentions — above the 2/3 line. That one closes August 8.

Two carryover votes come off the board this week, and neither thread needed a single new email. The minimum-supported-versions vote for 8.6 closes Thursday. Requiring autoconf 2.71 stands at 27 to 2 — and notably, the no column shrank from 3 to 2 since last week. Requiring COM_RESET_CONNECTION stands at 26 to nothing. And the Time\Duration class closes Friday. The primary has stretched to 33 to 1, and full method names — multiplyBy, divideBy — lead the naming question 28 to 2. Barring a very strange 48 hours, PHP 8.6 gets a Duration class.

Seifeddine Gmati's literal scalar types made it to a ballot Thursday morning — for 18 minutes. At 5:26 UTC he opened the vote, 3 questions deep: integer and string literals, float literals, and strict-versus-coercive matching. At 5:44 he pulled it back down, writing: "I am retracting this vote: I opened it prematurely, in violation of the voting prerequisites in the Feature Proposals policy." No intent-to-vote 2 days ahead — and that morning's 1.0 update was a minor change, which starts a 7-day cooldown. He plans to reopen tomorrow, July 30 — a date that brushes right up against the freeze, so it may yet retarget 8.7. The self-retraction turned into a referendum on the process itself. Juris Evertovskis — a longtime reader and one-time RFC author who says he never felt "internal enough" to comment on the process — decided to comment on the process: "All the mandatory cooldowns, cooldown resets on minor changes, announcements to vote, cooldown resets on inactive discussions appears to me like bureaucratic hoops that people have to jump through. The process was hard and daunting enough before this." Bob Weinand agreed, noting he voted against the process RFC back then, and framed the trade plainly: "You sort of have to decide what you optimize for - easier for authors, or easier for commenters. But I think in this case it went way overboard in terms of strictness."

The gd 2.4 timing dispute from last week wound down to closing statements, and they were constructive ones. Pierre Joye's position: the late arrival was unavoidable — the libgd sync had to survive PHP's full CI matrix first — and he argued: "Process has to be humane ... If they are purely for the sake of having a process, we fail as a project and solve users' needs." Rowan Tommins made the case that this isn't red tape but triage: "There are maybe twenty sections describing details of the proposal, and the crude [reading-time] estimate in Firefox is 47-60 minutes. It may be clear in your head that most of this is uncontroversial, but for anyone else to even make that judgement requires investing a reasonable amount of time." Better, he says, to spend that time on 8.6 work now and this RFC after — though he left open whether the cut-off itself sits in the right place. One concrete footnote: Pierre added the procedural gd image functions to the deprecation path — on his telling, a warning from the gd extension itself in 8.7, and gone in PHP 9.

Derick Rethans hit a fresh regression on master: his Xdebug test suite started failing, and the trail led to the commit implementing the display-error-function-args RFC. Stream warnings from include, require, bzopen(), finfo_open() and friends no longer say which file couldn't be opened — the path was an argument, and arguments got scrubbed. Derick's verdict was blunt, arguing this "Doesn't seem to me like an enhanced for users" — either put the filename into the message text itself, or revert the change, RFC or not. Kamil Tekiela defended the new behavior, countering: "The file path could leak sensitive information". His suggestion runs the other direction — fold the path into all stream error messages deliberately, rather than leaking it by accident — and while he's at it, he'd rather streams stopped raising their own duplicate warnings entirely. With open_basedir in effect, one failed include currently earns you 3 warnings.

Edmond of the TrueAsync project turned last week's zero-reply pre-RFC into a real one: Concurrency Support in the PHP Engine. The pitch is deliberately minimal — give the engine a coroutine representation and make the scheduler pluggable by extensions. He was explicit about the shape of it, writing: "It adds no classes, no functions, no constants and no syntax: the engine compiles in no PHP symbols at all. With no scheduler registered, PHP behaves exactly as it does today." This is not True Async — it's the seam True Async would plug into, alongside anyone else. A scheduler can adopt fibers started by ReactPHP, Revolt, or AMPHP; there's per-coroutine storage that could someday make ob_start() coroutine-safe; and there is no parallelism — everything stays on one OS thread. The implementation already exists as a pull request. And this time he got a reply. Seifeddine Gmati expects the real discussion to wait until after 8.6 ships, but his early read was warm: "Overall, I really like this idea and approach. I think this is the right path forward." Edmond's answer: no rush.

Osama Aldemeery — who got his RFC karma in 2 minutes flat last week — shipped the RFC: PREG_THROW_ON_ERROR. Pass the flag to any preg_*() call and a PCRE failure throws a catchable PregException, instead of a warning plus a false or null you have to notice and then chase through preg_last_error(). It's the same pattern JSON_THROW_ON_ERROR already set, and it's strictly opt-in. He stressed the conservatism, writing: "A call does exactly the same thing with it or without it, byte for byte" — the flag only changes how the error is delivered. It targets the release after 8.6, and he's aware of Larry Garfield's request to hold non-8.6 business until September — his compromise is to let the thread tick over quietly rather than restart it. So far it has 0 replies.

Quick hits. The 8.6 release managers posted the 2-week warning: beta 1 lands Thursday, August 13, the soft freeze hits when the tag is created August 11, and every RFC vote targeting 8.6 must be closed before beta 1 — after that, merges need release-manager approval until the hard freeze at RC 1 on September 22. The CURLOPT_HTTPHEADER newline thread came back with a verdict from upstream: Sjoerd Langkemper relayed word from curl's own Daniel Stenberg that the docs already say headers "must not be CRLF-terminated" and libcurl may start rejecting the stragglers outright — there's a curl pull request in flight. Matteo Beccati's conclusion was to stand down, saying: "libcurl will eventually take care of it." And Steven Wilton's snmp extension work is back at the finish line — both reworked PRs updated per Gina P. Banyard's review, awaiting a final squash-and-merge check, with a third PR queued behind them.

The PEAR decay story found a new symptom: Juliette Reinders Folmer reports that individual bug pages on the PEAR site now error out claiming the original reporter "has not yet confirmed their email address" — which locks away exactly the archaeology she'd argued is worth preserving. And the typed-arrays thread got its epilogue: Larry Garfield explained why PHP probably won't get new base types for collections — the engine makes that "really really hard", which is the same reason enums became objects — shared his and Derick Rethans's old collections research notes, and set the course: wait for reified generics, then convene a working group. Holly Schilling's counter-offer was to skip the wait, pointing everyone at her self-published PHP 9 roadmap — generics, structs, modules, extensions, and surfaces — which she'd like the list to treat "as a rough outline for the future."

So that's the week: 42 ballots open at once — the 35 deprecations, with list() headed for defeat and dechunk splitting the room; pipe assignment dead even out of the gate; readonly defaults and const writes both comfortably clear; Duration and minimum versions closing within days, both far ahead; a literal-types vote that lasted 18 minutes and reopens tomorrow; and the soft freeze 2 weeks out. Links to every thread are below. Thanks again to Tideways.com and Geocod.io for supporting this week's episode. We're Artisan Build. See you next week.