A little about me

PHP was my introduction to open source, when PHP 3 was the latest release. It was mind blowing to see an amazing group of smart, funny people collaborate with each other, help newbies, and build impactful things together while still having fun. People who lived thousands of miles away from each other and who had never met each other. People who had completely different backgrounds and daily lives. People who spoke different languages and lived in different time zones. They all managed to find a way to come together as a community. They wrote code, they organized events, they started local user groups, they built projects together, and they helped each other learn. Forgive my sentimentality, but it was (and still is) magical.

It was this sense of community that fascinated me most, and I found myself moving from PHP development to open source community management. Since officially making that switch in 2010, I’ve worked for companies like GitHub, Sourceforge, and Pivotal, striving to make open source healthier, more inclusive, and better for everyone. I wanted anyone with an interest to be able to join the open source party, bring their unique set of skills, and experience the magic firsthand.

For the last 6 years, I have worked as the Community Manager for an open source project called CHAOSS which focuses on open source community health and sustainability. It has been an unforgettable experience, I’m very proud of what we all accomplished together, and I love that community very much. But as I find my career pivoting back toward PHP, it honestly feels like coming home again.

Looking to the future

The progress that has been made by the Foundation in the last few years is remarkable! Moving forward, you can expect to see the same kind of commitment to improving the PHP language and to keeping PHP relevant and sustainable.

In addition, we aim to increase the Foundation’s transparency and openness, and to strengthen our collaborative relationships with users, sponsors, contributors, organizations, and the PHP community at large. A solid and thriving PHP ecosystem belongs to and benefits us all, but none of us can make that happen alone.

Let’s chat!

Because we’re all in this together, I want to spend the next 1-2 months really listening to what you have to say. I have an open calendar and I encourage you to reserve some time with me. I want to hear from PHP developers, contributors, companies using PHP, independent consultants, sponsors, community members, and anyone else interested in the future of PHP. I want to hear about your goals, your motivations, your pain points, and yes, even your wacky and unorthodox ideas. And if meetings aren’t your thing, that’s completely understandable. You can also send me an email. (I’ll even check my inbox!)

PHP’s secret recipe has always been its community and I can’t wait to be collaborating with you all again!

Elizabeth brings a rare combination of deep roots in the PHP community and proven leadership in open-source governance. She co-founded a volunteer-based nonprofit dedicated to supporting women and non-binary individuals in the PHP industry, served as Community Manager at GitHub where she led developer outreach programs including the Patchwork initiative, and has been active in CHAOSS – a project focused on open-source community health metrics.

Her experience spanning community building, fundraising, outreach operations, and open-source strategy makes her a natural fit to lead the foundation into its next chapter.

As previously announced, founding Executive Director Roman Pronskiy is transitioning to focus on his growing role at JetBrains, while continuing to serve on the Board of Directors. Roman will work closely with Elizabeth to ensure a smooth handover.

Please join us in welcoming Elizabeth. We're looking forward to what's ahead. 🐘💜

team.blue is a leading AI-powered digital enabler serving small and medium businesses (SMBs) and agencies across Europe. With more than 4,000 experts, 3.3 million customers, and operations in over 22 countries, team.blue provides businesses with the digital tools they need to build, grow, and scale online. Its ecosystem spans domains, hosting, cloud solutions, website and e-commerce tools, and a fast-growing portfolio of AI-driven SaaS products. For team.blue, PHP represents a foundational technology across its platforms and services.

PHP: the engine behind team.blue's platforms

PHP's performance, stability, and extensive ecosystem also provide a scalable basis for delivering AI-powered capabilities and intelligent user journeys, enabling million SMBs to grow and succeed online. PHP underpins:

• Shared hosting and managed WordPress products at brands like Combell, Register.it, and TransIP.

• PHP-based SaaS products (core app logic, integrations, and day-to-day feature work).

• Internal tools and systems used across the group.

PHP's mature ecosystem and proven scalability allow team.blue to build sophisticated digital tools that help SMBs and agencies grow online, demonstrating how the language powers modern high-traffic platforms across diverse use cases.

Discover more about the team.blue ecosystem: https://team.blue/our-ecosystem/

Giving back to the PHP community

As a Gold Sponsor, team.blue is putting tangible support behind PHP, helping accelerate progress, maintain strong security, and back the ecosystem globally, while directly supporting the essential work of maintenance, continuous improvement, and ensuring the language remains ready for what comes next.

