TimWolla

PHP’s New URI Extension: An Open Source Success Story The PHP Foundation — Supporting, Advancing, and Developing the PHP Language

Say goodbye to parse_url() headaches! 🥳

PHP 8.5 is introducing a new URI Extension with standards-compliant (RFC 3986 & WHATWG) and secure URL parsing. It provides a clean API and lets you easily modify URI components.

Learn more 👇

thephp.foundation/blog/2025/10...

⚙️ #PHP 8.5 sees its cloning supercharged! With the "clone with" RFC merged 5 days ago, we have much more possibilities when it comes to cloning objects.

Supports hooks, readonly, __clone() overriding. Thanks
@timwolla.bsky.social for the #DX improvement! 👏

PR: github.com/php/php-src/...

For this one I mainly contributed the implementation. @edorian.bsky.social made the decisions and a large part of the discussion :-)

🚀 (1/11) #PHP 8.4 adds SSE2 and SHA-NI #hardware acceleration for #SHA-256:

hash('sha256', /* your data */);

What does this means exactly? HUGE performance boost! 💥 But how is it possible? 👇

An invitation to chat and some useful links about PHP internals and extensions development - Externals #externals - Opening PHP's #internals to the outside

The resources mentioned in externals.io/message/120041 might come in helpful (especially StackOverflow Chat for a more direct line to some of the core contributors).

If someone would have disagreed with having that function (or still disagrees until PHP 8.5 feature freeze), then I would have went the RFC route. But as that did not happen (yet), we could avoid the bureaucracy there and save the participants on Internals and the voters some mental load 🙂

In that case, both naming and implementation was pretty obvious, without leaving much room for "creativity". It also filled a clear gap in the existing functionality, so it was just merged by simple agreement of the ext/curl maintainer.

curl: Add `curl_multi_get_handles()` by TimWolla · Pull Request #16363 · php/php-src see https://curl.se/libcurl/c/curl_multi_get_handles.html

As an example, here's a recent-ish PR of mine adding a new ext/curl function to PHP 8.5 without going through the RFC process: github.com/php/php-src/...

Screenshot (in German) of the 3-dot menu in Gmail's compose view. The plaintext option ("Nur-Text-Modus") is checked.

I recommend sending plaintext-only emails when interacting with Internals: Formatting will look as expected and less data to send around the Internet.

You can select that in the 3-dot menu when composing a message. Not sure if it can be set as default for specific recipients.

Based on externals.io/email/126356..., the HTML variant of your email indeed contains some fancy formatting for that left bar, but it didn't do anything for the plaintext variant.

So far you didn’t run into the issue, because the discussion thread is simple enough, but it will likely cause confusion for more complex discussions with multiple parallel discussion topics.

Also one thing to keep in mind with Gmail’s web interface: Please use the “Reply button” on the email you are actually replying to. Gmail’s linear view makes this easy to do wrong, leading to incorrect threading in other emails clients that show a tree structure (e.g. Thunderbird in my case).

And indeed, the quote didn’t properly make it through. I can’t comment on details of Gmail’s web interface, which I assume you’re using, but generally prefixing each line with a `>` should do the trick.

You mentioned that someone from the Laravel community sparked the idea and then I searched social media for “PHP RFC”.

Personally I don't ever run the entire test suite locally (no need to run, say, ext/dom tests if I work on something unrelated) and leave the full test to CI.

And for running tests, you can restrict the tests to a specific directory by running `sapi/cli/php run-tests.php --show-diff ext/random/` for faster turn-around times.

7 to 8 minutes sounds pretty slow for building on an M1. Did you build with `make -j$(nproc)` for multi-core compilation?

Using the information learned from writing the PR you can ensure that your RFC text itself is in the best possible shape, cutting down on the amount of back-and-forth discussion and clarification required on the mailing-list, saving everyone involved time.

Having the PR ready first will also help in working out all the details. By writing the tests you find necessary edge-cases that might need some explanation in the RFC itself.

In simple cases an RFC might not actually be necessary! As a newcomer it might be easier to file a PR against php-src first and then folks will likely tell you if you need an RFC (either because they disagree with the feature, or because they feel further discussion is necessary).

Friendly person here 👋 Happy to hear that my reply was well-received. My intention really was avoiding the “Internals is hard to approach” sentiment that is sometimes claimed on social media and it seems I succeeded with that 😁