Archive for the ‘PHP’ category

Getting started with Pyrus, the new PEAR compatible package installer

April 30th, 2008

There are quite a few reasons to start playing with the new PEAR package manager – named Pyrus. The first of which is that it is filled with PHP 5 goodness, utilizing many features of the SPL. And secondly, PEAR2 is just around the corner and these are exciting times for PHP development.

Prerequisites:

  • PHP >= 5.3 (I believe you need libxml > 2.6.16, but could use some help verifying this)
  • SQLite Extension, should be included by default (sudo apt-get install php5-sqlite)

The first thing we need to do, is create a temporary directory to checkout the PEAR2 files from the repository:
Note: In case you haven’t heard, PEAR2 source files are in subversion at http://svn.pear.php.net/PEAR2


mkdir ~/PEAR2_SVN
cd ~/PEAR2_SVN/
svn co http://svn.pear.php.net/PEAR2


Great, now you have a copy of the latest files for Pyrus and PEAR2. (r 314 when this was written).
The following packages are the backbone of the new package manager:
PEAR2_Autoload
PEAR2_Exception
PEAR2_Pyrus
PEAR2_HTTP_Request
PEAR2_Developer (if you’d like to build some PEAR2/Pyrus installable packages)
The PEAR2 channel is not available yet, but we can install the individual packages in Pyrus by using their respective package.xml files within the svn checkout.
Before we install the new packages, let’s create a directory to place our Pyrus installation. Previously, users would create a system PEAR install in /usr/share/pear or similar, or a local PEAR install in ~/pear/. And at this point, you would have to make a decision you might have to live with for the rest of the installed packages’ lives. But, don’t worry! With PEAR2 we can move this Pyrus managed installation later if needed.

mkdir ~/pyrus
cd ~/pyrus/

Note: it is important to change the directory to where you wish to install the packages as the current directory will be used as the default install location for pyrus commands.
Now let’s install some packages

php ~/PEAR2_SVN/PEAR2/Pyrus/trunk/pyrus.phar install ~/PEAR2_SVN/PEAR2/Autoload/trunk/package.xml
php ~/PEAR2_SVN/PEAR2/Pyrus/trunk/pyrus.phar install ~/PEAR2_SVN/PEAR2/Exception/trunk/package.xml
php ~/PEAR2_SVN/PEAR2/Pyrus/trunk/pyrus.phar install ~/PEAR2_SVN/PEAR2/HTTP_Request/trunk/package.xml
php ~/PEAR2_SVN/PEAR2/Pyrus/trunk/pyrus.phar install ~/PEAR2_SVN/PEAR2/Pyrus/trunk/package.xml
php ~/PEAR2_SVN/PEAR2/Pyrus/trunk/pyrus.phar install ~/PEAR2_SVN/PEAR2/Pyrus_Developer/package.xml

Now you have Pyrus and all the necessary dependencies installed!
To get started, you can create your PHP files which reference the PEAR2 autoloader by using:

<?php

require
'pyrus/src/PEAR2/Autoload.php';

How to create a PEAR2 package

The easiest way to create a Pyrus installable package is to set up a standard filesystem layout, and auto-generate the package.xml manifest for installation.
The source layout is as follows:
PackageName/src/      [role="php"]
PackageName/examples/ [role="doc"]
PackageName/doc/      [role="doc"]
PackageName/data/     [role="data"]
PackageName/tests/    [role="test"]
PackageName/www/      [role="www"]

In the root of your package directory create the following files:
CREDITS (this file contains the project lead info) example

; maintainers of PackageName

Brett Bieber [saltybeagle] <brett.bieber@gmail.com> (lead)

README (this file contains the summary and description for the package) example
This package is for use with blah


With this package you can do blah, blah, blah blah. My extended
description goes here.
RELEASE-0.1.0 (This file contains the release notes) example
This is the first alpha release.
You can create your PEAR2 installable package by using the Pyrus_Developer package and using a file like this:

makepackage.php
<?php

error_reporting
(E_ALL);

ini_set('display_errors',true);

require
'pyrus/src/PEAR2/Autoload.php';



$a = new PEAR2_Pyrus_Developer_PackageFile_PEAR2SVN(dirname(__FILE__), 'PEAR2_MyNewPackage');






Then run the file to generate the package.xml and install your package:
php makepackage.php

cd ~/pyrus

php ~/PEAR2_SVN/PEAR2/Pyrus/trunk/pyrus.phar install PackageName/package.xml



Hopefully this gives you all a quick understanding of how to get started, and some idea of where things are headed.

Note: The latest copy of this document is available at http://docs.google.com/Doc?id=dgtbrg66_50d5c68d

New PHP User Group – Lincoln, NE

April 7th, 2008

Greetings fellow PHP developers! I just wanted to invite you to a PHP
User Group meetup here in Lincoln (the first, to my knowledge).

