In this tutorial we’ll build a page that gathers up the RSS feeds of all those little bits of your life and presents them all together in one spot. To do that, we’ll use SimplePie, a feed parsing class written in PHP. It’s powerful, it’s open source, and it’s easy to use. We’ll then hack on the output a little, and make it all look gorgeous with HTML and CSS. The techniques we’ll cover are also useful if you find that you need to aggregate RSS from many sources, like a news page. Let’s begin!

What You’ll Need

• The SimplePie library.
• A web server that’s capable of running it — there’s a compatibility test in the SimplePie package that will tell you whether your server is good to go.
• If you tweet, grab this function by Alison Gianotto to help auto-link those tweets
• Of course, you’ll need your trusty text editor!
• For brevity, some of the code is excluded from this tutorial. If you want to see the full picture, view the completed example or download it.

Let’s Begin

First, of course, we’ll need to identify the feeds we want to include on the page. Like I said, I have profiles in lots of places, but for now I’ll keep it short and sweet — I’ll grab my blog, Twitter, Flickr photos, and favorited tracks from Last.fm.

You’ll need to gather up the URLs for the feeds you want, and stash them someplace safe. To do that, look for RSS icons on the page or in your browser’s address bar. Paste those URLs in a text file for later reference.

Next, we’ll need to check that SimplePie is compatible with our hosting environment. There’s plenty of stuff in this download — for now, we can just upload the compatibility_test directory in a web-accessible location on the server, and take a look at it in a web browser. Hopefully, there’ll be a series of messages informing you that a number of dependencies are enabled. If so, it’s time to upload the rest of the library. (If you have a folder in your download called test, it’s safe to exclude that one.)

While you’re poking around in your web server, now’s a good time to set up a directory for SimplePie to use as a cache. You should make this directory writable. I’ve chosen cache.

Make a note of where you uploaded SimplePie, and your cache directory. In my case, both are in the same directory as where I plan to put my lifestream page.

Prepare Your Feeds

Let’s grab those feeds! Open up a new text editor and begin a new PHP file, which we’ll call lifestream.php. This will be the page that eventually shows our lifestream.

First, let’s include a very important component — the SimplePie library itself:

<?php
  require_once('./simplepie/simplepie.inc');

Now, we need to define a couple of important variables: the first is to define the cache location, and the second is to specify the amount of time (in seconds) we want to cache the feeds. Hitting feeds repeatedly is rude, and some feed providers will bar you for excessive feed requests. Also, if you have a busy site, it’s sensible to keep your resource consumption low. I’ve chosen thirty minutes, or 1800 seconds, which is a nice tradeoff between freshness and politeness. Here are those variables:

$cache = "./cache";
$duration = 1800;

Next, time to create some SimplePie objects. The easiest way to turn a feed into a SimplePie object is to call it in its short form: pass it a feed URL, the location of your cache directory, and the cache duration. All my objects look roughly like this:

$object = new SimplePie(
 "http://example.com/feed.xml",
  $cache, $duration);

You’ll see I’m passing those $cache and $duration variables in to save repeating myself. Create objects for each of your feeds — mine are called $blog, $twitter, $flickr, and $lastfm.

At this stage, since I’m going to be including tweets, I’m going to paste in Alison Gianotto’s twitterify function. This function simply accepts some text and looks for items that would be clickable in Twitter — references to usernames with @, tags with #, and regular URLs — and wraps them in nice hyperlinks. The function inserts hyperlinks with a target attribute; I’ve removed those from my example.

Create a Shell

It’s markup time! Create a HTML shell immediately below the closing ?> of your PHP script. In this example, I’ve just shown the contents of the body element for brevity, though of course I’d include a !DOCTYPE, head, and other necessities:

<h1>My awesome lifestream</h1>

<div id="blog">
  <h2>My blog</h2>
  <ul>

  </ul>
</div>
<div id="twitter">
  <h2>My tweets</h2>
  <ul>

  </ul>
</div>
<div id="flickr">
  <h2>My pictures</h2>
  <ul>

  </ul>
</div>
<div id="lastfm">
  <h2>My tunes</h2>
  <ul>

  </ul>
</div>

Reveal the Items

Now that we have a shell of a document, it’s time to start adding some more PHP to this page to loop through each of the items and echo the relevant parts of each item — titles, descriptions, enclosures, links, and more — and wrap the appropriate markup around them. To find out what’s available, examine the source of your feeds, and take a look at the SimplePie documentation, specifically the stuff that begins with get_. You’ll find a list here.

