Getting Started with PEAR - PHP's Low Hanging Fruit

The last time you built an application with PHP, how much time did you spend plumbing?

"Plumbing?!?" you cry. "I was writing code, not fixing the drain!"

What I'm really talking about is this: in your last PHP project, how much time did you spend writing code that had been done before? Did you develop a complete user authentication system? How long did it take you to build that menu system? Did you struggle to send HTML emails with PHP? You know -- all those things that have been done time and again in PHP.

In this article, I'll be introducing you to PEAR, which, in short, helps you avoid becoming a plumber, and focus instead on getting projects done on time. On the menu today:

• Why pick PEAR? Keep the doctor away!
• A Short History: Of PEAR and confusion
• Installing PEAR: Get up and running
• The Package Manager: Finding your way around
• Instant RSS: Feed yourself with PEAR

Why Pick PEAR?

Your client asks you to build an online shop. Where do you begin? With budget and time constraints in mind, the less effort you expend reinventing wheel the better.

PHP comes with loads of built in functionality, like htmlentities() and strip_tags(), which do a lot to make building Web applications easier, but you won't find functions like shopping_cart(), for obvious reasons.

The more time you spend writing "plumbing code" -- stuff that could apply to many Web applications -- the greater the risk of your project missing deadlines or going over-budget.

Enter: PEAR. Although images of fruit come to mind, PEAR actually stands for "The PHP Extension and Application Repository" and is touted as "a framework and distribution system for reusable PHP components." Put another way, PEAR provides the plumbing you need to finish your project on time.

Taking a step back; one way to characterize source code is to consider it in terms of the domain it applies to, as described here.

PEAR primarily targets the "Architecture Domain": code that can be re-used in many applications, but targets a particular architecture (namely, Web applications). The majority of the "packages" provided by PEAR solve specific problems that are commonly encountered by those building Web apps, irrespective of the type site being built.

For example, PEAR::Validate provides a library of common validation routines, helping you to validate anything from a URL (very important if you want to prevent XSS exploits) to International Bank Account Numbers (IBAN). You could easily find reasons to re-use PEAR::Validate in all sorts of applications, saving yourself a lot of effort and avoiding the possibility that your alternative -- a regular expression -- has a nasty hole in it (because there was no time for careful testing).

A Short History

If you want to observe "wild and varied reactions", mention PEAR to a crowd a PHP developers. As a subject for debate, it provokes all kinds of responses, and it quickly becomes apparent that there's some confusion surrounding PEAR.

The PEAR project began in the mind of Stig Bakken (who's name you've probably run into via the PHP Manual). Legend has it that Stig wanted to create something like Perl's CPAN (a massive repository of re-usable Perl solutions) for PHP.

Work on PEAR began in November, 1999, with the beginnings of what is probably PEAR's most widely used package, PEAR::DB. Over the next three years, a small community of contributors grew up around PEAR, gradually shaping it into its first Public Release (1.0) in January, 2003.

In fact, "Public Release" is rather a misnomer. As with many Open Source projects, PEAR's development was always "public", via the PHP CVS servers, while the PEAR Website first showed up in October 2000, albeit "under construction". This may inadvertently have set expectations too early. To talk about a "release" of PEAR may also be little confusing; PEAR::DB, for example, was available ahead of time, as a stable release, in April 2002 (version 1.2). PEAR is, after all, not a single entity, but an infrastructure for code distribution and the all libraries (or packages) stored in the repository.

The end effect was that we had developers who knew what was going on with PEAR, talking about it as far back as May 2001 (An Introduction to PEAR), while the rest of us were left somewhat baffled.

What the Public Release really signified was the first stable release of the PEAR Installer and Package Manager (the infrastructure), which make it really easy to fetch packages from PEAR, as we'll see shortly. The Release was also an invitation to all to give PEAR a go.

