PHP Moves to End PEAR Endorsement: What It Means for Legacy Projects

A new PHP RFC, moved to discussion on 27 August 2026, proposes formally ending the project’s endorsement of PEAR — the package manager that predates Composer by over a decade. It hasn’t gone to a vote yet, but the direction is clear, and it’s worth understanding now rather than when PHP 8.7 actually ships.

What’s Actually Changing?

The RFC proposes four concrete steps:

• A static archive of PEAR’s package listings, downloads, and documentation, preserved for legacy access via a working CLI endpoint
• Removal of the PEAR installer from official PHP source distributions, targeted for PHP 8.7
• Official PHP documentation and communications updated to point developers to Composer instead
• PEAR’s mailing lists moved to an inactive/archived section on news-web.php.net

None of this deletes PEAR outright — it stops being bundled and stops being the thing PHP.net actively recommends.

Why Now?

The rationale in the RFC is blunt: PEAR’s own infrastructure is in poor shape despite living on a php.net domain — broken search, visible spam, and by the RFC’s own count, 534 of PEAR’s 603 packages were unmaintained as of June 2026. Two earlier attempts to formally deprecate PEAR, in 2016 and 2025, never made it to a vote. This is the third attempt, and the first with a working alternative (Composer) that’s been the de facto standard for a decade.

Does This Affect You?

For most modern WordPress, Adobe Commerce, and Shopify work, honestly — no. PEAR has been functionally dead in modern PHP development for years; Composer’s autoloading and dependency resolution replaced it long before this RFC existed. The RFC itself notes only six packages currently publish to PEAR at all, which tells you most of the ecosystem already left.

Where this actually bites is legacy codebases — the kind we get called into after a business has been running on the same PHP application for a decade and nobody currently on staff wrote the original dependency list. We still come across pear install calls and PEAR-style require_once includes buried in older platform integrations more often than you’d expect, usually in exactly the kind of inherited system that’s never had a proper technical audit.

What Should You Do?

1. Grep any legacy codebases for pear install, PEAR::, or PEAR-style require_once package includes
2. Check whether a Composer-compatible replacement package already exists — for the six packages still actively on PEAR, most already do
3. If you’re on PHP 8.4+ (our own baseline), you’re already unaffected by the unbundling itself — this is a “check your dependencies” item, not an urgent upgrade blocker

If step 1 turns up more than you expected, that’s usually a sign the codebase hasn’t had sustained attention in a while rather than a crisis on its own — which is exactly the kind of gap a development retainer is built to catch before it becomes one. And if what you find is tangled into a bigger system integration or you’re looking at a full platform move rather than a dependency swap, that’s a data migration conversation, not a quick fix.

We’ll keep an eye on the RFC as it moves toward a vote and update this if the timeline or scope changes.