Thinking of my own four feeds, each set of items should be slightly different. With my blog posts, I’ll want to include a title, description, date, and hyperlink. In the Twitter RSS feed, the title and description are identical, so I’ll just use the title. For the Flickr items, I just want to show the picture. The tracks on Last.fm just need a title, link, and date. So, I’ll need to create four separate loops.

Here’s the loop to spit out my blog items, which I’ve placed inside the unordered list inside div#blog. This one’s fairly straightforward:

<?php foreach ($blog->get_items()
  as $item) : ?>
<li>
  <h3>
    <a href="<?php
      echo $item->get_link(); ?>">
      <?php echo $item->get_title(); ?>
    </a>
  </h3>
  <p>
    <?php echo $item->get_description(); ?>
  </p>
  <p class="date">
    <a href="<?php
      echo $item->get_link(); ?>">
      <?php echo $item->get_date(); ?>
    </a>
  </p>
</li>
<?php endforeach; ?>

This loop should generate a series of list-items like this, for each blog entry in my feed:

<li>
  <h3>
    <a href="http://example.com/blogentry/">
      Title
    </a>
  </h3>
  <p>Blog entry description text</p>
  <p class="date">
    <a href="http://example.com/blogentry/">
      01 January 2010, 12:00 am
    </a>
  </p>
</li>

Too easy!

When examining my Twitter feed, I’ve noticed that each tweet is prefixed with my name, a colon, and a space. In this instance, I’ll want to remove that text. I’d also like to convert those hashtags, username references and URLs into clickable hyperlinks. In this loop, when I echo the title of the feed item, I’ll wrap $item->get_title() in a str_replace statement, and then wrap that in the twitterify function:

<?php foreach ($twitter->get_items()
  as $item) : ?>
<li>
  <p>
    <?php echo twitterify(
      str_replace(
        "raena: ", "", $item->get_title()
      )
    ); ?>
  </p>
  <p class="date">
    <a href="<?php
        echo $item->get_link(); ?>">
      <?php echo $item->get_date(); ?>
    </a>
  </p>
</li>
<?php endforeach; ?>

Flickr feeds’ descriptions are less than ideal for my purposes: they include the text “username posted a photo”, the medium sized image surrounded by a link to the photo page, and the Flickr photo’s description. However, I’d just like to present the littlest version of the image and hyperlink, and use the title of the image as the alt text. Fortunately, Flickr provides the URL to the image in the form of an enclosure, so I’ll use that instead.

Flickr’s enclosures are still medium-sized, but I want the cute, square thumbnail. That’s as simple as replacing any reference to _m.jpg with _s.jpg.

<?php foreach ($flickr->get_items()
  as $item) : ?>
  <li class="item">
    <a href="<?php echo $item->get_link(); ?>">
    <?php foreach ($item->get_enclosures()
      as $enclosure) : ?>
      <img src="<?php echo str_replace(
        "_m.jpg","_s.jpg",
          $enclosure->get_link()
      ); ?>"
        alt="<?php
          echo $item->get_title(); ?>" />
      <?php endforeach; ?>
    </a>
  </li>
<?php endforeach; ?>

Finally, I only need the titles and dates from my list of loved tracks from Last.fm:

<?php foreach ($lastfm->get_items()
  as $item) : ?>
  <li class="item">
  <p>
    <a href="<?php
      echo $item->get_link(); ?>">
      <?php echo $item->get_title(); ?>
    </a>
  </p>
  <p class="date">
    <?php echo $item->get_date(); ?>
  </p>
   </li>
 <?php endforeach; ?>

You’ll find my completed example as lifestream.phps in the code download, or again, view it in full here. If you plan to use it as a basis for your own work, remember to change the placeholder feed URLs to your own!

When you’re done fine-tuning your items, it’s time to upload it to the web server, and view it in your browser. If all went well, you should see a series of unordered lists, each containing different goodies from those RSS feeds.

All that’s left now is to style the page and add any other interesting goodies you feel are necessary. In the example, you’ll find an extremely simple set of styles: feel free to use them as a basis for your own.

There’s More…

Of course, there’s plenty more to SimplePie than the very easy example we’ve looked at today. Dive into the wiki and see what’s possible — there’s heaps of support for enclosure display, the ability to merge multiple feeds into one giant stream, and easy ways to add social media sharing buttons to items. You’ll find some great examples of SimplePie-powered sites on the wiki. Enjoy!

First, a little background: at the time of our first Twitaway in 2008, Twitter HQ had been kind enough to relax the limit it places on the maximum number of Twitter direct messages (DMs) that it would allow us to send in a single day. To distribute the free PDFs, then, we simply wrote a PHP script that would look through our Twitter followers every few minutes, identify the new ones and send them a DM with the download link.

