Industry Insights 37 min read

Goodbye PEAR: PHP 8.7 Ends 27-Year Official Endorsement

PHP Internals votes to end official PEAR endorsement in PHP 8.7, concluding a 27-year history where PEAR served as PHP's de facto standard library, pioneered coding standards and autoloading, but ultimately lost to Composer's project-isolated dependency management and modern ecosystem.

Open Source Tech Hub
Open Source Tech Hub
Open Source Tech Hub
Goodbye PEAR: PHP 8.7 Ends 27-Year Official Endorsement

PEAR History

In October 2026, the PHP core committee (Internals) held a formal vote on an RFC titled End PEAR Project Endorsement . The proposal calls for completely removing the bundled PEAR installer from PHP 8.7, converting pear.php.net into a static archive site, and stripping all PEAR recommendations from official PHP documentation and pages. Voting closes October 19, and the proposal is almost certain to pass.

For developers who started after Composer's birth, PEAR may seem like a dusty corner of php.net. But throughout the 2000s, PEAR was the closest thing to a "Standard Library" outside PHP core extensions . It was where a generation of PHP developers first ran a command-line install, first encountered coding standards, and first submitted code for global peer review.

Before PEAR

In 1999, PHP had no package manager. Reusing code meant scouring sites like PHP Classes (Manuel Lemos, 1999), HotScripts (early 2000s), and Zend Code Gallery . The workflow: download a .zip, extract to project, pray paths didn't break. Harry Fuecks (SitePoint, 2004) captured the chaos:

"Everyone heard from HotScripts: to install a PHP program, just unzip and run, right?"

Then came the classic error:

Warning: Failed opening 'lib/someClass.php' for inclusion.

Database connectivity was another nightmare. Early PHP provided incompatible native functions per database: mysql_query() for MySQL, pg_query() for PostgreSQL. Supporting multiple databases required writing a custom abstraction layer. PDO only became default in PHP 5.1 (Nov 2005) , and still couldn't rewrite vendor-specific SQL dialects. Worse, the community had zero consensus on code style, naming, or file structure — every project invented its own wheel .

Birth: PECL, Dedicated to a Newborn Daughter

On Nov 22, 1999 , core developer Stig Bakken committed DB.php (a database abstraction layer) to php-src under a new directory named PECL ( PHP Extension and Code Library ). His commit message ended: "I dedicate this piece of PHP code to my daughter Malin, born yesterday. :-)" The README stated PECL's goal: a standardized repository like TeX's CTAN or Perl's CPAN, providing a single authoritative code source.

Six days later, Bakken renamed it PEAR ( PHP Extension and Add-on Repository ), later finalized as PHP Extension and Application Repository (July 2000). The dedication to Malin remains in PEAR's manual credits today.

Building the Command-Line Installer

Over three years, PEAR's pieces coalesced in php-src:

July 2000: PEAR base class, PEAR_Error, and first CLI installer merged.