Learn more about team.blue and its mission to make online business success simpler: https://team.blue/

The gist

In PHP 8.6, it will be possible to create a closure that simply delegates to another function without writing out the whole closure.

// This
$underscore = str_replace(' ', '_', ?);

// Is effectively the same as this:
$underscore = fn(string $s): string => str_replace(' ' , '_', $s);

Both lines will produce nearly identical opcodes, but the former is much easier to both write and to read, as it doesn't require messing about with redeclaring all the types and variable names.

Any function (or method) call may use one of two placeholders, ? or ..., to indicate that it is only "partially invoking" that function. Or "partially applying arguments to it." It works with both positional and named arguments, too!

function complex(int $a, int $b, int $c, int $d): string { ... }

// This creates a closure that takes 2 ints and returns a string.
$f = complex(?, 2, ?, 4);

// This creates the same closure, but with named arguments.
$f = complex(b: 2, d: 4, ...);

// This reverses the order of the parameters, $f needs $c first, then $a.
$f = complex(b: 2, d: 4, c: ?, a: ?);

// Keep all arguments unbound. Hey look, first-class-callables!
$f = complex(...);

// This creates a zero argument closure, which just calls complex() when invoked!
$f = complex(1, 2, 3, 4, ...);

PFA supports a wide variety of complex use cases and features, like parameter reordering, named arguments, variadics, etc. In practice, however, we expect most uses to be reducing a function down to a single remaining argument (that is, currying). That makes it perfect to use as a callback. Most of PHP's functions that take callbacks expect a single argument, and the few remaining take two (such as a value and a key). PFA makes using arbitrarily complex, contextually aware functions in those cases trivially easy.

// This
$result = array_map(in_array(?, $legal, strict: true), $input);

// is much nicer than this
$result = array_map(fn(string $s): bool => in_array($s, $legal, strict: true), $input);

By design, it's also the perfect complement for the new pipe operator. To reuse some examples from the Pipe RFC:

$numberOfAdmins = getUsers()
    |> array_filter(?, isAdmin(...))
    |> count(...);

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> array_map(strtoupper(...), ?)
    |> array_filter(?, fn($v) => $v != 'O')
;

What's more, optimizations around the pipe operator mean the closure doesn't even need to be created in those cases, so there's zero performance overhead.

The RFC has more details on all the ins and outs of the new syntax.

The long view

If all of this sounds a lot like an extended version of "first class callables," it should. Or rather, "first class callables," are the training wheels version of partial function application.