This time around, when we sat down to plan Twitaway 2009, it was clear our job would be more difficult. Much less cooperative than they had been previously, Twitter HQ stonewalled our requests to relax the daily DM limit—they wouldn’t even tell us what our daily limit was. For awhile there, we weren’t sure how we would be able to deliver a download link privately to our Twitter followers.

The solution finally came from Mal, a new developer on the team here at SitePoint HQ. We would use Twitter’s new OAuth support to request temporary access to your Twitter account, use it to verify that you were indeed following us, and then simply display the PDF download link in your browser. No DM required!

Of course, writing a PHP application that supported this OAuth-based workflow was a lot more complicated than writing a static web page with a “follow us on Twitter” link. Not only would it be harder to write, but it would be harder to handle large amounts of traffic hitting it, too.

So there we were: just past midnight on launch day of the Twitaway, and the application had stopped responding. Our monitoring systems made it clear that, while our PHP servers were weathering the storm nicely, the MySQL database server had spiked to 100% CPU usage, stuck its fingers in its ears and begun rocking back and forth, chanting “na-na-na-na-na-I’m-not-listening!”

As it turned out, this was an important lesson for our development team about the importance of choosing appropriate MySQL table types. Read on for how we solved the problem, and why we should have predicted it.

Choosing The Right Table Type

When we logged into the swamped MySQL server, we could see (using the SHOW PROCESSLIST command) that the overwhelming majority of the queries that it was receiving were for the database table we had set up to contain PHP session data.

By default, PHP stores your users’ session variables in files on the web server’s hard drive. In our case, however, we had multiple web servers that all needed to share the same session data, so we had configured PHP to store its sessions on the MySQL database server instead.

Unfortunately, we had failed to specify a table type when creating the session table in the database:

CREATE TABLE sessions (
  sesskey VARCHAR(32) NOT NULL DEFAULT '' PRIMARY KEY,
  expiry INT(11),
  expireref VARCHAR(64),
  sessdata LONGTEXT
);

MySQL supports a number of different storage engines. When you create a table, by default MySQL will use the MyISAM storage engine to create a MyISAM table. MyISAM is a relatively simple table type, which forgoes several advanced features in order to offer improved performance. In the early days of MySQL, the MyISAM table type was instrumental in making it one of the best performing databases around.

These characteristics would seem to make MyISAM a natural choice for something like a session data table. Unfortunately, MyISAM has an achilles heel: table-level locking. In order to write a change to a MyISAM table, MySQL must lock the whole table, preventing any other query from reading the table until the change is complete.

As thousands upon thousands of SitePoint readers flocked to our Twitaway site to claim their book, multiple PHP processes competed to create, update, and read session data in this single table. And because of MyISAM’s table-level locking, they had to do so one at a time, waiting their turn on an increasingly backed-up database server.

On the surface, the InnoDB storage engine would seem to be a poor choice for improving database performance. It supports a bunch of features that MyISAM doesn’t, including transactions and enforced referential integrity, and all the literature will tell you that writing data to an InnoDB table is slower than with a MyISAM table.

But where MyISAM has an achilles heel, InnoDB has a secret weapon: row-level locking. When writing data to an InnoDB table, only the affected rows are locked, not the whole table. Queries accessing other parts of the same table can happen simultaneously. In a situation like session data, where each browser request being processed is likely to relate to a different session, row-level locking is just what the doctor ordered!

With this in mind, you can probably guess how we cured our swamped database server. We simply converted the session table to an InnoDB table:

ALTER TABLE sessions ENGINE = InnoDB;

Instantly, the CPU load on the database server dropped to more reasonable levels, the Twitaway site came back online, and there was much rejoicing. We could have saved ourselves a lot of grief simply by specifying the table type when we first created the table:

CREATE TABLE sessions (
  sesskey VARCHAR(32) NOT NULL DEFAULT '' PRIMARY KEY,
  expiry INT(11),
  expireref VARCHAR(64),
  sessdata LONGTEXT
) ENGINE = InnoDB;

Switching to InnoDB got us through that first night, but by the next morning we were wondering if there might be an even better table type for us to use. After a little research, the Memory storage engine looked like a likely candidate.

If MyISAM sacrifices features for performance, the Memory table type takes this to extremes. Memory tables are never written to disk, so if you restart your database server, the data stored in any Memory tables is lost. The fact that Memory tables require no disk access, however, makes them blazing fast! Since session data is intended to be volatile anyway, we didn’t really mind if this particular table wouldn’t survive a server restart.

According to the documentation, Memory tables have the same table-level locking weakness as MyISAM. Nevertheless, when we switched our session table to the Memory storage engine, our database server’s CPU usage dropped to virtually zero!