This is something I’ve been meaning to do for a long time… and I’ve
finally set a time, a place, and a website. :-)

Thursday, April 10th 2008 7pm-8:30pm CBA 108

Right now the agenda is light, so if you have a topic you’d like to
talk on – by all means let me know and I’ll add it to the agenda.
Hopefully we can get some project demos and discussion on what people
are working on currently.

We have room for around 20 people so invite some friends and forward
this on if you know of anyone interested — especially students you
may have contacts with. I think student participation is key to the
growth and continued life of this user group.

The website is:
http://phpug.unl.edu/

I’ll bring some pop & pretzels…. Hope you can attend if you’re available!

Upgrading Ancient PEAR Versions

January 11th, 2008

If your PEAR installer is acting funky, returning 404’s, remote packages not found etc you may have an ancient version in need of upgrading. As announced almost a year ago, XML RPC would be disabled on Jan 1st, 2008.

Here’s a typical error:

# pear list-upgrades
HTTP error, got response: HTTP/1.1 404 Not Found
Didn't receive 200 OK from remote server. (HTTP/1.1 404 Not Found)

Read this message on the PEAR website for how to fix it.

Unit Tests for HTML Validation

September 29th, 2007

It is now very easy to integrate testing for valid HTML into your web application’s test environment using the W3C’s validator and PHPUnit. I just committed a sample unit test for PHPUnit which will checks your html markup.

The test cases or suites are very easy to integrate into your existing environment with the Services_W3C_HTMLValidator package.

First you’ll need the PEAR package for html validation:
pear install Services_W3C_HTMLValidator-beta

And then you should copy down the two sample PHPUnit files ValidationSuite.php and URIValidationTest.php.

Within the ValidationSuite.php file, modify the array of URLs to check and simply run the tests with php ValidationSuite.php

A validation test will be automatically added for each URI you wish to validate.

– NOTE: If you plan on validating many pages, consider installing a local copy of the W3C validator – which isn’t that complicated and you’ll get faster results.

RoR has a similar plugin for html validation called ResponsibleMarkup, and I think the title is appropriately named.

Happy validating!

iTunes U Authentication Class

September 21st, 2007

Aaron Axelsen’s iTunes U autentication class written in PHP is now installable through UNL’s local PEAR channel.

pear channel-discover pear.unl.edu
pear install unl/UNL_iTunesU-beta

The class is nearly identical except the constructor now accepts an associative array of options to set for the class, and added support for PEAR packages if PHP doesn’t have curl or hash extensions.

Our university is just getting started with iTunes U and authentication is the first step – big thanks to Aaron @ UWW for porting Apple’s perl connection script to PHP.

Why Aren’t You Using APC?

September 20th, 2007

I got a new Mac this week – Quad Core Dual 2.66 Intel, pretty sweet. Anyways, the Apple Migration Assistant can only transfer so much. I had to setup PHP 5, MySQL, as well as quite a few other manual install and custom configuration files. Well, I wasn’t getting the performance I was expecting out of my PHP apps, until I remembered that APC wasn’t installed.

Now I’m not that big of an optimization freak, so my code isn’t that lean and mean, but man APC does some amazing stuff.
Here’s the results of an apachebench [ab] on my localhost -

Without APC (~40 req/s):

ucommbieber:~ bbieber$ ab -k -c 50 -t 300 http://localhost/events/
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Finished 12202 requests
Server Software: Apache/1.3.33
Server Hostname: localhost
Server Port: 80

Document Path: /events/
Document Length: 23809 bytes