PFA was first proposed way back in 2021, by a team of Joe Watkins, Levi Morrison, Paul Crovella, and myself. That version was largely similar on the surface, but had a different implementation that caused some consternation. In particular, Nikita Popov (at the time still PHP's de facto lead developer) felt that it introduced too much complexity in the engine. His hesitancy convinced many others to reject it at the time, though there was still a lot of interest and support.

There was enough support, however, that Nikita asked "couldn't we just do foo(...) to delay all the variables, and skip the rest of the RFC?" The result of that was the First Class Callables RFC, released in PHP 8.1.

I've been looking to take a second swing at PFA since then, but needed the right time and right collaborators. FCC has clearly shown itself to be a huge boon to the language, so why not go all the way? It wasn't until the Pipes RFC passed earlier this year, though, that I was able to snare the PHP Foundation's Arnaud Le Blanc into working on a second version with me. It didn't quite make it into PHP 8.5 for timing reasons, but it's now available in 8.6.

So what changed? One, FCC ended up already including a lot of the underlying engine trickery that was needed for this version of PFA. We were able to leverage that. For another, the implementation is a bit different. Rather than creating a special kind of pseudo-closure that can be extra-optimized, the new approach just creates a normal closure object like we've had for years. That makes it much simpler to implement and solve a ton of edge-case questions. Three, now we have pipes.

And oh boy is this an exciting combination.

A long time coming

PFA for PHP really began even before 2021. As discussed in the Pipes blog post from July, way back in 2016 Sara Golemon proposed porting Hack/HHVM's pipe syntax to PHP:

$result = $arr
    |> array_column($$, 'tags')
    |> array_merge(...$$)
    |> array_unique($$)
    |> array_values($$)
;

That was never approved, but led us to try splitting the syntax in two: The pipe operator itself, and partial function application instead of $$. We tried in 2021 to get both, but both failed. Now we have both.

One of the chief criticisms I've seen about the new pipe operator is the need to wrap up multi-parameter functions into an inline arrow function, and then wrap that in () to keep the parser happy. Which is a fair criticism! And the perfect fix for that criticism is... partial function application. Which we now have. The twins have been reunited.

PHP breaks the mold

I've often seen PHP criticized for just stealing features from other languages and piling them in willy-nilly. Frankly that's not always a bad thing: PHP, much like English, evolves by finding good ideas in other languages and ahem borrowing them, and making it our own.

Partial function application is not a new concept. It's been the foundation of many functional languages for decades. Haskell, for instance, implicitly uses partial application for literally every function call. Any function call can just omit its right-most arguments and poof, it becomes a partial application.

What I have not seen in any language, however, is the ability to partially apply arbitrary parameters. That's important for PHP, because while Haskell's entire standard library was built around the assumption of right-most partial application, PHP's most definitely was not. We needed to be able to turn arbitrary functions into unary (single-argument) functions to allow most parts of the standard library to work with... pipes. Or as callbacks.

And now we can. I do not know of any other language that has as flexible, powerful, and compact a partial function application syntax as PHP 8.6 will have. Here, PHP would seem to be the innovator.

Rock on, ElePHPants!

What comes next?

There's one more major piece of the puzzle still to come: Function composition. Where pipe executes immediately, function composition creates a new function by sticking two functions end-to-end. Sara Golemon helpfully got it started, but it still needs some work before it can be formally proposed.

That would complete the trifecta of "Functional Features" we've been trying to get into PHP for years to allow a much more natural use of functional techniques.

Each of these RFCs is, on its own, useful but not earth-shattering. Taken together... "synergy" may be a dirty word outside of management consulting, but in this case it applies. We are very close to blowing open PHP's functional capabilities in much the way that PHP 5.2 finally blew open its object-oriented capabilities. And as a multi-paradigm language, we'll be able to freely mix and match OOP and FP approaches where they make the most sense.

I can't wait!

Our Achievements This Year

Now in our fourth year, The PHP Foundation has achieved several milestones that have further strengthened the PHP ecosystem:

• Release of PHP 8.5
• PIE 1.0 Release
• Supporting FrankenPHP
• PHP MCP SDK together with Anthropic and Symfony
• 2nd Sovereign Tech Agency Investment for the Stream Layer Rework

Thank You to Our Sponsors

We owe a special thanks to our major sponsors who make our work possible:

Platinum

Automattic
Sovereign Tech Agency
JetBrains

Gold

Laravel
GoDaddy

Silver

Passbolt 🆕, Private Packagist, Craft CMS, Cybozu, Tideways. Zend by Perforce. Symfony Corp, Sentry. Manychat, Mercari Inc., Les-Tilleuls.coop, pixiv Inc., Aternos GmbH, CH Studio

In total more than 550 donations were made by businesses and individual sponsors to The PHP Foundation throughout this year through OpenCollective and more through our GitHub sponsors.

Your contributions enable us to support developers, fund crucial projects, and ensure PHP is a modern and reliable choice for web development.

If you are yet to decide on sponsoring the foundation, here you can find information on how to join us and why it matters or reach out directly to [email protected].

Outlook into 2026

Big changes are ahead for 2026, when our founding and long-term executive director Roman Pronskiy (JetBrains) will step down and the foundation will hire a dedicated executive director for the first time.

This marks a new chapter as we recognize that The PHP Foundation has grown so much that we consider a dedicated management position to be required to ensure that our projects and goals are getting done.

If you are interested in the Executive Director role, we are still looking for candidates to apply until December 15th, 2025.

Furthermore, we’d like to add 2 new developers to our team who applied to our program in autumn.

And mainly, our team will continue to maintain, document, and improve PHP further with the next major release (8.6 or 9.0) coming at the end of 2026.

Thank you,
The PHP Foundation
🐘💜

After four years at the helm of the PHP Foundation, Roman Pronskiy will conclude his tenure as Executive Director in early 2026. Roman founded and helped build the Foundation from the ground up into a stable, well-run organization, expanded our team of core developers, and deepened collaboration across the PHP ecosystem. As his role at JetBrains grows, Roman has decided to focus his efforts there while continuing to support the PHP Foundation’s next chapter.

We’re immensely grateful for Roman’s vision and leadership, which shaped the foundation’s first years and set a strong course for the future. He will continue serving on the Board of Directors as JetBrains’ representative, providing continuity as JetBrains remains a platinum sponsor and steadfast supporter of PHP. Roman will work closely with the incoming Executive Director to make the transition smooth and complete.

The Board has formed a search committee consisting of two board members Sebastian Bergmann and Nils Adermann as well as two community representatives Lorna Jane Mitchell and Ben Ramsey. The search committee will manage the selection process and find a leader who can build on the Foundation's momentum and guide us through our next phase of growth.

What we're looking for:

• Strong leadership experience in open source communities
• Deep knowledge of the PHP ecosystem
• Excellent project management and communication skills
• Strategic thinking and a vision for the foundation's future
• Experience working with diverse stakeholders and sponsors

This is an opportunity to shape the future of one of the world's most widely-used programming languages and support the vibrant community that sustains it.

How you can help:

We need the PHP community's help in finding the right person for this role. If you know someone who would be an excellent Executive Director for the PHP Foundation, please encourage them to apply or reach out to us directly.

The full job description and application details can be found below.

For questions about the search process, please contact [email protected].

🐘💜

Executive Director – The PHP Foundation

Position Type: Full-time or Part-time (if part-time, responsibility includes hiring necessary staff to fulfill the complete role)
Location: Remote, no visa opportunity
Reports To: Board of Directors
Term: 1 year, renewable subject to annual performance evaluation
Compensation: Total Compensation $90,000-$160,000 (Base: $90,000 - $105,000 USD / year, Performance based bonus up to $65,000 USD)

About The PHP Foundation

PHP is one of the world's most widely-used programming languages, powering millions of websites and applications. The PHP Foundation is a collective of people and organizations relying on the PHP language. Its mission is to ensure the long-term prosperity of the PHP language.

The PHP Foundation focuses on providing financial support and guidance to PHP language developers to support its goals of improving the language for its users, providing high-quality maintenance, and improving the PHP language project to retain current contributors and to integrate new contributors.

The PHP Foundation aims to promote the public image of the PHP language in the interest of retaining existing and gaining new users and contributors.

The PHP Foundation operates as a collective under the Open Source Collective, a 501(c)(6) non-profit organization based in the United States. The Executive Director role will be structured as a contractor position with this entity.

The Role

The Executive Director serves as the operational leader of the PHP Foundation, defining its strategic vision and translating it into reality while managing day-to-day operations and serving as the primary bridge between the Board, staff, community, and sponsors.

While the programming language PHP is over 30 years old, the PHP Foundation was only created in 2021. The Executive Director will be responsible for maturing the foundation’s internal structure and will play a crucial role in ensuring the foundation can effectively support this vital ecosystem.

Key Responsibilities

Strategic Leadership

• Develop strategic initiatives for the PHP Foundation and the PHP language in alignment with the foundation's mission and goals
• Annual presentation of new strategy and evaluation of previous year’s performance to the Board for approval
• Develop and implement marketing strategies to fulfill the foundation’s mission to promote the public image of the PHP language

Fundraising & Financial Oversight

• Responsible for fundraising to provide the budget for implementing proposed strategy
• Manage finances, budgets and fundraising
• Prepare quarterly operations summaries and financial statements

Operational Management

• Manage day-to-day operations, staff, including contracted PHP core developers
• Oversee hiring, performance management, and development of Foundation staff
• Ensure efficient execution of foundation programs and initiatives
• Provide regular updates at board meetings

Stakeholder Relations

• Represent the foundation externally and maintain relationships with sponsors, partners, and community stakeholders
• Serve as the public face of the foundation at conferences and community events

Required Qualifications

• Demonstrated leadership experience in relevant organizations or communities
• Strong project management and organizational skills
• Excellent written and verbal communication skills
• Financial management and budgeting experience
• Proven ability to work with diverse stakeholders and build consensus

Additional Experience We Value

• Experience in free and open source software communities
• Knowledge of the PHP ecosystem and its community dynamics
• Experience in fundraising or sponsor relations
• Network within the PHP community
• Experience managing remote teams
• Public speaking and presentation skills
• Previous experience in open source foundation governance
• Experience in or working with public relations or marketing

Compensation and Terms

• Contracting position with Open Source Collective 501(c)(6)
• Fully remote, no visa opportunities
• At full-time, base pay of $90,000 - $105,000 / year, invoiced monthly
• Annual performance based bonus up to $65,000 tied especially to fundraising goals
• Travel to a few community events per year required with expenses covered, additional travel encouraged if event organizers cover expenses
• Renewable annually based on performance and mutual agreement with Board of Directors

Selection Process

A search committee of Board members and community representatives is managing the candidate search and evaluation process. The process includes:

1. Application review and initial screening by the search committee
2. Interviews with the search committee
3. Committee presents top candidates to the full Board of Directors
4. Presentation of vision and strategy to the full Board
5. Final selection by full Board vote (2/3 majority required)

Applications will be accepted on a rolling basis until 2025-12-15.

How to Apply

Please fill in our Google form including:

• Cover letter describing your interest and relevant experience
• Resume/CV
• Brief vision statement (500-1000 words) addressing: your understanding of the foundation's current position, key opportunities and challenges you see for the foundation, and your approach to the role
• During the interview process we will ask you to provide at least 3 references who we can contact

Questions about the position or application process? Contact: [email protected].

Note about future redesigns
This contest was an experiment for a single release page. We might not use the same approach for a broader homepage redesign. If we did run a contest again, we would separate tracks (on-brand update vs blue-sky concept), use a dedicated voting tool or randomized ordering, keep log-damped voting, and set a 50/50 jury/community split with clearer criteria and a small shortlist honorarium.

Results

Winner: Nuno Guerra @nunowar – PHP is Awesome 🔥

Prizes: $1,000 + AI Ultimate License from JetBrains·+ $1,000 from Rector

At JetBrains, we decided to support other contestants with gifts as well.

Runner-up: Hanna Stelmakh @hastelmakh – PHP 8.5 Release Page Design Contest Submission

Prize: $500 + AI Ultimate License from JetBrains

Shortlist:

@ben-joostens, @tao, @lumnn, @thiagoolivier, @mcpad2025-crypto, @minlivalievs-eng, @giodi, @everlastedSE, @asterd, @ad-1984, @Ayesh, @StillMoe, @KarinCheng, @christian-acceseo

Shortlist thank-you: PhpStorm / AI Ultimate License from JetBrains for all shortlisted participants.

A little fun along the way

Of course, no PHP contest would be complete without a bit of humor. Among all the serious submissions, one playful entry from X/Twitter stood out:

It didn’t quite meet the “accessible and lightweight” brief, but it earned an honorary mention for spirit and commitment to vintage web aesthetics.

Next steps

We will collaborate with Nuno Guerra to polish the winning design and may incorporate ideas from other entries where they improve clarity or accessibility. And finally we’ll adapt it to php.net’s stack.

In the spirit of PHP, contributions are welcome! We encourage all participants to join the implementation thread and help refine the final page.

How the scoring worked

We combined a jury score with a community vote and used a logarithmic transform to reduce social-media spikes. We counted 👍 during the voting window for each shortlisted entry and ignored 👎 and other reactions.

• Jury (40%)
  Judges scored four criteria from 0 to 5. For each entry we averaged judges into J in the range 0–25.
  Normalization: J_norm = J / 25.

• Community vote (60%), log-damped
  For entry i with V_i upvotes and T = Σ V_i across the shortlist:
  V′_i = log(1 + V_i) and V_logshare = V′_i / Σ V′_k.

• Final score
  Final = 0.4 × J_norm + 0.6 × V_logshare

We will publish the full table with anonymized jury subtotals and final scores.

Lessons learned

We might not run this contest format again. But if we did, here’s what we would fix:

1) Scope & brief: on-brand update vs full rework