Memory tables have some harsh restrictions that mean they aren’t a cure-all for performance issues. Disappearing data aside, Memory tables cannot contain large column types like TEXT or BLOB. Indeed, the largest piece of data you can store in a Memory table row is a 255 character CHAR or VARCHAR. In our case, we actually had to shorten a couple of our session variable names to make sure they would fit!

At this point, our session table is gliding along happily under moderate load. As the traffic from this article and some other promotion we have planned hits the server, we will be watching closely to decide if the Memory storage engine is up to the task, or if we should switch back to InnoDB to take advantage of row-level locking. In either case, we learned an important lesson: when performance counts, take the time to think about you choice of MySQL storage engine. In our case, it took us from a swamped database server to one showing zero CPU usage.

My recent tutorials received a number of comments complaining about namespace implementation in PHP. The main issues were the syntax and the backslash character. Before I tackle those issues, let’s take a quick look back at the history of PHP.

PHP is a Mess

Languages such as C# and Java were designed and follow rigorous syntax standards. PHP has evolved. The original version was released in 1995 and, by version 3, it was a popular procedural programming language. Version 4 introduced rudimentary object orientation and version 5 provides a reasonably standard OOP model. Namespaces have now been added to version 5.3.

PHP critics will argue that the language is a mess. Function names are inconsistent (e.g. strpos, str_split, substr), object handling has been tagged on, and some of the syntax is different — if not bizarre — when compared with other languages.

However, PHP remains the most widely-used server-side development language. Its versatility is one of its primary strengths:

• Novice developers can start with simple procedural programming. They need never touch OOP techniques and can still be productive.
• Code written 10 years ago in PHP 3 still works today in PHP 5.3. A few minor tweaks may be required, but major rewrites are rarely necessary.

PHP code may not always be pretty, logical, or elegant, but development is rapid and often easier to comprehend than the alternatives.

PHP Namespace Implementation

Unlike C# and Java, PHP has to retain compatibility with non-namespaced code. That has been achieved and you can choose whether to use namespaces or not. However, if you’re using PHP 5.3 (or above), I would recommend them — even if you simply use the same name throughout the whole of your project.

The choice of namespace and use as namespace operators seems logical. Some developers may disagree, but that would have been the case no matter what they’d been named.

Finally, we come to the backslash character. Most critics complain that it’s ugly, difficult to read, and awkward to type on a Mac. However, I still consider it preferable to the double-colon that was originally proposed. Examine the following static method call:

// PHP 5.3 beta static method call
echo ::App::Lib1::MyClass::WhoAmI();

// PHP 5.3 final static method call
echo \App\Lib1\MyClass::WhoAmI();

The second line is quicker to type, less error-prone, easier to read, and simpler to understand. If you see a backslash outside of a string, you know namespacing must be involved.

Of course, it would be great if PHP used a ‘.’ period for public methods, static methods, and namespaces. That would make it consistent with Java, C#, JavaScript, Python and many other languages. Unfortunately, PHP’s history and backwards compatibility makes that difficult to achieve.

No language is perfect, and PHP is far from it! However, namespacing has been implemented well, especially when you consider the restrictions and problems it could have caused. I’m sure you’ll learn to love that backslash!

Related reading:

• How to Use PHP Namespaces, Part 1: The Basics
• How to Use PHP Namespaces, Part 2: Importing, Aliases, and Name Resolution
• How to Use PHP Namespaces, Part 3: Keywords and Autoloading

The __NAMESPACE__ Constant

__NAMESPACE__ is a PHP string that always returns the current namespace name. In the global space it will be an empty string.

<?php
namespace App\Lib1;
echo __NAMESPACE__; // outputs: App\Lib1
?>

The value has obvious benefits during debugging. It can also be used to dynamically generate a fully-qualified class name, e.g.

<?php
namespace App\Lib1;

class MyClass {
	public function WhoAmI() {
		return __METHOD__;
	}
}

$c = __NAMESPACE__ . '\\MyClass';
$m = new $c;
echo $m->WhoAmI(); // outputs: App\Lib1\MyClass::WhoAmI
?>

The namespace Keyword

The namespace keyword can be used to explicitly reference an item within the current namespace or a sub-namespace. It is the namespace equivalent of self within classes:

<?php
namespace App\Lib1;

class MyClass {
	public function WhoAmI() {
		return __METHOD__;
	}
}

$m = new namespace\MyClass;
echo $m->WhoAmI(); // outputs: App\Lib1\MyClass::WhoAmI
?>

Autoloading Namespaced Classes

One of the best time-saving features of PHP 5 is autoloading. In global (non-namespaced) PHP code, a standard autoload function could be written:

<?php
$obj1 = new MyClass1(); // classes/MyClass1.php is auto-loaded
$obj2 = new MyClass2(); // classes/MyClass2.php is auto-loaded

// autoload function
function __autoload($class_name) {
	require_once("classes/$class_name.php");
}
?>

In PHP 5.3, you can create an instance of a namespaced class. In that situation, the fully-qualified namespace and class name is passed to the __autoload function, e.g. the value of $class_name could be “App\Lib1\MyClass”. You could continue to place all your PHP class files in the same folder and strip the namespace from the string, however, that could result in file name clashes.

Alternatively, your class file hierarchy could be organized in the same way as your namespace structure. For example, a MyClass.php file could be created in the folder /classes/App/Lib1:

/classes/App/Lib1/MyClass.php:

<?php
namespace App\Lib1;

class MyClass {
	public function WhoAmI() {
		return __METHOD__;
	}
}
?>

A file in root folder could then use the following code:

myapp.php:

<?php
use App\Lib1\MyClass as MC;

$obj = new MC();
echo $obj->WhoAmI();

// autoload function
function __autoload($class) {

	// convert namespace to full file path
	$class = 'classes/' . str_replace('\\', '/', $class) . '.php';
	require_once($class);

}
?>

Explanation:

1. The class App\Lib1\MyClass is aliased as MC.
2. new MC() is translated to new App\Lib1\MyClass() during compilation.
3. The string “App\Lib1\MyClass” is passed to the __autoload function. This replaces all namespace backslashes with file path forward slashes, and modifies the string so the file “classes\App\Lib1\MyClass.php” is loaded.

I hope you found this series of PHP namespace articles useful. Will you be namespacing in your PHP code?

See also:

• How to Use PHP Namespaces, Part 1: The Basics
• How to Use PHP Namespaces, Part 2: Importing, Aliases, and Name Resolution
• How to Install PHP 5.3 on Windows

For the purposes of this example, we will define two almost identical code blocks; the only difference is their namespace:

lib1.php:

<?php
// application library 1
namespace App\Lib1;

const MYCONST = 'App\Lib1\MYCONST';

function MyFunction() {
	return __FUNCTION__;
}

class MyClass {
	static function WhoAmI() {
		return __METHOD__;
	}
}
?>

lib2.php:

<?php
// application library 2
namespace App\Lib2;

const MYCONST = 'App\Lib2\MYCONST';

function MyFunction() {
	return __FUNCTION__;
}

class MyClass {
	static function WhoAmI() {
		return __METHOD__;
	}
}
?>

There is a little PHP terminology to understand before we begin…

Fully-qualified name
Any PHP code can refer to a fully-qualified name — an identifier starting with the namespace backslash separator, e.g. \App\Lib1\MYCONST, \App\Lib2\MyFunction(), etc.

Fully-qualified names have no ambiguity. The initial backslash operates in a similar way to a file path; it signifies the ‘root’ global space. If we implemented a different MyFunction() in our global space, it could be called from lib1.php or lib2.php using \MyFunction().

Fully-qualified names are useful for one-off function calls or object initialization. However, they can become impractical when you are making lots of calls. As we will discover below, PHP offers other options to save us from namespace typing cramps.

Qualified name
An identifier with at least one namespace separator, e.g. Lib1\MyFunction().

Unqualified name
An identifier without a namespace separator, e.g. MyFunction().

Working Within the Same Namespace

Consider the following code:

myapp1.php:

<?php
namespace App\Lib1;

require_once('lib1.php');
require_once('lib2.php');

header('Content-type: text/plain');
echo MYCONST . "\n";
echo MyFunction() . "\n";
echo MyClass::WhoAmI() . "\n";
?>

Although we include both lib1.php and lib2.php, the identifiers MYCONST, MyFunction, and MyClass will only reference code in lib1.php. This occurs because the myapp1.php code is within the same App\Lib1 namespace:

result:

App\Lib1\MYCONST
App\Lib1\MyFunction
App\Lib1\MyClass::WhoAmI

Namespace Importing

Namespaces can be imported with the use operator, e.g.

myapp2.php:

<?php
use App\Lib2;

require_once('lib1.php');
require_once('lib2.php');

header('Content-type: text/plain');
echo Lib2\MYCONST . "\n";
echo Lib2\MyFunction() . "\n";
echo Lib2\MyClass::WhoAmI() . "\n";
?>

Any number of use statements can be defined or you can separate individual namespaces with a comma. In this example we have imported the App\Lib2 namespace. We still cannot refer directly to MYCONST, MyFunction or MyClass because our code is in the global space and PHP will look for them there. However, if we add a prefix of ‘Lib2\’, they become qualified names; PHP will search through the imported namespaces until it finds a match.

