In October 2026, PHP internals voted on the End PEAR Project Endorsement RFC. It unbundles the PEAR installer from PHP 8.7, turns pear.php.net into a static archive, and takes PEAR off official PHP websites. Voting closes on October 19 and it looks like it's going to pass.

We've covered what the RFC proposes and how it got to a vote. This one goes back to the start.

If you started writing PHP after Composer came out, PEAR probably looks like a dusty corner of php.net. For most of the 2000s, though, it was the closest thing PHP had to a standard library outside the core. It's where a lot of developers first installed a package from the command line, first read a coding standard, and first had their code reviewed by people they'd never met.

Before PEAR

In 1999, PHP had no package manager. If you wanted someone else's code, you went looking for it. PHP Classes, which Manuel Lemos started in 1999, collected freely available classes. HotScripts listed PHP scripts by early 2000. Zend later ran a Code Gallery of PHP snippets. You downloaded a zip, unpacked it into your project, and hoped the paths worked.

Harry Fuecks described the result in a 2004 SitePoint article:

Everyone knows, from Hotscripts, that to install a PHP application, you just unzip and go, right?

He followed it with the error everyone from that era has seen, "Failed opening 'lib/someClass.php' for inclusion."

Databases were their own problem. PHP gave you a different set of functions for each database, like mysql_query() for MySQL and pg_query() for PostgreSQL. If your app needed to support more than one, you wrote that layer yourself. PDO didn't ship enabled by default until PHP 5.1 in November 2005, and even PDO doesn't rewrite SQL for you.

There also wasn't much shared agreement on how PHP code should look, how classes should be named, or where files should live. Every project made it up.

It Started as PECL

On November 22, 1999, Stig Bakken made a commit to php-src that added a database abstraction layer called DB.php in a new directory. He called the project PECL, the "PHP Extension and Code Library," and ended the commit message with a personal note:

I hereby dedicate this part of PHP to my daughter-of-yesterday Malin. :-)

His daughter had been born the day before. The README in that commit explained the idea:

PECL is a code repository for PHP extensions and PHP library code similar to TeX's CTAN and Perl's CPAN.

It continued:

The intention behind PECL is to provide a means for library code authors to organize their code in a defined way shared by other developers, and to give the PHP community a single source for such code.

Six days later, Bakken renamed it to PEAR, the "PHP Extension and Add-on Repository." In July 2000 it changed again to the name that stuck, the PHP Extension and Application Repository. The PEAR manual still dedicates the project to Malin.

Building the Installer