Concurrency Level: 50
Time taken for tests: 300.002 seconds
Complete requests: 12202
Failed requests: 952
(Connect: 0, Length: 952, Exceptions: 0)
Broken pipe errors: 0
Non-2xx responses: 2
Keep-Alive requests: 0
Total transferred: 269977940 bytes
HTML transferred: 267940001 bytes
Requests per second: 40.67 [#/sec] (mean)
Time per request: 1229.31 [ms] (mean)
Time per request: 24.59 [ms] (mean, across all concurrent requests)
Transfer rate: 899.92 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 4.0 0 76
Processing: 117 1226 2243.5 1065 33964
Waiting: 117 1226 2243.4 1065 33936
Total: 117 1227 2246.6 1065 33990

Percentage of the requests served within a certain time (ms)
50% 1065
66% 1097
75% 1119
80% 1133
90% 1184
95% 1375
98% 1764
99% 3704
100% 33990 (last request)

With APC (~208 req/s)

ucommbieber:~ bbieber$ ab -k -c 50 -t 300 http://localhost/events/
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Finished 50000 requests
Server Software: Apache/1.3.33
Server Hostname: localhost
Server Port: 80

Document Path: /events/
Document Length: 23809 bytes

Concurrency Level: 50
Time taken for tests: 239.538 seconds
Complete requests: 50000
Failed requests: 0
Broken pipe errors: 0
Keep-Alive requests: 0
Total transferred: 1198823976 bytes
HTML transferred: 1190473809 bytes
Requests per second: 208.74 [#/sec] (mean)
Time per request: 239.54 [ms] (mean)
Time per request: 4.79 [ms] (mean, across all concurrent requests)
Transfer rate: 5004.73 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 2.0 0 101
Processing: 19 239 43.4 234 1489
Waiting: 19 238 43.4 233 1489
Total: 19 239 44.1 234 1489

Percentage of the requests served within a certain time (ms)
50% 234
66% 238
75% 241
80% 244
90% 254
95% 265
98% 294
99% 349
100% 1489 (last request)

And all you’ve gotta do is:
sudo pear install pecl/apc
sudo apachectl graceful

I went from 40 requests per second to 208 requests per second. Wowzers. You should seriously install it.

New Release of Services_W3C_HTMLValidator

July 31st, 2007

I recently released a new version of the PEAR Services_W3C_HTMLValidator package which supports the latest features of the HTML Validator.

With release 0.8.0 the W3C Validator has a shiny new interface and speed improvements to boot. In addition, the web services and SOAP output supports additional features which make the web service just as good as the web interface at http://validator.w3.org/.

The additions to the SOAP output format give developers the ability to re-create the validator’s interface in any template they choose, or just programmatically validate HTML documents.
As a quick example, I’ve built a simple validation interface within the UNL web templates.

Screenshot-UNL | Document Template - Mozilla Firefox

Big thanks to Olivier for all his work, and getting my patches in to production.

Grab the latest release and build your own interface at http://pear.php.net/package/Services_W3C_HTMLValidator/

Commenting Re-enabled / Salty_Services_Akismet

March 26th, 2007

Commenting on the blog has been re-enabled now that I’ve had time to code in Akismet spam checking.

The process was fairly simple, I utilized existing code from Alex Potsides @ http://www.achingbrain.net/, and pearified the code into a package Salty_Services_Akismet which is now a dependency on the saltybeagle.com code.

Hooray for PEAR packages.

I’m gonna check with Alex and see if he’s considering adding his package to PEAR under Services_Akismet… there would only be minor coding standards changes, a look into how he uses the sockets to connect to akismet, and a re-license from GPL. (A bit of work :-) )

I’ll also note that Tobias Schlitt has Akismet trackback checking already built in to Services_Trackback, but as of yet I don’t think there’s an Akismet comment spam checker inside PEAR.

Custom PhpDocumentor Templates

January 30th, 2007

PhpDocumentor is an essential tool all serious PHP developers should know about.
By parsing the phpdoc blocks within the source of your files phpDocumentor can generate API documentation for your entire project/application.

I recently had the need to build a custom output template for the HTML converter, and decided to distribute it using a PEAR installable package so other PHP developers at the University could generate documentation for their code.

The process is fairly straightforward – I copied the frames template and created my own named ‘UNL.’ This template yields .php pages in the UNL Templates so that the API documentation matches the rest of the www.unl.edu website.

Tricks with creating an installable PEAR package were to mark all the files .tpl, .inc, etc as ‘php’ and to use ‘/’ as the baseinstalldir. This will make sure the template files get installed into the correct location.

Other UNL PHP developers can run:

pear install pear.unl.edu/UNL_PhpDocumentor_UNLHTMLTemplate-alpha

And then set phpDocumentor loose on your files like so:

phpdoc -po UNL_DWT -o HTML:UNL:UNL -d UNL_DWT -t /Library/WebServer/pear.unl.edu/docs/UNL_DWT/

which will generate API documentation within the UNL templates and it will look like this.

Simple Guidelines for Proposing a PEAR Package

January 24th, 2007

Recently I went through the proposal process for a PEAR package (Services_W3C_HTMLValidator) and figured I would write down some thoughts.

Simple Guidelines for Proposing a PEAR Package ( and getting it approved ):

1. Lose your ego (if you have one). Your code might be good, but there are plenty of people out there who will find flaws with it. The sooner you realize others can help you, the sooner you can move on to accepting help and improving your code.

2. Choose an appropriate package name. And be sure you understand why the underscores are in package names. Examine what packages are out there, and note their category and naming scheme — the package name should quickly convey the purpose of your package. Also make sure you look to see if your package is already in the repository.

3. Follow the coding standards. PEAR developers will nitpick you to death – it’s best to just correct this ahead of time. The biggest ones are: Use 4 spaces, not tabs! Take a look at PHP_CodeSniffer and run your code through this before you submit any code.

4. Document your code. If you expect anyone else to use your code, you MUST document it. Provide internal documentation using PHPDoc syntax – AND externally using general terms anyone can understand.

5. Provide useful examples. You must have examples which work and are easy to understand – and you MUST have examples which cover the basic functionality your package provides.