result:

App\Lib2\MYCONST
App\Lib2\MyFunction
App\Lib2\MyClass::WhoAmI

Namespace Aliases

Namespace aliases are perhaps the most useful construct. Aliases allow us to reference long namespaces using a shorter name.

myapp3.php:

<?php
use App\Lib1 as L;
use App\Lib2\MyClass as Obj;

header('Content-type: text/plain');
require_once('lib1.php');
require_once('lib2.php');

echo L\MYCONST . "\n";
echo L\MyFunction() . "\n";
echo L\MyClass::WhoAmI() . "\n";
echo Obj::WhoAmI() . "\n";
?>

The first use statement defines App\Lib1 as ‘L’. Any qualified names using ‘L’ will be translated to ‘App\Lib1′ at compile-time. We can therefore refer to L\MYCONST and L\MyFunction rather than the fully-qualified name.

The second use statement is more interesting. It defines ‘Obj’ as an alias for the class ‘MyClass’ within the App\Lib2\ namespace. This is only possible for classes — not constants or functions. We can now use new Obj() or run static methods as shown above.

result:

App\Lib1\MYCONST
App\Lib1\MyFunction
App\Lib1\MyClass::WhoAmI
App\Lib2\MyClass::WhoAmI

PHP Name Resolution Rules

PHP identifier names are resolved using the following namespace rules. Refer to the PHP manual for more information.

1. Calls to fully-qualified functions, classes or constants are resolved at compile-time.

2. Unqualified and qualified names are translated according to the import rules, e.g. if the namespace A\B\C is imported as C, a call to C\D\e() is translated to A\B\C\D\e().

3. Inside a namespace, all qualified names not already translated according to import rules have the current namespace prepended, e.g. if a call to C\D\e() is performed within namespace A\B, it is translated to A\B\C\D\e().

4. Unqualified class names are translated according to current import rules and the full name is substituted for short imported name, e.g. if class C in namespace A\B is imported as X, new X() is translated to new A\B\C().

5. Unqualified function calls within a namespace are resolved at run-time. For example, if MyFunction() is called within namespace A\B, PHP first looks for the function \A\B\MyFunction(). If that is not found, it looks for \MyFunction() in the global space.

6. Calls to unqualified or qualified class names are resolved at run-time. For example, if we call new C() within namespace A\B, PHP will look for the class A\B\C. If that is not found, it will attempt to autoload A\B\C.

See also:

• How to Use PHP Namespaces, Part 1: The Basics
• How to Use PHP Namespaces, Part 3: Keywords and Autoloading
• How to Install PHP 5.3 on Windows

In tomorrow’s final article we will cover autoloading and other advanced options.

Why Do We Need Namespaces?

As the size of your PHP code library increases, there is increased risk of accidentally re-defining a function or class name that has been declared before. The problem is exacerbated when you attempt to add third-party components or plugins; what if two or more code sets implement a ‘Database’ or ‘User’ class?

Until now, the only solution has been long class/function names. For example, WordPress prefixes every name with ‘WP_’. The Zend Framework uses a highly descriptive naming convention that results in long-winded class names such as Zend_Search_Lucene_Analysis_Analyzer_Common_Text_CaseInsensitive.

Name collision problems can be solved with namespaces. PHP constants, classes, and functions can be grouped into namespaced libraries.

How are Namespaces Defined?

By default, all constant, class, and function names are placed in the global space — like they were before PHP supported namespaces.

Namespaced code is defined using a single namespace keyword at the top of your PHP file. It must be the first command (with the exception of declare) and no non-PHP code, HTML, or white-space can precede the command, e.g.

<?php
// define this code in the 'MyProject' namespace
namespace MyProject;

// ... code ...

The code following this line will be assigned to the ‘MyProject’ namespace. It is not possible to nest namespaces or define more than one namespace for the same code block (only the last will be recognized). However, you can define different namespaced code in the same file, e.g.

<?php
namespace MyProject1;
// PHP code for the MyProject1 namespace

namespace MyProject2;
// PHP code for the MyProject2 namespace

// Alternative syntax
namespace MyProject3 {
	// PHP code for the MyProject3 namespace
}
?>

Although this is possible, I would advise against it: retain your sanity by defining a single namespace per file.

Sub-namespaces
PHP allows you to define a hierarchy of namespaces so libraries can be sub-divided. Sub-namespaces are separated using a backslash (\) character, e.g.

• MyProject\SubName
• MyProject\Database\MySQL
• CompanyName\MyProject\Library\Common\Widget1

Calling Namespaced Code

In a file named lib1.php, we will define a constant, a function, and a class within the App\Lib1 namespace:

lib1.php

<?php
// application library 1
namespace App\Lib1;

const MYCONST = 'App\Lib1\MYCONST';

function MyFunction() {
	return __FUNCTION__;
}

class MyClass {
	static function WhoAmI() {
		return __METHOD__;
	}
}
?>

We can now include this code in another PHP file, e.g.

myapp.php

<?php
header('Content-type: text/plain');
require_once('lib1.php');

echo \App\Lib1\MYCONST . "\n";
echo \App\Lib1\MyFunction() . "\n";
echo \App\Lib1\MyClass::WhoAmI() . "\n";
?>

No namespace is defined in myapp.php so the code exists in the global space. Any direct reference to MYCONST, MyFunction or MyClass will fail because they exist in the App\Lib1 namespace. To call code in lib1.php, we can add a prefix of \App\Lib1 to define fully-qualified names. The following result is output when we load myapp.php:

App\Lib1\MYCONST
App\Lib1\MyFunction
App\Lib1\MyClass::WhoAmI

Fully-qualified names can become quite long and there are few obvious benefits over defining long class names such as App-Lib1-MyClass. Therefore, in the next article, we will discuss aliasing and take a closer look at how PHP resolves namespace names.

See also:

• How to Use PHP Namespaces, Part 2: Importing, Aliases, and Name Resolution
• How to Use PHP Namespaces, Part 3: Keywords and Autoloading
• How to Install PHP 5.3 on Windows

PHP has moved on. These days, a developer that builds web sites that way is unlikely to gain a job (except perhaps one that pays poorly). Developers are expected to organize their code into multiple files, and URLs containing file names like index.php are definitely on their way out.

Experienced developers will use finely-crafted frameworks and web server configurations to convert so-called pretty URLs like http://www.example.com/thingy/. No ".php" advertising the fact that the site is built in PHP, no specific filename at all. URLs like this one are designed to be as simple and memorable as possible.

For the fourth edition of the book, I wanted developers to make a habit of this earlier, without forcing them to fiddle with their server configuration, or learn a complex PHP framework.

The easiest possible way I could find to produce pretty URLs was to take advantage of a feature built into every PHP-equipped web server out there: a URL that points to a directory on the server will automatically run a PHP script named index.php sitting in that directory.

With that in mind, here’s how all of the examples in the book from Chapter 3 onward are structured:

• A folder
  Everything goes inside a folder, whose name is the only visible part in the URL. So if the example displays "thingies", you would start by creating a folder named thingies, and the URL of the example would be http://www.example.com/thingies/
• A controller, index.php
  When a browser requests the example’s URL, the server will automatically run the index.php script contained in the folder. This file is called the controller, and contains all the logic for handling browser requests and performing tasks in response.
• Include files, like db.inc.php
  Pieces of code that will be useful in more than one example are pulled out of index.php and placed in separate PHP files. This is basic stuff for PHP veterans, but it’s a valuable coding technique that was covered much later in the third edition, in Chapter 12. Now it’s in Chapter 3.
• Template files, like thingy.html.php
  Once the controller (with the assistance of one or more include files) does all the work, it must prepare a web page to send back to the browser in response. Rather than slopping all the HTML code into index.php (which is what we did all the way through the third edition of the book), the fourth edition uses a separate file for the HTML code for each type of page. These template files consist mostly of pure HTML; the only PHP code they contain is there to output the values of PHP variables created by the controller. The code in these files is kept very simple, so that they can be handed off to designers who may be unfamiliar with PHP at all. Also, using separate files makes it easy to generate several different types of page (that is, serveral different template files) from a single controller.

All the little changes in approach like this one are what really makes me proud of Build Your Own Database Driven Web Site Using PHP & MySQL, 4th Edition. I used to describe the third edition of this book as giving beginners "just enough rope to hang themselves with."

With the fourth edition, beginners can breeze past the self-strangulation stage — hopefully straight into a well-paying career as a PHP developer!

I bet you’re wondering where the code is, right? To see how the “pretty URL” technique described above looks in code, be sure to check out Chapter 3 when we publish it on Thursday. Or if you’re unable to wait, grab all four chapters in PDF format today — free of charge.

A Word of Warning…

PHP 5.3 is new and you may experience some problems (see below). If you already have a stable PHP environment, ensure you keep a backup of your current php folder and settings.

Web Server Installation

If you have not installed Apache, refer to How to Install Apache Web Server on Windows. Optionally, you can also install the MySQL database — refer to How to Install MySQL.

PHP 5.3 Installation