The pieces came together over the next three years, mostly inside php-src.

  • July 2000. The PEAR and PEAR_Error base classes, plus the first installer class, landed in php-src.
  • January 2001. Chuck Hagenbuch committed the first PEAR Coding Standards with the message "initial coding standards doc for all to argue over." It called for four-space indents, no tabs, and the if (...) { brace style.
  • 2001. PHPUnit started life on pear.php.net. Sebastian Bergmann's project was released there from 2001 until 2006.
  • April 2002. Tomas V.V. Cox added go-pear, a script that downloaded and installed the PEAR installer for you.
  • 2002. Packages that a generation of PHP developers relied on got their first releases on pear.php.net, including DB, Mail, Net_SMTP, HTML_QuickForm, and Log.

PEAR 1.0 Ships With PHP

PEAR 1.0 came out on December 27, 2002, the same day as PHP 4.3.0. Bakken announced it on pear.php.net:

As of PHP 4.3.0, PEAR is an officially supported part of PHP. From this release, the PEAR installer with all its prerequisites is installed by default on Unix-style systems (Windows will follow in 4.3.2). It has been a long pregnancy.

This is the relationship the 2026 vote ends. From PHP 4.3.0 on, a standard PHP build put a pear command on your system, along with a set of bundled packages.

That made PEAR something you could count on. DreamHost's knowledge base from around 2006 told customers that PEAR was "installed on all servers," and added, "Most people mean the DB package when they speak of PEAR -- and it's there." cPanel still has a PHP PEAR Packages screen for adding packages to a hosting account.

What Using PEAR Was Like

From a terminal, you installed a package system-wide:

pear install Mail

PEAR put the files in a shared directory that had to be on PHP's include_path. Class names mapped to file paths, with underscores becoming directories, so Net_SMTP lived in Net/SMTP.php. Your code loaded it with require_once.

Errors worked differently too. Instead of exceptions, PEAR functions returned a PEAR_Error object when something failed, and you checked for it. Here's the pattern, close to how Drupal 4.0 connected to databases other than MySQL:

require_once 'DB.php';

$db = DB::connect('pgsql://user:pass@localhost/app');

if (DB::isError($db)) {
    die($db->getMessage());
}

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

The connection string picked the database driver, so the same code could talk to MySQL, PostgreSQL, or others. In 2004, Fuecks called DB "probably PEAR's most widely used package."

If you were on shared hosting without shell access, the PEAR manual walked you through making a local copy and pointing set_include_path() at it.

The Packages Everyone Used

PEAR's catalog covered the things PHP didn't do well on its own. Some of the most used:

  • DB and later MDB2 for database abstraction. MDB2 was a merge of DB and Manuel Lemos's Metabase.
  • Mail and Mail_Mime for sending email with attachments over SMTP. The php.net manual's mail() page still points you to them.
  • Net_SMTP for talking to mail servers directly.
  • HTML_QuickForm for building and validating forms.
  • Log, Cache_Lite, Archive_Tar, and XML_RPC.

Big applications of the era leaned on them. Drupal 4.0 through 4.5 used PEAR DB for every database except MySQL. Horde's install docs told you to run pear install for Log, Mail, Mail_Mime, DB, and more. MediaWiki 1.5 needed PEAR Mail to send email over SMTP. Moodle 1.9 bundled its PEAR packages, explaining in a README:

We include these in Moodle solely for the convenience of sites that may not have PEAR installed.

PEAR was big enough to get its own books. Packt published PHP Programming with PEAR and Gregory Beaver's The PEAR Installer Manifesto in 2006, and Apress published Foundations of PEAR.

Getting a Package Into PEAR

PEAR wasn't a place where you published whatever you wanted. New packages went through review.

Early on, you proposed a package by email to the pear-dev mailing list. In 2003, the PEAR Group wrote down the rules: developers voted for a week, and a proposal passed "if the total of all votes exceeds +5." Anyone voting -1 had to explain why.

In January 2004, PEAR switched to PEPr, the PEAR Proposal system built by Tobias Schlitt. A proposal moved through draft, discussion, and a seven-day vote, and every active PEAR maintainer got one vote of -1, 0, or +1. A total of five or more meant acceptance. The manual warned proposers:

Be aware that people will scrutinize your code, so be prepared for criticism

This review process is a big part of why PEAR packages had a reputation for consistency. Every package followed the same coding standard, the same directory layout, and the same error handling. For a lot of developers, PEAR's standards were the first ones they ever followed. The finished proposals list has 312 entries.

It also meant PEAR moved slowly, and getting a package in took real effort.

Governance

In August 2003, Bakken appointed the first PEAR Group, eight developers including Lukas Smith, Pierre-Alain Joye, Martin Jansen, and Tomas V.V. Cox. He explained its purpose on pear-dev:

I would like to emphasize that the purpose of the PEAR Group is not to add bureaucracy, but to ensure that decisions are being made, efficiently and fairly.

That October, the C extensions moved to their own site at pecl.php.net. PECL now meant the "PHP Extension Community Library," while PEAR kept the PHP code. The two kept sharing an installer, which is why the pear and pecl commands stayed tied together for years.

In 2007, PEAR developers voted on a constitution. The ballot said "PEAR has not moved fast enough to keep up with innovation," and the option for an elected group and president won with 65.79%. Gregory Beaver became the first president, and David Coallier won the next two elections.

The PEAR Group page still lists the 2009 to 2010 group. There's no record of an election after that.

Channels

PEAR 1.4, released in September 2005, added channels. Any project could now run its own PEAR server and publish packages there, without going through pear.php.net's review.

Six weeks later, PEAR shipped a security fix. Version 1.4.3 closed a vulnerability where a malicious package could run code every time you ran the pear command. Beaver's advisory rated it low risk, since you had to install the bad package yourself.

Channels changed how PEAR was used. PHPUnit moved to its own channel at pear.phpunit.de in 2006. Symfony, Doctrine, and others followed with channels of their own.

Running a channel server wasn't simple, though. In 2009, Fabien Potencier released Pirum, a single-file channel server, and explained why:

Pirum comes from my frustration with the current state of PEAR channel servers.

His point was that a channel was really a set of static files: "hosting a PEAR channel server is super simple. It's all about static files." Symfony, PHPUnit, Swift Mailer, and Twig used it. In early 2010, sites like pearfarm and pearhub.org appeared to host channels for anyone.

The PHP 4 Problem

PEAR valued backward compatibility, and for years that meant supporting PHP 4. PHP 5 arrived in 2004 with a new object model, and PHP 5's E_STRICT mode started flagging PHP 4 habits. The most common one was calling PEAR::isError() statically. PEAR's bug tracker filled up with reports like this one from 2006:

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

In 2006, PEAR developers accepted an RFC requiring new packages to be E_STRICT compatible. Its problem statement was frank. Supporting PHP 4 "slows the adoption of PHP version 5 by users of PEAR," it said, and PEAR "risks becoming a garbage dump of obsolescent code, or at least be perceived as one."

The rule applied to new code starting January 1, 2007. Existing packages could keep going as they were. The PEAR installer itself didn't drop PHP 4 support until version 1.10 in October 2015.

PEAR2 and Pyrus

PEAR's answer to PHP 5 was PEAR2. Its coding standards, written in late 2007, required namespaces and targeted PHP 5.3. Pyrus was the new installer, described in its manual as "a re-factored version of the PEAR installer, re-designed for new features available in PHP 5.3."

Beaver started Pyrus in 2007. Its last tag was 2.0.0a4 in November 2012, and it never left alpha. In 2010, Till Klampaeckel wrote:

PEAR2 is taking a while and I sometimes think that everyone associated with PEAR is busy elsewhere.

Every package page on pear.php.net still says "Try PEAR2's installer, Pyrus."

Composer

Potencier had been using PEAR since 2004, and used it for symfony 1 plugins, but said "the code was really messy as PEAR was not built with that use case in mind." He wanted something closer to Ruby's Bundler. At a 2011 hack day, he pointed Nils Adermann toward libzypp, the dependency solver from openSUSE. Adermann made the first Composer commit in April 2011, and Jordi Boggiano built the rest of the system around it.

According to Packagist's own history, packagist.org first launched "as a PEAR proxy for now." Composer's first tagged release, 1.0.0-alpha1, came in March 2012.

Boggiano laid out the difference in a December 2011 post:

PEAR started as a system-wide package manager, much like apt-get

That didn't work well when several projects on one machine needed different versions of the same package. "You can't easily install both versions at the same time, and lots of frustration ensues," he wrote. Composer installed packages per project, into a vendor/ directory, with an autoloader. He also pointed out that there was no approval process to get a package onto Packagist.

PEAR's maintainers adapted where they could. In November 2011, they began moving PEAR development to GitHub. PEAR packages started showing up on Packagist under the pear/ vendor in 2012.

The big channels closed anyway. In February 2014, Potencier deprecated Pirum. In April, PHPUnit announced the end of its PEAR channel, and pear.phpunit.de shut down at the end of the year. In May, Symfony stopped publishing PEAR packages, and Potencier wrote:

PEAR served the PHP community for many years, and I think it's time now to make it die.

Composer kept the ability to install from PEAR channels until Composer 2.0 in October 2020, which removed it.

Running on Fumes

In December 2015, after a server outage, Christian Weiske described the state of the project on the PEAR blog:

The number of active people in the PEAR group has shrunken to about 1.5, with Christian Weiske doing most of the work.

He added that "server maintenance thus will continue to be a one-man spare-time show." The same post noted 212,000 downloads in the first three days after PEAR 1.10 added PHP 7 support.

That same year, PEAR published pear-core-minimal, a slimmed-down copy of PEAR's core classes for Composer packages that still depended on PEAR and PEAR_Error.

The 2019 Breach

In January 2019, the PEAR team found that go-pear.phar on pear.php.net had been replaced with a tainted copy, and took the site offline.

The team later said the file was planted after the last official release on December 20, 2018, so downloads in roughly the following month were at risk. According to The Hacker News, the modified installer would "spawn a reverse shell via Perl" to an outside IP address. The copy on GitHub was clean.

Two weeks later, Nikita Popov proposed turning off PEAR installation by default in PHP 7.4:

It's not really the recent security breach itself, but rather the underlying issue that PEAR simply isn't actively maintained anymore.

He noted that PEAR had been throwing deprecation errors on PHP's master branch since each() was removed, and nobody had noticed or fixed it. The change landed without an RFC. Since PHP 7.4, you've needed --with-pear to get PEAR at all, and that flag has been deprecated from the start.

Fifteen-Year-Old Bugs

PEAR code kept showing up in security advisories. Drupal core still used Archive_Tar, and between 2019 and 2021 Drupal shipped several security releases for Archive_Tar vulnerabilities.

In 2022, Thomas Chauchefoin at SonarSource published two bugs in pearweb, the code that runs pear.php.net. Both had been exploitable for more than 15 years.

The first was in password resets. The tokens were predictable enough that an attacker could find a valid one "in less than 50 tries" and take over any developer account, then publish a malicious release. The second was an outdated copy of Archive_Tar that allowed remote code execution on the server. SonarSource estimated that about 285 million packages had been downloaded from pear.php.net over its lifetime. The fixes shipped in March 2022.

Ending It

People had tried to end PHP's official ties to PEAR before. In 2016, Davey Shafik proposed unbundling PEAR and PECL in favor of Composer and Pickle. It never went to a vote.

In 2025, James Titcumb made two proposals. His RFC to deprecate PECL in favor of PIE, the PHP Installer for Extensions, passed in September. His follow-up to deprecate PEAR ran into the question of who actually controlled PEAR, since the PEAR Group is separate from the PHP project. He withdrew it:

I withdrew the RFC because it seems this is a can of worms.

The next day, Jakub Zelenka opened a php-src pull request to remove PEAR and PECL from the PHP source.

In 2026, Nick Sdot took a narrower approach. His RFC doesn't try to shut PEAR down. It ends PHP's endorsement: no more bundling, no more pear.php.net under PHP's control, no more links from php.net. If anyone wants to keep PEAR going, they can do it on their own domain. The RFC laid out the state of things plainly: the PHP project had no access to pear.php.net, the site had broken search and casino spam, and 534 of 603 packages were marked unmaintained.

What made this attempt different was that someone from PEAR agreed. Chuck Burgess, a PEAR Group member since 2008, told Sdot he supports sunsetting the site and removing PEAR from PHP source. He also recovered lost bug reports for the archive. Rowan Tommins noted how hard it had been to reach anyone:

In practice, he's the only person involved who anyone has managed to track down, and even that took several months, so I think we're safe to say nobody's that interested.

Under the RFC, a static archive keeps the pear command line client working until December 31, 2027. After that, the archive becomes a download. Derick Rethans suggested moving a tarball to museum.php.net "for archeologists."

What PEAR Left Behind

Even with pear.php.net archived, a lot of PEAR is still around.

  • Coding standards. PHP_CodeSniffer, which got its start on pear.php.net in 2006, still ships a PEAR standard and uses it as the default when you don't pick one. PEAR was one of the projects surveyed for PSR-2.
  • Autoloading. PEAR's underscore-to-directory class naming is the same mapping PSR-0 standardized, and PSR-0 is what Composer's first autoloader followed.
  • Packages. The pear/ vendor on Packagist has over 100 packages. pear/pear_exception, pear/pear-core-minimal, pear/console_getopt, and pear/archive_tar each have more than 70 million installs, mostly as dependencies of other packages. Drupal core still requires Archive_Tar.
  • People and tools. PHPUnit, PHP_CodeSniffer, and phpDocumentor all started as PEAR packages.

In 2019, the team at thePHP.cc summed up PEAR's place this way:

PEAR was a significant driver for the professionalization of PHP

Composer took some of PEAR's ideas and dropped others on purpose, and PEAR code still lands in vendor/ directories every day. The RFC leaves all of that alone. What it ends is PHP's endorsement, 27 years after Stig Bakken's first commit.

Timeline

  • 1999-11-22: Stig Bakken commits PECL to php-src, with DB.php as the first code.
  • 1999-11-28: PECL is renamed PEAR, the PHP Extension and Add-on Repository.
  • 2000-07-28: The name becomes the PHP Extension and Application Repository.
  • 2001-01-05: The first PEAR Coding Standards are committed.
  • 2002-04-27: go-pear is added.
  • 2002-12-27: PEAR 1.0 ships alongside PHP 4.3.0, installed by default on Unix systems.
  • 2003-08-12: The first PEAR Group is announced.
  • 2003-10-15: PECL moves to pecl.php.net.
  • 2004-01-25: PEPr becomes the official proposal system.
  • 2005-09-18: PEAR 1.4.0 adds channels.
  • 2005-11-04: PEAR 1.4.3 fixes an installer vulnerability.
  • 2005-11-24: PHP 5.1.0 ships with PDO enabled by default.
  • 2006: PHPUnit moves to its own channel.
  • 2007-01-01: New PEAR packages must be E_STRICT compatible.
  • 2007-03: PEAR adopts a constitution. Gregory Beaver becomes the first elected president in May.
  • 2009-11-28: Fabien Potencier announces Pirum.
  • 2011-04-05: First Composer commit.
  • 2011-11-05: PEAR development starts moving to GitHub.
  • 2012-03-01: Composer 1.0.0-alpha1.
  • 2012-11-05: Pyrus 2.0.0a4, its last release, still alpha.
  • 2014-02: Pirum is deprecated.
  • 2014-04-21: PHPUnit ends PEAR distribution.
  • 2014-05-05: Symfony stops publishing PEAR packages.
  • 2015-10-07: PEAR 1.10.0 drops PHP 4 and adds PHP 7 support.
  • 2016-09-01: Davey Shafik proposes unbundling PEAR and PECL. The RFC never goes to a vote.
  • 2019-01-19: pear.php.net goes offline after a tainted go-pear.phar is found.
  • 2019-02-11: php-src disables PEAR by default, effective in PHP 7.4.
  • 2019-11-28: PHP 7.4.0 ships without PEAR by default.
  • 2020-10-24: Composer 2.0 removes PEAR channel support.
  • 2022-03-29: SonarSource publishes two 15-year-old pearweb vulnerabilities.
  • 2025-09-20: The vote to deprecate PECL in favor of PIE closes and passes.
  • 2025-10-09: James Titcumb proposes deprecating PEAR, then withdraws the RFC.
  • 2025-10-10: Jakub Zelenka opens a php-src pull request to remove PEAR and PECL.
  • 2026-08-27: The End PEAR Project Endorsement RFC goes to discussion.
  • 2026-10-05: Voting opens. It closes on October 19.
  • 2027-12-31: The browsable PEAR archive is scheduled to become a download.

Read More