The scope was the PHP 8.5 release page with an on-brand constraint. Some entries explored broader rebrands.

Next time we would

• Be more explicit on on-brand requirement.

• Potentially Split into two tracks judged and presented separately:

  • Track A: on-brand update of the specific page.
    Track B: blue-sky concept for future reference.

2) “Spec work” concerns

We kept scope small, didn’t require code, and recognized more than one entry (runner-up and shortlist thanks).

Next time we would:

• Prepare a more detailed brief with the community.
• Offer a paid shortlist honorarium.
• Cap deliverables (mock-ups plus optional tiny HTML/CSS), no heavy code.

3) Voting & balance (order bias, social reach, weights)

Order bias and social amplification are real. In this contest we ignored downvotes and used log damping on upvotes.

Next time we would also:

• Use a dedicated voting tool that shuffles candidates.
• Optionally hide aggregate reaction counts until voting closes.
• Set a 50/50 split between jury and community.
• Publish the full calculation sheet upfront for auditability.

Thank you

Thanks to all participants, voters, reviewers, and to the jury and design advisors for careful evaluations. Special thanks to JetBrains and Rector for supporting the community with prizes and encouragement.

If you want to follow implementation, join the thread here: php/web-php/issues/1592.

🐘💜

This post outlines the planned work and explains why these changes matter for the PHP ecosystem.