Windows PHP distributions are now available from a dedicated microsite at http://windows.php.net/download/. The choice is a little bewildering and the instructions are vague but, since we will be installing PHP as an Apache 2.2 module using the Apache Lounge build, so you should download the VC9 x86 Thread Safe Zip file.

General note:
Download the VC6 builds if you are using the standard Apache.org web server. The VC9 builds should be used for the Apache Lounge binaries or IIS.

A Thread Safe version should be used if you install PHP as an Apache module. The Non Thread Safe version should be used if you install PHP as a CGI binary.

You can now follow the instructions at How to Install PHP on Windows from step 2 onwards. Note that, in step 3, php.ini-recommended is now named php.ini-development; you still need make a copy and rename it php.ini.

If you have previously defined a working PHP configuration file, a tool such as WinMerge can help you compare and copy existing values to your new php.ini file.

PHP 5.3 Error Reporting

The first time you load your previously bug-free PHP application, you are likely to be confronted by reams of long-winded error messages. Don’t panic! PHP 5.3 introduces a number of new error directives which are enabled by default in the development php.ini configuration:

• E_STRICT suggests improvements that ensure best interoperability and forward compatibility of your code, and
• E_DEPRECATED warns you about code that will not work in future versions of PHP.

Very useful. In my experience, the majority of messages report that a time zone has not been defined and assigning a return values using new by reference is deprecated.

Unfortunately, applications can display so many minor errors they become impossible to use. You can disable the new error directives by setting the error_reporting value to "E_ALL & ~E_DEPRECATED" on line 514 of php.ini and restarting Apache.

However, several web applications, including WordPress, define their own error_reporting settings and may continue to show messages. It will take a developers some time to upgrade their applications to full PHP 5.3 compatibility.

Have you installed PHP 5.3 successfully? Have you experienced any major issues or problems with existing code?

Today, we’ve published the beginning of the series: the Introduction and directly from the book, Chapter 1: Installation. Over the weekend you can read chapter 1 and make sure your newly installed software is working properly, in readiness for next week’s chapters. At the end of the week you’ll have 4 complete chapters from the book and one bonus article, comprising another book excerpt.

Here’s what you’ll be receiving:

Chapter 2: Introducing MySQL

An introduction to databases in general, and the MySQL relational database management system in particular. If you’ve never worked with a relational database before, you’ll find this enlightening, whetting your appetite for what’s to come! In the process, you’ll build up a simple database to be used in later chapters.

Chapter 3: Introducing PHP

Here’s where the fun really starts. In this chapter, Kevin will introduce you to the PHP scripting language, which you can use to build dynamic web pages that present up-to-the-moment information to your visitors.

Chapter 4: Publishing MySQL Data on the Web

In this chapter you’ll bring together PHP and MySQL to create some of your first database driven web pages. You’ll explore the basic techniques of using PHP to retrieve information from a database and display it on the Web in real time. Kevin will also show you how to use PHP to create web-based forms for adding new entries to, and modifying existing information in, a MySQL database on the fly.

Bonus: How to Handle File Uploads with PHP
In this bonus excerpt from Chapter 12, you’ll learn how to accept file uploads from your web site visitors securely and store them.

Build Your Own Database Driven Web Site Using PHP & MySQL, 4th Edition is one of the most popular PHP books for beginners, and SitePoint’s first ever book. This shiny new 4th edition has been completely updated using only best-practice PHP. It’s essential reading for all budding PHP & MySQL developers. For more information, see the book page.

If you prefer to read the Adobe Acrobat PDF version of these first four chapters, you can download the first four chapters FREE.

Build Your Own Database Driven Web Site Using PHP & MySQL (4th Edition) — by Kevin Yank

One of the most popular PHP books for beginners, this shiny new 4th edition has been completely updated using only best-practice PHP.

In this book you’ll learn how to:

• install PHP 5 and MySQL 5 on Windows, Linux, or Mac OS X
• gain a thorough understanding of PHP syntax
• master database design principles and SQL
• build a working content management system
• add, edit, and delete web content without using HTML
• create an ecommerce shopping cart
• utilize sessions and cookies to track site visitors
• craft SEO-friendly and memorable URLs

And a whole lot more …

At around 480 pages, this book is an easy read. As you move through the book you’ll quickly notice that it’s written in a clear tutorial format that’s easy to understand, and illustrated with plenty of screenshots and diagrams, providing quick visual cues. If you hate wading through dry, academic-style “how to” texts, this book will be a breath of fresh air to you.

If you’ve never built a database driven web site and you’re looking to go beyond the limitations of a static site, this book will start you off in no time.

And if you have built database driven web sites before, the extensive PHP/MySQL reference guides included will ensure this book remains an extremely handy desk reference.

Check out the free sample chapters or order a copy today.