A new RFC asks PHP internals to stop endorsing PEAR. End PEAR Project Endorsement, authored by Nick Sdot, moved to discussion on August 27. It would unbundle the PEAR installer from PHP source, remove PEAR references from official php.net sites, and replace the live pear.php.net website with a static archive that keeps the PEAR command line client working.

PEAR is the PHP Extension and Application Repository. As the RFC puts it, PEAR "was historically promoted as a framework and distribution system for reusable PHP components." It was how PHP developers shared code before Composer. It still lives on a php.net subdomain and ships inside PHP source releases.

That's the part the RFC targets. It argues the relationship "has become a liability for the PHP project," since PHP has no access to the PEAR infrastructure or website even though it runs under the official domain.

What the RFC Proposes

The proposal lists four actions.

Every relevant public page of the current PEAR site would be served as a static archive, including package details, downloads, manuals, and public bug reports. The PEAR CLI endpoints keep working, so legacy installs don't break. A preview of the archive is online already, and the infrastructure team would decide the technical details.

PHP source would no longer install or bundle the PEAR installer. That follows an existing php-src pull request from Jakub Zelenka that removes PEAR and its integration, and the RFC targets PHP 8.7 for the change.

References to PEAR would come off official PHP websites, with Composer named as the community package manager. The RFC is explicit that this doesn't make Composer a PHP project and doesn't change how Composer is governed.

The PEAR mailing lists on news-web.php.net would move to the "Inactive Lists" section.

Why Now

The RFC describes a site with broken links, missing package pages that still have live bug trackers, broken documentation downloads, a search that doesn't work, and visible spam such as casino links. The PEAR web repository itself was recently archived.

It also puts numbers on the activity. Based on PEAR metadata read on June 22, 2026, 534 of 603 packages are marked unmaintained, and 63 of the remaining 69 have gone a long time without an update. Only six packages still publish to PEAR at all. In the discussion thread, Nick Sdot broke those six down further: three are PEAR infrastructure packages, two were recently marked unmaintained by a PEAR Group member, and one is an independent package that is still maintained, Net_SMTP, which is also on Packagist.

This isn't the first attempt. Two earlier RFCs, one in 2016 and one in 2025, covered similar ground and never went to a vote. The author says he spent about three months reading through those past discussions and built the static mirror, then gave a cooperative fix another two months to play out, with the PHP Foundation aware of the effort. The RFC's own changelog shows it sitting as a draft from June 24 until this week.

He ended his announcement to the list this way:

We win nothing by further stalling a decision; I believe we should stop the endorsement for PEAR.

Rowan Tommins backed that reasoning in the thread:

If that's not long enough, how long is? If the site stays alive in its current state for 10 years, it will continue to be exploited by spammers and probably worse. That's not in anyone's interest.

What It Doesn't Propose

The RFC is not a takeover of PEAR. Its stated non-goal: "The goal is not to take over the governance of the independent PEAR package ecosystem." If a team wants to keep PEAR running, they're free to do it on domains they control. PHP internals can't vote to stop that, and the RFC says so directly. What internals can decide is what PHP bundles, what php.net domains serve, and what official sites point people toward.

The RFC lists two effects on your code. PEAR no longer ships with PHP, so you'd install it by hand if you want it. And anyone using one of the six packages still publishing to PEAR would switch to the Composer version.

Freezing Versus Removing

The most substantive question in the thread so far is what a frozen channel does to security. Rowan Tommins pointed at a post by Andrew Nesbitt on sunsetting a package manager and summarized the tradeoff:

One of the points he discusses is that freezing a channel rather than taking it offline means that security vulnerabilities are also frozen in place, with no way to supersede them for anyone still using the old tooling.

He added:

I think readonly is probably the right approach in this case at least in the short term, but actively sunsetting later is maybe something to consider.

Nick Sdot agreed, and noted that the infrastructure team would also prefer sunsetting eventually. The RFC already puts that in its Future Scope section: the browsable archive is meant to be temporary so legacy projects don't break abruptly, and it should be removed later rather than consume project resources forever.

He argued the frozen vulnerabilities matter less here than they would elsewhere, given the package count:

I think we can safely say that security is not a very pressing concern in this very situation; and that keeping the CLI alive for a while is to demonstrate good manners rather than serving high demand.

One loose end came up around the archive itself. Only bug reports that are reachable on the live PEAR site made it in, because many pages now return an error about unconfirmed email addresses. Nick Sdot said he skipped the error pages instead of archiving them, considers recovering old bugs from archive.org snapshots out of scope, and offered to backfill the missing reports at any point if an admin provides a database dump.

What Happens Next

The RFC is at version 0.9 and listed as under discussion. No vote has opened and none is scheduled. When one does, it needs a 2/3 majority to pass.

You can read the full proposal in End PEAR Project Endorsement and follow the discussion on externals.io. We cover more proposals like this under RFC.