The Simple HTML DOM Parser is implemented as a simple PHP class and a few helper functions. It supports CSS selector style screen scraping (such as in jQuery), can handle invalid HTML, and even provides a familiar interface to manipulate a DOM.

Here’s a sample of simplehtmldom in action:

$html = file_get_dom('http://www.google.com/');
 
foreach($html->find('a') as $element)
    echo $element->href;

This snippet is fairly self explanatory - file_get_dom() is a simple helper function in the library that fetches the page and constructs a new simplehtmldom object around it. Once the object is available, we can easily use simple CSS selectors to find our elements - in this case, anchors - and iterate over them just as we would with PHP 5’s standard DOM classes. (The equivalent code with the standard DOM classes is twice as long.)

But the library doesn’t stop there - as well as traversing the DOM and extracting information, you can also alter it. Consider this snippet:

$html = str_get_html('
<div id="hello">Hello</div>
<div id="world">World</div>
 
');
 
$html->find('div', 1)->class = 'bar';
 
$html->find('div[id=hello]', 0)->innertext = 'foo';

The library supports many DOM-style approaches for manipulation, from exposing real attributes as shown here, to a few helper methods. It also includes other methods to traverse the current node - children(), parent(), first_child() and so on.

Real scraping? Easy. Here’s their Slashdot sample:

$html = file_get_html('http://slashdot.org/');
 
foreach($html->find('div.article') as $article) {
    $item['title']     = $article->find('div.title', 0)->plaintext;
    $item['intro']    = $article->find('div.intro', 0)->plaintext;
    $item['details'] = $article->find('div.details', 0)->plaintext;
    $articles[] = $item;
}
 
print_r($articles);

And finally, there’s always a simple save mechanism:

$html->save('altered-dom.html');

Ready to get started? Head over to the project website, online documentation or the project page on SourceForge.

But you don’t have to be a web dev guru to build great applications: with just a few simple tricks, you can make your web based interfaces more usable and more visually appealing. Here are a few simple CSS tricks every PHP / web developer should know.

Here’s a quick preview of how we’re going to transform our page:

1. Styling Form Inputs, Buttons
When you pop an <input> onto your page, it’s at the mercy of the end user’s system for appearance, behaviour - even size. For example, Firefox handles unstyled inputs differently from IE, and both take many cues from the local OS styling; the same goes for Safari. This is okay on modern OSes — if you aren’t concerned with controlling your visuals — but quite a few users still run “Classic” interfaces, and it’s especially annoying for buttons. Here are some basic styles you should consider for your inputs.

input {
	padding:3px;
	border:1px solid #F0F0F0;
}

These will first add a bit of padding to your text boxes and buttons, and set in stone your border color to a soft gray. In particular, most browsers will render a clean rectangular button with this style present. Consider defining a width in pixels or percents (if inside a container) as well.

2. Styling Tables
Remember to style tables nicely, with table row hover colors, reasonable borders and maybe even striped tables. After all, tables can be dull and boring:

There are two key areas to this: using semantic markup, and taking advantage of CSS selectors. Let’s first fix up our table HTML:

<table border="1">
<thead>
<tr>
<td>Heading 1</td>
<td>Heading 2</td>
</tr>
</thead>
<tbody>
<tr>
<td>Value</td>
<td>Value</td>
</tr>
<tr>
<td>Value</td>
<td>Value</td>
</tr>
</tbody>
</table>

And then add some styles:

table {
	border-collapse: collapse;
	border: 1px solid #CCC;
	font-size: 12px;
}
 
table thead td {
	font-weight: bold;
	background: #E1E1E1;
}
 
table tbody tr:hover td {
	background-color: #F3F3F3;
}
 
table td {
	padding: 5px 10px;
}

First, notice the use of border collapse - this prevents the blocky double-borders on cells. Next, we take advantage of our <thead> and <tbody> to apply a background color to our header row, but a hover effect on body rows. The :hover is on the table row, but the actual background needs to be applied to the cell. Finally, we add a neat padding that keeps text in order. A smaller font size on your table will also cut it down to size and fit more figures on a page.

3. Button Links
Often you want a button-style link to execute a simple action or lead the user to another page. Let’s create a simple “Next” link with this markup:

<a href="#" class="button">Next &raquo</a>

We can then style it nicely with this CSS:

a.button {
	background: #AAA;
	color: #FFF;
	padding: 3px 5px;
}
 
a.button:hover {
	background: #888;
}

We first set a simple background color on the anchor to make it stand out, and ensure the text is still visible. However, feedback is important here - by adding a simple hover color, we make it clear that this is an interface element and not some ordinary link.

4. Typography
It isn’t hard to use simple, clean text on your pages, as opposed to the serif-heavy fonts IE and Firefox will default to on Win/Linux. Try adding this to your main stylesheet:

body {
	font-family: Arial;
	font-size: 95%;
}

Arial isn’t terribly fantastic, but it isn’t too bad either. (Verdana is also a standard option.) By explicitly setting a font here, you avoid leaving at the mercy of the browser/OS, especially when you may not have testing machines of a particular OS available (e.g. OS X).

With all these techniques in play, we have a nice and usable interface:

Caching alleviates the latency issue to some extent, but retrieving more than a few files is always going to be a problem, and, well, sometimes users just can’t wait. cURL’s parallel processing allows you to fire off multiple requests at a time and handle responses as they arrive, instead of linear operations - waiting for each request to complete (or worse, time out) before starting the next.

Consider this basic cURL example:

<?php
$ch = curl_init();
 
curl_setopt($ch, CURLOPT_URL, "http://example.com/");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 
$data = curl_exec($ch);
 
curl_close($ch);
?>

This will fetch the initial resource of http://example.com/ and put the data (the HTML) in $data. If we wanted to do this multiple times, we could use a simple for loop around this code block and repeat. However, through this method script execution time increases are linear, proportionate to the latencies of each network request, and latencies of 50-100ms x 10 requests don’t help when you barely spend <10ms executing all your PHP code.

Instead, we’ll use cURL’s parallel processing system. This requires a bit of a context shift - instead of running each operation, you now have to tell cURL all the operations to run, let it do it’s stuff, and then continue on once it has finished. The difference is that it doesn’t wait for each request - it runs them all simultaneously (network permitting). Here’s a basic example:

<?php
// Create two cURL handlers
$ch1 = curl_init(); $ch2 = curl_init();
 
// Set options on both
curl_setopt($ch1, CURLOPT_URL, "http://example.com/");
curl_setopt($ch2, CURLOPT_URL, "http://example2.com/");
curl_setopt($ch1, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch2, CURLOPT_RETURNTRANSFER, 1);
 
$mh = curl_multi_init();
curl_multi_add_handle($mh,$ch1);
curl_multi_add_handle($mh,$ch2);
 
$running=null;
do {
    curl_multi_exec($mh,$running);
} while ($running > 0);
 
$data1 = curl_multi_getcontent($ch1);
$data2 = curl_multi_getcontent($ch2);
 
curl_multi_remove_handle($ch1);
curl_multi_remove_handle($ch2);
curl_multi_close($mh);
?>

Here, we first create a cURL connection object for each request we want to make - an array of these is perfectly acceptable - and set the options on each. Instead of curl_init(), we then call curl_multi_init() and point the library at each of our connection objects. We have to cede control from cURL at this point: curl_multi_exec() now runs all the sub-connections of the current cURL object - that is, $ch1 and $ch2.

The curl_multi_exec() function takes a second parameter, a reference to a flag of whether operations are still running. When that parameter - for us, $running - is 0, cURL’s finished taking care of requests and we can proceed. Timeouts are the only concern - remember to set the timeout option to a reasonable value to avoid being held up by requests that won’t complete.

As you increase in requests, however, remember that the next bottleneck you will hit is memory. Given PHP’s memory_limit flag (especially on shared servers), you can actually hit this quicker than you think. cURL can’t read part of a file or stream, even if it’s packet-based. Ever seen fread($handle, 8192)? The second parameter results in 8KB chunks, avoiding memory limits elegantly. cURL, however, will simply collect up all your request responses: if you hit your memory limit, you either get a fatal error or a “white screen of death”. Consider parallel cURL-ing in a background process. Also, these simple routines can get quite lengthy - consider building an abstraction layer for your app/framework, to maintain an array of cURL connection objects and interface requests.

Parallel HTTP requests in cURL are quick and easy, despite the architectural differences with libraries for single-threaded cURL. To learn more, just check out the detailed documentation on the PHP manual page.

FirePHP is implemented as a native Firefox extension, and is available from Mozilla Addons. After a basic setup procedure, you can start printing everything from status messages to multi-dimensional arrays straight to your Firebug console. FirePHP achieves this using extension HTTP headers - in particular, X-FirePHP-Data headers in the response.

The PHP library provides a function, fb(), which handles sending data across to the client side. From here, you simply open up your Firebug console, and your data is displayed in a highly functional manner.

To get started with FirePHP, grab the extension from Mozilla Addons and the core library from the FirePHP project page (the “Download” link). You’ll need to install Firebug first, then the FirePHP Firefox addon. Next we get to the PHP library - either add the “FirePHPCore” folder to somewhere in your include_path, or just pop it into your script directory, and include it:

require('FirePHPCore/fb.php');

Remember to change the relative path as required (no pun intended). Then, simply call the fb() function anywhere in your code, passing a single argument - the info you want to send to your FirePHP console. Here are some examples:

fb('The value of $var is '.$var);
fb('Just logging this event.',FirePHP::LOG);
fb('Error in the email module.',FirePHP::ERROR);
fb($_SERVER, '$_SERVER array', FirePHP::LOG);
 
try {
  throw new Exception('Exception');
} catch(Exception $e) {
  fb($e);
}

As you can see, we can output basic messages, use Firebug’s standard styles to identify message importance (also, INFO and WARN), output labelled assocative arrays, and even debug exceptions - FirePHP will display a neat little stack trace.

Remember that this information is sent via headers, so it needs to be output before any of your HTML. If you’re using a framework with view templates, this is probably not an issue, but otherwise, you can get around the problem by using output buffering. Just run this line somewhere near the beginning of your script execution:

ob_start();

This will initialise output buffering, so that any HTML you output is held up till the end of script execution (or till the next call to ob_flush() and derivatives). Calling the fb() function will then work fine any time before the end of your script, as the headers will be flushed immediately. (Alternatively you can use php_flag output_buffering on in your .htaccess / apache virtual host configuration.)

FirePHP has all sorts of neat tips and tricks - just check out the quick start guide and protocol reference. If you use the Zend Framework, have a look at the Zend library for FirePHP; similar libraries exist for Symfony and Prado as well.

When we want some kind of background process running our PHP code, we have a simple challenge: we can’t leave it up to the client. On the web, people hit their stop button, their browsers lock up and they force quit, they even have the odd power outage. When we want to do complex processing on the server side, we need to detach from the client-server model of a web-served script. PHP can fork a script, but the parent script is still facing an unreliable client.

Our best option, then, is to launch a background process from the command line. There are three steps to this: starting the background script, passing it information to do its job, and checking when it’s finished.

Starting the background script
On UNIX systems, we can easily call another PHP script via the shell, set it to run off in the background and send its output to /dev/null. Here’s a sample:

exec ("/usr/bin/php proc.php >/dev/null &");

Here, we call the exec function; instructing it to run our local PHP binary - usually at /usr/bin/php or /usr/local/bin/php, check with your host/sysadmin. We pass it a single argument: the filename of the PHP script that handles our background process. We then send the output to /dev/null, effectively destroying it. The last character, the & symbol, is important - this tells the system to start this process in the background and to let us continue.

Talking to the background process
It’s all very well to start a background process, but now it needs to know what to do. We handle this through command line arguments. Let’s update the previous example:

exec ("/usr/bin/php proc.php --task=50 >/dev/null &");

Our proc.php file might look like this:

<?php
echo "Handling process ".$argv[1];

Running “php proc.php –task=50″ on command line produces the following output:

Handling process --task=50

From here, you can easily design your script to do what it needs to.

Monitoring the background process
There’s just one last detail: how do we monitor the progress of our background process? It’s best to use an independent datastore that can be relied upon, instead of communicating with running threads - your application’s MySQL database would be perfect. You can create a “sessions” or “jobs” table with an ID column, a status column (started, in progress, finished - 0, 1, 2), and any other information you need. Before you start your background process, create a new entry in this table and check the insert ID, then pass it to the background process when you start it:

exec ("/usr/bin/php proc.php --some_info=50 --job=1234 >/dev/null &");

Your proc.php file can then update the table row with the ID you supply it, and your front end applications can provide status updates to end users by checking up on all pending jobs for the current user - relatively straightforward business logic.

If you’re going to be running many background processes, a job queue and an “always-on” script running on your server may also be an option. In this case, consider looking into pcntl_fork() and the program execution functions.

SimpleTest is a PHP unit testing and web testing framework along the lines of JUnit and JWebUnit. It provides a comprehensive set of APIs for testing everything from your class methods to your SSL-secured authentication pages.

Unit testing in PHP generally validates that individual sections of your source code are functioning as expected. As your project grows, it’s hard to remember what each and every module is responsible for, especially with multiple developers. Unit tests help check that a function or method does what it’s meant to, and when run during a build process or around version control commits, can check that recent changes haven’t broken expected functionality.

Let’s look at a simple SimpleTest example:

<?php
define('SIMPLE_TEST', 'simpletest/');
 
require_once(SIMPLE_TEST . 'autorun.php');
require_once('arithmetic_class.php');
 
class TestOfArithmetic extends UnitTestCase {
    function TestOfArithmetic() {
        $this->UnitTestCase('Test of Arithmetic');
    }
 
    function testAddition() {
        $arithmetic = new Arithmetic();
        $result = $arithmetic->add(1,1);
        $this->assertEqual($result, 2);
    }
}
?>

SimpleTest provides PHP classes that serve as the ground work for unit testing. When we define a new unit test case - in this case, “TestOfArithmetic”, SimpleTest automatically works out what tests you’ve defined in order to run them. We then simple create new methods for our tests, run whatever logic we need, and use assert calls to check that we have achieved our expected outcome. In this case, we want to assert that the return value of Arithmetic::add(1, 1) equals 2.

This may seem rather lengthy for a single test, but additional tests can be added on in as little as a single line of code, and an entire application can be quickly checked for reliability with just a few hundred lines of unit tests. Once this is in place, we can run our unit tests by loading up this script in our browser, and if everything is in order, we see a nice and concise status page displaying the results of the tests.

Of course, why write tests after you write your application code, when you could write it sooner and sooner, and maybe even before? That’s the approach of test driven development (TDD) - SimpleTest is perfectly happy with writing tests for code that doesn’t exist yet. TDD, from one of the guys who created Extreme Programming (XP), basically involves writing tests to define the design of code, and then working away at the code till it passes the tests, and SimpleTest is a great way to achieve it in PHP.

SimpleTest is hosted on SourceForge, so head over and try it out. They’ve also got a great tutorial on their main project site.

ORM brings data closer to a programming paradigm, where actual information is stored and accessed through interfaces that resemble actual objects. In PHP frameworks, this is typically achieved through the framework providing classes representing database information, that can then be manipulated as actual objects such as a car or a booking. This is almost always a level above actual database operations - when using an ORM layer, writing actual SQL queries is taken care of, although an understanding of how to is always helpful.

Let’s consider a simple database, consisting of users and posts. ORM defines relationships between objects (and in general, also between tables) where an object either has one or has many of another object. For example, a post might have one author, while an author would have many posts. By adding foreign keys to the actual database, and defining these simple relationships (usually hard-coded), an ORM layer can take care of working with related data.

CakePHP’s ORM layer is possibly one of the most used ORM layers of any PHP framework, and is a good example of how a simple ORM implementation should function. In Cake, when an author model is defined as having many posts, any calls to fetch a particular author will automatically fetch all posts related to that author. The entire database logic is taken care of, and instead of thinking in terms of SQL queries, we get to think in terms of actual objects.

Symfony also has quite a nice ORM layer, although the symfony implementation is a little more hands-off, based around database design conventions and it’s YAML schema file approach. But you don’t need to be using a PHP framework to take advantage of ORM; the Doctrine project provides a powerful ORM layer that can be implemented on its own or within an MVC framework. Doctrine also provides an object-oriented SQL-like language to write database queries - the Doctrine Query Language is is great for complex object retrieval. Propel is another popular option, and is actually the ORM layer behind Symfony.

At the end of the day, ORM provides a fundamental advantage over writing raw SQL queries: it’s designed to retrieve information, not record sets. While thinking about data in terms of objects is a major paradigm shift from hands-on PHP scripting, it’s a great way to deal with the challenge of complex databases. So what are you waiting for? Grab a framework or a library, and dive in to the world of ORM.

If you have an Apache installation locally, you’ve probably got ab already. Check your path - just run `ab`. Otherwise, head to your apache/bin folder. If you’re running Windows and don’t have Apache, grab a copy of XAMPP Lite from the project page.

The ab executable is independent of Apache, and doesn’t actually care if it’s testing an Apache installation - ab will load test Apache web servers, LigHTTPD servers, anything that speaks HTTP. Still, ab will give the most accurate results when run without latency on a local server, and you probably don’t want to load-test on a production server. Given this, it’s best to setup Apache and your application locally as a staging server, then load test it with ab.

Work out the path to your ab executable - for example, mine’s D:\dev\apache\bin\ab.exe - and open up a command line window to run it.

D:\dev\apache\bin\>ab
ab: wrong number of arguments
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
    -n requests     Number of requests to perform
    -c concurrency  Number of multiple requests to make
    -t timelimit    Seconds to max. wait for responses
    -p postfile     File containing data to POST
    -T content-type Content-type header for POSTing
    -v verbosity    How much troubleshooting info to print
    -w              Print out results in HTML tables
    -i              Use HEAD instead of GET
    -x attributes   String to insert as table attributes
    -y attributes   String to insert as tr attributes
    -z attributes   String to insert as td or th attributes
    -C attribute    Add cookie, eg. 'Apache=1234. (repeatable)
    -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
                    Inserted after all normal header lines. (repeatable)
    -A attribute    Add Basic WWW Authentication, the attributes
                    are a colon separated username and password.
    -P attribute    Add Basic Proxy Authentication, the attributes
                    are a colon separated username and password.
    -X proxy:port   Proxyserver and port number to use
    -V              Print version number and exit
    -k              Use HTTP KeepAlive feature
    -d              Do not show percentiles served table.
    -S              Do not show confidence estimators and warnings.
    -g filename     Output collected data to gnuplot format file.
    -e filename     Output CSV file with percentages served
    -h              Display usage information (this message)
    -Z ciphersuite  Specify SSL/TLS cipher suite (See openssl ciphers)
    -f protocol     Specify SSL/TLS protocol (SSL2, SSL3, TLS1, or ALL)

Calling ab without arguments will display this list of options. We are primarily interested in -n and -c. The -n switch represents the number of requests to perform - a figure in the low thousands is generally appropriate for a web application. The -c switch represents concurrency, or how many requests to make at the same time. This value can vary depending on what you expect for your application.

Work out a URL to an average page of your web application. For example, I’m load testing a local CakePHP application, so my URL is http://cake.local/users/list. Call ab as follows:

ab -n 1000 -c 10 http://cake.local/users/list

If you need to use a proxy (e.g. for testing remote servers), use the -X switch, in the format -X proxyhost:proxyport e.g. -X proxy.local:3128.

After displaying some status reports every 100 requests or so, it will print out a fairly detailed report, including document length, bytes transferred, completed and failed requests, requests per second and some statistics on connection times.

For further information, check out the documentation page for ab.

After running the tests on a production grade box, he recorded these basic results, without any caching in place.

Some basic indications are obvious - frameworks create massive overheads, with hefty overall performance costs. Per these results, using CakePHP over a static HTML site was 226 times slower. CodeIgniter fared the best, at about 40 times slower, while the Zend Framework was somewhere in between.

While the actual numbers may be surprising, how each framework fared in relation to the others is not.

All of these frameworks provide levels of abstraction, taking care of many common tasks and moving the logic away from the developer’s application. Each framework offers a varying level of this “hand holding”, and it’s generally accepted that CakePHP leads the race in this area. By making more assumptions and relying on more default behaviours, Cake will always have a far greater overhead.

CodeIgniter, on the other hand, is far more efficient in what it does - but doesn’t do as much. An application built on CodeIgniter will always be more efficient than one built in Cake, but development time will be considerably longer.

Another interesting area to note was ORM - Cake’s inbuilt ORM layer couldn’t be reasonably “disabled” to run benchmarks without the added overhead, and so the benchmark of frameworks without their ORM layer excluded Cake entirely. Ekerete also notes that CodeIgniter doesn’t have much of an ORM implementation, possibly leading to its vastly increased performance over the other frameworks.

However, the final point to consider was caching. The performance (measured in requests per second) of CodeIgniter and Zend Framework increased by about 4x when the eAccelerator cache was used. On the other hand, Cake’s requests per second figure barely doubled, suggesting that Cake’s architecture imposes some limitations on the performance gains achievable through caching. With eAccelerator, CodeIgniter was serving over ten times as many requests per second than Cake.

In the end, the choice is really up to the developer. If your applications tend to grow in complexity very quickly, your choice of framework (or language, for that matter) will be increasingly irrelevant. On the other hand, if you’re building small applications, CakePHP will clearly save you time in development, CodeIgniter will offer massive performance benefits, and Zend will give you a reasonable middle ground.

Check out the post on AVNet Labs for more details.

Phing uses XML files to define automated build processes. Each buildfile includes some basic information about the project, and then a series of tasks. XML tags represent each task - for example, an <copy file=”…” tofile=”…”> is used for a file copy operation. Here’s a sample extract from one of these buildfiles:

<?xml version="1.0"?>
<project name="FooBar" default="dist" basedir=".">
    <target name="prepare">
        <echo msg="Making directory ./build" />
        <mkdir dir="./build" />
    </target>
    <target name="build" depends="prepare">
        <echo msg="Copying files to build directory..." />
        <copy file="./about.php" tofile="./build/about.php" />
    </target>
</project>

Phing comes with quite a few tasks built in out of the box, such as file operations, PHPUnit and Subversion tasks, compression tasks and even a ZendCodeAnalyzer operation to analyse source files with the Zend Code Analysis tool. Phing is also extendible with PHP classes, and has access to the command line, giving it virtually limitless possibilities in what can be done during a build process.

Build systems like Phing are well suited to larger projects, where continuous integration is important. With Phing, your application can be prepared and built overnight, ready to test in the morning and saving hours of hacking around with deployment or one-liner install scripts. Some systems, Apache Ant especially, even integrate with IDEs - for example, some scripts can be run from within Zend Studio for Eclipse at the click of a button.

Getting started with Phing is easy; the project has a PEAR channel for quick and easy download, as well as thorough documentation covering every area of the system. PHPUnit, XDebug and PhpDocumentor can also be installed for added functionality, such as the inbuilt unit testing system. If you’re working on a sizable project and could use some decent automated build tools, head over to the Phing website for more details.