What Are PHP Streams?

Before diving into the improvements, let’s briefly revisit what Streams are and why they matter.

Introduced around 2001, PHP streams provide a unified way to handle file and network I/O, allowing data from different sources such as files, sockets, or memory to be accessed through a consistent API using the same set of functions.

Over time, PHP streams have proven to be a powerful and flexible subsystem, but some parts of the implementation have not evolved alongside modern use cases, performance expectations, and system capabilities. This project aims to make Streams faster, safer, and easier to extend for modern PHP applications.

The actual scope is divided into four subsections.

Performance and Stability improvements

This part aims to improve performance and consistency in how PHP Streams copying and seeking.

There is still room to improve performance in stream copying.

For example, copying large files or handling network transfers can be made faster through asynchronous I/O mechanisms like io_uring on Linux. At the same time, we need to prevent potential crashes caused by memory-mapped files. The goal is to phase out mmap usage and introduce a new copying API as part of the upcoming I/O API, using io_uring or other system features where available.

Seeking is currently problematic for filtered streams, which causes various inconsistencies. Developers working with filters often encounter limitations when rewinding or skipping data.

The plan is to introduce a new seeking filter API that will allow seeking in streams where possible and disallow it where not. For example, seeking to the beginning should always be possible, but not all filters support seeking to arbitrary positions. Some may allow it, so a new internal API is needed.