Another confusing aspect of PEAR raises this question: "If PEAR really is a repository for PHP code, why does it have an installer?" Everyone knows, from Hotscripts, that to install a PHP application, you just unzip and go, right? That's very true; PHP code is generally very easy to deploy. But how often have you run into error messages like this: "Failed opening 'lib/someClass.php' for inclusion", when using third party PHP code (because PHP couldn't find someClass.php in your include_path)? PEAR has a standard approach to providing off-the-shelf PHP components, which uses a fixed include path. What that means, so long as your have PEAR set up correctly, is that including PEAR::Cache_Lite, for example, can always be accomplished with the following:

require_once 'Cache/Lite.php';

What about when you're mixing numerous external libraries into your application? Do all the different coding styles mix well? What do you do when some Open Source project you rely on, starts generating all sorts of error messages, thanks to a PHP upgrade? Is the owner still supporting it? That's not to mention all those other PHP "gotchas", like magic_quotes and register_globals.

There are a lot of experienced PHP developers contributing to PEAR and, with the help of user feedback, bug fixing is relatively quick with issues like magic_quotes ironed out speedily, if they happen at all. There's also a willingness to pick up slack, so if one of PEAR's contributors drops out, the package will usually be handed on to someone else.

There are also signs that, despite being inspired by Perl's CPAN, the PEAR team are aiming at a more integrated library -- something more Java-like. For example, PEAR::DB_DataObject (as you've seen before on SitePoint here) provides a database persistence layer, allowing you to treat tables like objects and, for the most part, forget SQL. DB_DataObject uses PEAR::DB to make the real calls to your database, allowing you to benefit from the functionality it provides, no matter what database engine you're using. Also, the new PEAR Package Proposal System (PEPr) provides a level screening of what code gets into PEAR in the first place. Not quite the Java Community Process, but a step in the right direction.

The question of how PEAR packages are designed leads to a discussion that divides many PHP developers. Search around (perhaps on the SitePoint Forums) and you'll find opinions on PEAR and the packages found within, ranging from "It sucks!" to "It rocks!" -- and covering everything in between. So, why these diverging reactions to PEAR?

PEAR, as a project, is many things to many people. Alongside positive reactions come remarks like "it didn't do what I needed", and "it's bloated", to general questions of Object Oriented application design. To some extent, PHP is a unique language in that there's no such thing as a typical PHP coder. It attracts developers from all backgrounds, from Perl hackers to Java gurus, from Web designers to career programmers. Building something to suit everyone is impossible. You will find gems in PEAR. More often, although a package you've chose wasn't "perfect", it was good enough for the problem you're trying to solve.

There's also the social aspect. The PEAR developer community is changing shape. From a relatively small group of developers who knew each other and were able to coordinate easily, PEAR is now attracting much more input from the PHP community as a whole. While that's a good thing, it also leads to growing pains. The effort required to manage this new input is significant and there are, fortunately, people giving up their free time to do so. On occasion, a poor response to someone's "How do I..." question or an undiplomatic critique of a PEAR package (someone else's hard work) has, in the past, lead to grudges being held.

Finally, there's the issue of documentation, covering both how to use PEAR, and the details of packages stored in it. Simply put, there's not a lot of documentation. And, where detailed instructions do exist, don't be surprised if they're out of date.

That said, having been a little involved with PEAR over the last seven months, I see a project that's getting better and better. The PEAR regulars are very open to newcomers and are willing to listen to constructive feedback. They're even more willing to accept offers of help, whether it be in adding new packages, maintaining existing ones, helping out with (much needed) documentation, or just getting involved in the mailing lists.

Whatever your preconceptions about PEAR, (or even if you've never heard of it), it's a project of great value. The current code base already represents the sum of many thousands of hours' work. More to the point, PEAR represents a chance to evolve PHP itself. From the basic framework (that you download from php.net) plus many other incoherent projects scattered around Sourceforge and the like, PEAR presents the opportunity for a unified and well-supported library of components, re-used by PHP developers world-wide, cutting everyone's development time significantly.

So if there's something you don't like, don't sit on the sidelines. Get involved and reform it. Evolution works better than revolution, after all!