Jan 2001: Chuck Hagenbuch submitted the first PEAR Coding Standard — "initial coding standard doc, for everyone to start holy wars." It mandated 4-space indent, no tabs , and the if (...) { brace style.

2001: PHPUnit born on pear.php.net (Sebastian Bergmann); hosted there 2001–2006.

Apr 2002: Tomas V.V. Cox wrote go-pear script for one-line installer bootstrap.

2002: Classic libraries debuted: DB, Mail, Net_SMTP, HTML_QuickForm, Log.

PEAR 1.0 Bundled with PHP: The High Point

Dec 27, 2002 : PEAR 1.0 released alongside PHP 4.3.0 . Bakken announced: "From PHP 4.3.0, PEAR becomes an officially supported part of PHP. Unix systems will default-install PEAR installer and dependencies (Windows in 4.3.2). A long gestation." This bundling — severed by the 2026 RFC — made PEAR a default on every server. DreamHost (c. 2006) told customers: "All servers have PEAR pre-installed. When most people say PEAR they mean the DB package — rest assured, it's there." Even today, cPanel retains a "PHP PEAR Packages" manager.

The PEAR Developer Experience

Installing a package meant a global system command: pear install Mail Files downloaded to a global system directory added to PHP's include_path. Class names mapped to physical paths via underscores : Net_SMTP → Net/SMTP.php. Code required explicit require_once:

require_once 'DB.php';

// DSN driver string enables multi-database support
$db = DB::connect('pgsql://user:pass@localhost/app');

// Classic PEAR_Error pattern (pre-Exception era)
if (DB::isError($db)) {
    die($db->getMessage());
}

$result = $db->query('SELECT * FROM users');

PHP lacked exceptions until PHP 5. PEAR used PEAR_Error objects with DB::isError() static checks. This exact pattern powered Drupal 4.0 's non-MySQL database support.

Star Packages That Filled Core Gaps

PEAR's official repository plugged nearly every practical hole in early PHP core:

DB / MDB2 : de facto database abstraction standard.

Mail + Mail_Mime : essential for SMTP emails with attachments (still linked from php.net's mail() docs).

Net_SMTP : low-level mail protocol client.

HTML_QuickForm : form handling before modern template engines.

Log , Cache_Lite , Archive_Tar , XML_RPC .

Major projects depended heavily:

Drupal 4.0–4.5 : all non-MySQL DB via PEAR DB.

Horde : install step 1 = pear install Log Mail DB.

MediaWiki 1.5 : email via PEAR Mail.

Moodle 1.9 : bundled full PEAR dependencies for servers without PEAR.

Dedicated books appeared: Packt's PHP Programming with PEAR , The PEAR Installer Manifesto ; Apress's Foundations of PEAR .

Strict, Elite Governance

PEAR was no free-for-all. Every package endured brutal peer review. Early proposals posted to pear-dev mailing list. 2003: PEAR Group mandated one-week public vote, net score (yes minus no) > +5 to accept; negative votes required justification. 2004: PEPr (PEAR Proposal system) by Tobias Schlitt formalized draft → discuss → 7-day vote; each active maintainer votes -1, 0, +1. Manual warned: "Be prepared: people will scrutinize every line with a magnifying glass. Accept criticism."

This elite process yielded unmatched consistency — coding standards, directory layout, error design all uniform. For countless developers, PEAR standards were their first systematic professional engineering education . But evolution slowed; new-package barrier became daunting.

2003 Oct: C extensions split to pecl.php.net (PECL = PHP Extension Community Library); PEAR focused on pure-PHP. Both shared installer logic, keeping pear and pecl CLI tools tightly coupled for 15+ years. 2007: Gregory Beaver elected first PEAR president; after his 2010 term ended, no further elections held — governance effectively stalled .

Channels: Decentralization Attempt

PEAR 1.4 (Sep 2005) introduced Channels — third parties could host their own PEAR Channel servers, bypassing pear.php.net's slow vote. This reshaped the ecosystem:

2006: PHPUnit moved to pear.phpunit.de.

Symfony, Doctrine, others self-hosted channels.

But running a Channel server remained heavy. Fabien Potencier (Symfony creator) built Pirum (2009) — a single-file Channel manager — saying: "I developed Pirum because I was utterly frustrated with existing PEAR channel server implementations." Pirum's insight: a Channel server only needs static XML/package files. Public hosts like pearhub.org followed.

PHP 4 Legacy Baggage

PEAR prized backward compatibility, long meaning unconditional PHP 4 support . PHP 5 (2004) brought a new OO model; E_STRICT warned about PHP 4 habits — notably static calls to non-static methods:

Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context

Bug tracker flooded with such reports. 2006 RFC mandated new packages be E_STRICT -compatible from Jan 1, 2007, warning: "Clinging to PHP 4 compatibility not only blocks users upgrading to PHP 5, but turns PEAR into a dumping ground for abandoned legacy code." Yet old packages kept legacy code. PEAR installer itself only dropped PHP 4 support in Oct 2015 (v1.10.0)!

To embrace PHP 5.3 namespaces, community attempted PEAR2 rewrite with installer Pyrus . Started 2007, last release 2.0.0a4 (2012) — never left Alpha .

Composer & Packagist Take Over

Fabien Potencier, PEAR user since 2004 (Symfony 1 built on PEAR), grew frustrated: "PEAR's underlying design was never meant for modern modular development." He wanted a Bundler -like tool (Ruby). At a 2011 hackathon, he proposed using openSUSE's libzypp dependency solver.

Apr 2011: Nils Adermann commits first Composer code.

Jordi Boggiano joins, builds ecosystem.

Mar 2012: Composer 1.0.0-alpha1 released.

Boggiano (late 2011) nailed the core difference:

"PEAR is fundamentally a system-level global package manager , positioned like Linux's apt-get ."

This caused disaster in multi-project development: two projects needing different versions of same package couldn't coexist. Composer delivered a knockout:

Project isolation: dependencies in per-project vendor/.

Standard autoloading: out-of-the-box autoloader.

Decentralized publishing: Packagist.org — no approval committee, anyone can publish.

PEAR tried adapting: 2011 moved source to GitHub; 2012 Packagist added pear/ vendor namespace for legacy packages. But the tide turned:

Feb 2014: Fabien deprecates Pirum.

Apr 2014: PHPUnit shuts down its PEAR channel.

May 2014: Symfony stops PEAR releases; Fabien's farewell: "PEAR served the PHP community for so many years; I think it's time to let it die with dignity."

Composer 2.0 (Oct 2020) fully removed PEAR channel compatibility.

Final Glimmers & 2019 Security Nightmare

Late 2015, after a severe server outage, maintainer Christian Weiske blogged: "Active PEAR Group members down to ~1.5 people, basically me alone in spare time… server maintenance a one-person show." Yet PEAR 1.10 (PHP 7 support) saw 212,000 downloads in first three days. Community extracted pear-core-minimal so legacy projects depending on PEAR and PEAR_Error could limp along via Composer.

The death blow: Jan 2019 supply-chain attack . Unknown hackers replaced go-pear.phar on pear.php.net with a backdoored version that executed a Perl script to open a reverse shell to an external IP . The malicious file lurked nearly a month. GitHub-hosted code was clean, but official distribution channel compromised.

Two weeks later, core developer Nikita Popov proposed default-disable PEAR bundling from PHP 7.4 : "Not just due to the recent hack, but because of an undeniable fact — PEAR has been effectively unmaintained for a long time." After PHP core removed deprecated each(), PEAR threw deprecation errors on main branch for ages with no one noticing or fixing. From PHP 7.4, PEAR only installed if explicitly compiled with --with-pear (also marked Deprecated).

15-Year-Old Ghost Vulnerabilities

PEAR code kept appearing in CVE alerts. Drupal still used Archive_Tar; 2019–2021 forced multiple core security patches for its high-severity flaws. 2022: SonarSource researcher Thomas Chauchefoin disclosed two 15+ year-old critical vulnerabilities in pearweb (pear.php.net backend) :

Weak password-reset token randomness: predictable tokens; <50 attempts to hijack any package maintainer account, enabling global malicious version distribution.

Server RCE: relied on ancient unpatched Archive_Tar copy, allowing arbitrary command execution on the official server.

SonarSource estimated 2.85 billion package downloads from this compromised server over PEAR's history. Patches finally applied March 2022.

Endgame: A Dignified Exit

Multiple attempts to sever PHP-PEAR ties:

2016: Davey Shafik proposed unbundling PEAR/PECL in favor of Composer/Pickle — no vote.

Sep 2025: James Titcumb's RFC passes overwhelmingly: deprecate PECL, adopt modern PIE (PHP Installer for Extensions) .

James then proposed deprecating PEAR but withdrew due to complex historical governance disputes, calling it "a bottomless can of worms."

Breakthrough 2026: Nick Sdot took a pragmatic, restrained approach with End PEAR Project Endorsement RFC:

"This RFC does not intend to forcibly shut down or kill PEAR. Its sole demand: end the official endorsement relationship between PHP and PEAR. " Remove bundled source code. Stop PHP-official maintenance of pear.php.net domain/infrastructure. Remove all recommendation links from php.net. If community wants to continue PEAR, they can do so on their own independent domain.

RFC cited brutal realities: PHP core team lost actual control of pear.php.net server; search broken for years; pages littered with gambling/casino spam ads; of 603 remaining packages, 534 explicitly marked 'unmaintained'.

Remarkably, PEAR's last elder supported it. Chuck Burgess (PEAR Group member since 2008) endorsed shutting down main site and stripping PEAR from PHP source, even salvaging lost historic bug-tracker data. Core developer Rowan Tommins noted: "Chuck is the only PEAR elder we could reach after months of searching. If the whole world yields just one person, we can responsibly confirm: no one is interested in maintaining this project anymore."

Execution roadmap: pear.php.net → read-only static archive ; existing pear CLI can still fetch old packages until Dec 31, 2027 .

After 2027: site packaged as pure historical tarball for download.

Veteran Derick Rethans proposes final tarball to museum.php.net (PHP History Museum) "for future computer archaeologists."

PEAR's Living Legacy

Though pear.php.net enters the archive, PEAR's DNA runs through modern PHP:

Modern Coding Standards: PHP_CodeSniffer (2006) started as a PEAR package; its default ruleset remains PEAR standard. Industry-unifying PSR-2 heavily referenced PEAR's spec.

Autoloading Revolution: PEAR's "underscore maps to directory" concept directly birthed PHP-FIG's PSR-0 , the first autoloading standard that powered Composer's early dominance.

Code Still Running: On Packagist, pear/ vendor packages number in hundreds. pear/pear_exception, pear/pear-core-minimal, pear/console_getopt, pear/archive_tar — each exceeds 70 million total installs . Modern Drupal core still depends on Archive_Tar.

Incubator of Giants: PHPUnit , PHP_CodeSniffer , phpDocumentor — all infrastructure pillars of today's PHP ecosystem — were born on humble pear.php.net.

In 2019, consultancy thePHP.cc assessed: "PEAR was the single most critical engine that pushed the entire PHP language toward industrial-grade professionalism."

Composer inherited PEAR's mantle, amplified its wisdom, and decisively shed its bloated baggage. This vote ends only the 27-year official authorization bond; but that code seed planted in 1999 for a newborn daughter has long since become the indelible soil and nutrients of modern PHP's vast forest.

Complete PEAR Timeline (1999–2027)

1999-11-22: Stig Bakken commits PECL initial code to php-src; DB.php first file.

1999-11-28: PECL renamed PEAR (PHP Extension and Add-on Repository).

2000-07-28: Formal name: PHP Extension and Application Repository.

2001-01-05: First PEAR Coding Standard committed (4 spaces, no tabs).

2002-04-27: One-click install script go-pear introduced.

2002-12-27: PEAR 1.0 released with PHP 4.3.0 ; Unix default bundle.

2003-08-12: First PEAR Group governance committee formed.

2003-10-15: C extensions split to pecl.php.net.

2004-01-25: PEPr proposal/voting system launched.

2005-09-18: PEAR 1.4.0 adds Channel (third-party channels) feature.

2005-11-04: PEAR 1.4.3 fixes critical installer execution vulnerability.

2005-11-24: PHP 5.1.0 releases, PDO enabled by default; DB abstraction landscape shifts.

2006: PHPUnit moves to independent Channel.

2007-01-01: New rule enforced: new packages must be PHP 5 E_STRICT compatible.

2007-03: PEAR Constitution ratified; Gregory Beaver elected first president (May).

2009-11-28: Fabien Potencier open-sources single-file channel tool Pirum.

2011-04-05: Composer first commit.

2011-11-05: PEAR begins GitHub migration.

2012-03-01: Composer 1.0.0-alpha1 released.

2012-11-05: Next-gen installer Pyrus stalls at 2.0.0a4, dies.

2014-02: Pirum officially deprecated.

2014-04-21: PHPUnit terminates PEAR channel distribution.

2014-05-05: Symfony stops PEAR packages; declares PEAR era over.

2015-10-07: PEAR 1.10.0 released — after 11 years, finally drops PHP 4 compatibility , adds PHP 7 support.

2016-09-01: Davey Shafik proposes unbundling PEAR/PECL RFC; no vote.

2019-01-19: pear.php.net discovers go-pear.phar backdoored; emergency shutdown.

2019-02-11: Nikita Popov submits PR: PHP source defaults to disable PEAR.

2019-11-28: PHP 7.4.0 released; no longer bundles PEAR by default.

2020-10-24: Composer 2.0 removes all PEAR channel compatibility.

2022-03-29: SonarSource discloses 15+ year-old account takeover & RCE vulnerabilities in pearweb.

2025-09-20: Community vote passes PECL deprecation; adopts modern PIE .

2025-10-09: James Titcumb proposes PEAR deprecation; withdraws due to resistance.

2025-10-10: Jakub Zelenka starts cleaning residual PEAR/PECL logic from php-src.

2026-08-27: Nick Sdot submits "End PEAR Project Endorsement" RFC.

2026-10-05: RFC voting opens (closes Oct 19, near-certain passage).

2027-12-31: (Planned) Read-only static archive period ends; site packaged into museum cold storage.

Did You Use PEAR When You Started?

What package did you first install with pear install? Which old code remains unforgettable? Share your early PHP development memories in the comments.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

dependency managementPHPComposerpackage managementPEARPHP 8.7PHP historyPSR standards
Open Source Tech Hub
Written by

Open Source Tech Hub

Sharing cutting-edge internet technologies and practical AI resources.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.