Error Handling and Monitoring Enhancements

This part is mainly about the introduction of new error reporting mechanisms for streams as well as the introduction of more hooks. Currently, many low-level I/O errors are surfaced inconsistently to user space. The goal is to standardize how Streams report errors and make them easier to debug.

The primary idea for error reporting is to have a better way to handle errors so they can be collected and reported to user space. We’ll wrap existing errors and provide richer context options for developers.

In terms of hooks, this would be useful for async code and could be done through a special polling wrapper. There should be some way to allow replacing some blocking operations (specifically for file IO). This is primarily meant as an internal change, but it will also be considered to possibly expose some hooks to user space if convenient and acceptable from a performance point of view.

Networking and Socket Improvements

This part is mainly about the introduction of a new polling API, improvements in the stream_select function, and resolving issues in socket handling.

Modern network applications rely heavily on scalable event handling. The new polling API will introduce modern mechanisms such as epoll and kqueue, enabling PHP to handle multiple I/O streams more efficiently.

Currently, only select is available for user space, which has known performance and scaling issues. This modernization will benefit frameworks and extensions that implement async networking or event-driven I/O.

The purpose of the API is primarily to build an internal API that can be used internally for various tasks in the PHP core and as a base (fallback) for the future async IO API.

The stream_select usage should be extended to better handle polling of filtered streams and provide an API for external objects that can provide extra data, as will be possible in the new polling API. This will require some refactoring and potentially sharing some of the logic with the new polling API.

Additionally, several socket-specific improvements are planned. New socket context options will be added to provide better configuration capabilities. Various socket handling issues will be addressed, and utilities for working with file descriptors will be improved.

Security and TLS Enhancements

Another important part of this work targets the OpenSSL extension, which handles encrypted streams.

Specifically, refactoring its async handling that is currently not well implemented and has various limitations. The refactoring will clarify what polling action is required for user space. For example, whether the stream needs to wait for reading or writing.

In addition, we aim to improve TLS 1.3 support with options to select cipher suites and integrate TLS Sessions, PSK (Pre-Shared Key) and early data (0-RTT) support.

To enable these changes, a new TLS 1.3 PHP testing library is being developed. It will allow customizing the protocol flow and testing TLS 1.3 features, including asynchronous behavior.

Next Steps

Together, these efforts will modernize and strengthen PHP’s I/O layer for the next decade of web and CLI development.

Work has started in 2025 and will go through 2026. Incremental progress will be shared publicly through PHP Foundation updates and PHP internals discussions, and RFCs.

We’re grateful to the Sovereign Tech Agency for supporting this foundational investment in PHP’s core. Stay tuned for technical write-ups and benchmarks as the implementation progresses.

Their familiarity makes them appear deceptively simple: Seemingly clearly delineated components like scheme, hostname, path, and some others suggest that it’s trivial to extract information from a URL. In reality, there are thousands of custom parsers built over the years, each with their own take on details.

For us web developers, there are two main standards specifying how URLs are supposed to work. RFC 3986, which is the original URI standard from 2005; and the WHATWG URL Living Standard, which is followed by web browsers. Because things are not as simple as they appear at first glance, these two commonly used standards are incompatible with each other! Mixing and matching different standards and their parsers, especially when they do not exactly follow the standard, is something that commonly leads to security issues.

Why Change Was Needed

Despite the importance of correctly parsing URLs, PHP did not include any standards-compliant parser within the standard library for the longest time. There is the parse_url() function, which has existed since PHP 4, but it does not follow any standard and is explicitly documented not to be used with untrusted or malformed URLs. Nevertheless, it is commonly used for lack of a better alternative that is readily available and also because it appears to work correctly for a majority of well-formed inputs that developers encounter in day-to-day work. This can mislead developers to believe that the security issues of parse_url() are a purely theoretical problem rather than something that will cause issues sooner or later.

As an example, the input URL example.com/example/:8080/foo is a valid URL consisting of only a relative path according to RFC 3986. It is invalid according to the WHATWG URL standard when not resolved against a base URL. However, according to parse_url() it is a URL for the host example.com, port 8080 and path /example/:8080/foo, thus including the 8080 in two of the resulting components:

<?php

var_dump(parse_url('example.com/example/:8080/foo'));

/*
array(3) {
  ["host"]=> string(11) "example.com"
  ["port"]=> int(8080)
  ["path"]=> string(18) "/example/:8080/foo"
}
*/

Introducing a New API

This changes with PHP 8.5. Going forward, PHP will include standards-compliant parsers for both RFC 3986 and the WHATWG URL standard as an always-available part of its standard library within a new “URI” extension. Not only will this enable easy, correct, and secure parsing of URLs according to the respective standard, but the URI extension also includes functionality to modify individual components of a URL.

<?php

use Uri\Rfc3986\Uri;

$url = new Uri('HTTPS://thephp.foundation:443/sp%6Fnsor/');

$defaultPortForScheme = match ($url->getScheme()) {
    'http' => 80,
    'https' => 443,
    'ssh' => 22,
    default => null,
};

// Remove default ports from URLs.
if ($url->getPort() === $defaultPortForScheme) {
    $url = $url->withPort(null);
}

// Getters normalize the URL by default. The `Raw`
// variants return the input unchanged.

echo $url->toString(), PHP_EOL;
// Prints: https://thephp.foundation/sponsor/
echo $url->toRawString(), PHP_EOL;
// Prints: HTTPS://thephp.foundation/sp%6Fnsor/

Thoughtfully Built to Last

In this post we not only want to showcase the functionality but also tell you the story of how this project developed and how work gets done in PHP to keep the language modern and a great choice for web development. There is often more work behind new PHP features than meets the eye. We hope to provide some insight into why we prefer doing things right rather than fast.

Máté Kocsis from The PHP Foundation’s dev team initially started discussion for his RFC of a new URL parsing API in June 2024. Given PHP’s strong backwards compatibility promise, the new API needed to get things right on the first attempt in order to serve the PHP community well for the decade to come without introducing disruptive changes. Thus, over the course of almost one year, more than 150 emails on the PHP Internals list were sent. Additionally, several off-list discussions in various chat rooms have been had. Throughout this process, various experts from the PHP community continuously refined the RFC. They discussed even seemingly insignificant details, to provide not just a standards-compliant implementation, but also a clean and robust API that will guide developers towards the right solution for their use case. We also planned ahead and made sure that the new URI extension with its dedicated Uri namespace provides a clear path forward to add additional URI/URL-related functionality in future versions of PHP.

The RFC ultimately went to vote in May 2025 and was accepted with a 30:1 vote. But work didn’t stop there: The proposed API also had to be implemented and reviewed. Instead of building a PHP-specific solution, Máté opted to stand on the shoulders of giants and selected two libraries to perform the heavy lifting. The uriparser library provides the RFC 3986 parser, and the Lexbor library, which is already used by PHP 8.4’s new DOM API, provides the WHATWG parser.

Open Source Collaboration

As part of the integration, Máté and The PHP Foundation worked together with the upstream maintainers to include missing functionality in the respective libraries. As an example, neither library included functionality to cheaply duplicate the internal data structures, which was necessary to support cloning the readonly PHP objects representing the parsed URL when attempting to modify individual components with the so-called with-er methods (e.g., ->withPort(8080)). The uriparser library also did not include any functions for modifying components of a parsed URL. All this functionality is now available in the upstream libraries for everyone to use and benefit from.

The review and testing of Máté’s PHP implementation was carried out by PHP community contributors Niels Dossche and Ignace Nyamagana Butera. This included reviewing and testing the new functionality that had been added to the two upstream libraries. Tideways, a founding member and Silver sponsor of The PHP Foundation, also sponsored engineering time; their contribution came in the form of Tim Düsterhus. During the review and testing, these reviewers discovered several pre-existing bugs in the upstream libraries. They submitted fixes to the upstream maintainers, Sebastian Pipping (uriparser) and Alexander Borisov (Lexbor), who quickly reviewed and applied them.

Test It Now

This work paid off, and PHP’s new URI extension with not just one but two feature-rich and standards-compliant URI implementations is fully available for testing with PHP 8.5 RC 1.

If you'd like to see further improvements to PHP’s standard library please consider sponsoring The PHP Foundation.

Redesign php.net? We hear you. Let’s start small and ship something great: a refreshed PHP 8.5 release page. The 8.0-era page built with community contributors and JetBrains set the tone for 8.x. It’s held up, but 8.5 is a good moment to modernize: modern, clean, fast, inspiring.

We’re opening a design contest and you, the community, will help choose the winner. Read on for how to enter.

Prizes

• 🥇 Grand prize: USD $1,000 sponsored by JetBrains
• Honorable mentions (credit in the footer of the page)

What we’re looking for

A modern, lightweight design for the PHP 8.5 release page that:

• Keeps things simple: vanilla HTML/CSS, minimal/no JS, no new build tools or frameworks.
• Mobile-first & fast: responsive layouts, small assets, system fonts.
• Localizable: works with multiple languages, avoids text baked into images.
• Content-first: use existing 8.5 content as data.
• On-brand: feels at home on php.net; tasteful, unobtrusive visuals.
• Maintainable: straightforward markup that future contributors can edit.

Nice-to-have: a visual approach that can evolve for future releases (e.g., PHP 9.x).

What to submit

Please submit designs first (we’re not judging big code drops):

• Mockups or prototype (Issue to php/web-php).
• A short rationale (why this layout, how it meets the criteria).
• You can also link to PR with the implementation.
  Keep the code small and clean. We won’t review large generated codebases.

How to submit

Create a GitHub Issue in the php/web-php repository using Design Contest template:

Include:

• Link(s) to mockups/prototype
• 3–5 screenshots (desktop/mobile)
• Rationale (300–600 words)
• Your name (and teammates, if any)

See a pinned contest tracking issue with all entries for easy browsing.

Timeline (UTC)

• Submissions open: Oct 1, 2025
• Deadline: Oct 22, 2025, 23:59
• Shortlist announced: Oct 23, 2025
• Community vote: Oct 23–Oct 30, 2025
• Winner announced: Nov 1, 2025

How we’ll pick the winner

• Jury (40%): php.net maintainers Sergey, Luffy, Derick, Sara + design advisor Sergei Elin (JetBrains) evaluate against the criteria below.
• Community vote (60%): single-vote mechanism.
• Tie-breaker: jury decision.

Scoring criteria:

1. Clarity of content hierarchy
2. Responsiveness & mobile UX
3. Performance & simplicity (no deps, readable markup)
4. Fit with php.net look and tone

Rules & licensing

• Your submission must be your original work and free of restrictive third-party licenses.
• By entering, you agree your design (and any code you provide) will be licensed under the same terms as the php.net website (web-php repository) and may be adapted as needed.
• Team entries are allowed (max 1 entry per person/team).
• Judges and organizers cannot participate.
• We may decline to award if no entry meets the bar.
• Participants must be 18 years or older.
• Submissions from participants in restricted or sanctioned territories will not be considered.

Questions

Please ask in the pinned Contest issue in php/web-php. We’ll keep answers centralized and public.

Let’s make the PHP 8.5 release page a joy to browse – clear, fast, and friendly for everyone!

🐘💜