PHP frameworks, Part 1: Getting started with three popular frameworks

Zend, symfony, CakePHP

A few short years ago, one of the more common criticisms about PHP was that it did not support MVC-style architectures. Times change. And these days, there are a number of choices available in the world of PHP frameworks. This series takes a look at three widely used PHP frameworks — Zend, symfony, and CakePHP — examining their similarities and differences while building and extending a sample application in each of the three frameworks.

Duane O'Brien, PHP developer, Freelance

Photograph of Duane O'BrienDuane O'Brien has been a technological Swiss army knife since the Oregon Trail was text only. His favorite color is sushi. He has never been to the moon.

09 October 2007

Also available in Russian Japanese Vietnamese

About this series

This series is designed for PHP developers who want to start using a framework, but have not examined the available frameworks in detail. This series examines why the three frameworks under examination were chosen, how to install each of the frameworks, and you'll get a good handle on the test application that you're going to extend in each framework. It might sound like a lot, but don't worry — we break it down into manageable chunks.

Part 1 of this series lays out the scope for the series, introduces the frameworks being examined, covers their installation, and scopes out the first test application you will build. (Phew!)

Part 2 walks you through building the sample application in each of the three frameworks, highlighting their similarities and differences.

Part 3 starts with extending the test application, then deals with exceptions to the rule. All frameworks work well when doing the tasks for which they were designed. Needing to do something the framework wasn't built to do happens on every project. This article looks at such instances.

Part 4 focuses primarily on Ajax support. The use of Ajax, using native code and third-party libraries, is examined — specifically, how each framework behaves and accepts specific popular libraries.

Part 5 deals with working outside the frameworks. A single task is identified (nightly update script), and the process for accomplishing this task is examined in each framework.

About this article

This article has a lot of material. You must get up to speed quickly. There are three frameworks under examination. Which three? Why these three? What other frameworks are there? Why not those, instead? So many questions! But you'll get most of them answered before you go through the installation process for each framework. Then you'll learn about the test application used in the subsequent parts of this series. Right away, you'll start to get a sense for how the different frameworks differently and what kinds of things they do the same.

System requirements

Before you begin, you need to have an environment in which you can work. The requirements are fairly minimal:

  1. An HTTP server that supports sessions (and preferably mod_rewrite) — This series was written using Apache V1.3 with mod_rewrite enabled.
  2. PHP V5.1.4 or later — Not all the frameworks being examined require this release level of PHP, but for the sake of ease, all frameworks will use the same PHP installation. This series was written using PHP V5.2.3.
  3. A reasonably recent installation of MySQL— Several other database options are available and supported, but both this series and the sample application were written using MySQL V5.0.37.
  4. An operating system that supports PHP V5.2.4 or later and MySQL — Linux® is used in this series. If you are a Windows® user, you will need to make obvious adjustments, especially when creating the directories mentioned below.


It is assumed that you already know PHP, application design, and how to work in a database. It's not necessary to have used a framework before, but you should certainly be ready to jump in with both feet.

Frameworks for dummies

Before talking about which frameworks were selected, it's worth talking about what a framework is.

The idea behind a framework is to offer a design you can use across multiple applications. All applications have a number of basic things in common — specifically, some kind of interface with a database, some amount of application logic, something that presents the application to the user. If you've written many PHP applications, you know what this looks like. You've probably written a set of functions or a class that reads and writes data from the database. You might have used a templating engine like Smarty to manage your UI. You've certainly written a bunch of PHP code that did things like analyze form submissions and make decisions based on submitted data. And if you've written many applications, you've probably done the same basic things over and over, sometimes stealing code from one application to use in another.

A framework is designed to provide a structure for these common elements (database interaction, presentation layer, application logic) so you spend less time writing up database interface code or presentation-layer interfaces and more time writing the application itself. The architecture represented by breaking an application up in this fashion is referred to as Model-View-Controller (MVC). Model refers to your data, View to your presentation layer, and Controller refers to the application or business logic. A full discussion of MVC is outside the scope of this article, but you are encouraged to research MVC and learn what all the fuss is about (see Resources).

Selecting a framework

There are several frameworks available for nearly every language. Selecting the right one for your needs can be somewhat difficult, especially if you haven't used any of them before. While advice and opinions from colleagues and trusty developerWorks authors can be helpful in this area, there is really only one guiding principle that should be followed when selecting any framework: A framework is only as good as the amount of time and effort it saves everyone. A framework is no good if it works well for you but causes a significant increase in support calls. A framework is no good if it is easy to support, but hinders rather than assists your development. A framework is useless if it is elegant, but causes support and development issues.

When selecting a framework for your project, consider everyone involved, from the top down, and when you evaluate the framework, keep the impact to other parties in mind.

When you consider adopting a framework, look at your application closely and ask yourself it if needs a framework. A framework isn't a necessity. Enterprise applications will continue to be written without the use of frameworks. Will a framework help you with the project? Will it save everyone time and effort? Will your application perform better on a framework? Will it provide the stability you are lacking? If the answer to any of these questions is yes, you should look to adopt a framework. If the answer to all of these questions is no, a framework will only complicate matters.

Unfortunately, size and scope restraints do not allow for a comprehensive coverage of all available PHP frameworks. This series focuses on three frameworks:

  • Zend Framework
  • symfony
  • CakePHP

These were selected based on a variety of factors, but might be best classified as "The One Your Boss Knows About," "The One Someone Else Already Installed," and "The One They've Been Talking About." I encourage you to research CodeIgniter, Seagull, Web Application Component Toolkit (WACT), PRADO, Zoop, PHP on Trax, or any of the many other PHP frameworks available. Framework selection is very much a personal choice, much like selecting a language in which to code. This series isn't going to tell you which framework is better, or worse, than the others. Where a framework does something well, it will be called out. Where a framework seems unwieldy, this will be called out, as well. Even if we are not comprehensive in our coverage of the myriad frameworks, the approach we take will help you weight the strengths and weaknesses of other frameworks. You need to form your own opinions about the frameworks being examined, which ones you like, and what you decide to pursue.

The Zend Framework

Everyone knows Zend — "The PHP Company." When you download and install PHP, you're downloading it from Zend and have been since around V3. In addition to distributing PHP, Zend Technologies has offered a wide range of PHP support technologies over the years. It should be no surprise that Zend offers a framework for PHP — a popular one at 2 million downloads to date. If your boss has heard of a PHP framework, the Zend Framework is likely to be the one.


Sponsored by Sensio, symfony "aims to speed up the creation and maintenance of Web applications, and to replace the repetitive coding tasks by power, control and pleasure." The symfony framework has been used worldwide in a number of enterprise-level applications, perhaps most notably Askeet and Yahoo! Bookmarks. Odds are that if someone you know has installed, used, or played around with a PHP framework, that framework was symfony.


Borrowing heavily from Ruby on Rails, CakePHP aims to bring simplicity and scalability to PHP frameworks. Consistently recognized as a top PHP framework, CakePHP was recently selected as the core around which V5 of the Mambo Content Management System. Driven by a strong community and a rapidly growing user base, CakePHP's popularity is growing steadily. If you've overheard a conversation about PHP frameworks, that conversation was probably about CakePHP.


Each of the frameworks has its own set of installation instructions, and a thorough discussion of installation particulars is outside the scope of this article. Each installation will be highlighted, calling out the high points that may not be covered in each individual framework's installation instructions, or where deviation from these instructions is necessary due to the particulars of installing all three on a single machine.

Begin by creating a folder to hold all the code, frameworks, and includes you will need for this series (for example, a directory called /column). In this directory, create four additional directories: htdocs, protected, include, and src. Edit your Apache conf file so the document root points to /column/htdocs — and while you're there (if you haven't already), you should enable mod_rewrite. Edit your php.ini conf file to include the /column/include/ directory in the include_path directive. Don't worry if this all doesn't make sense yet. As you install the frameworks, all will become clear.

Installing the Zend Framework

Download the Zend Framework (see Resources). This series was written using V1.0.1. Download and untar/unzip the Zend Framework into the /column/src directory. The distribution will contain a number of text files and three directories: demos, tests, and library. Copy the contents of the library directory (this should just be a folder called Zend) into the /column/include/ directory. You should now have a folder called /column/include/Zend containing a number of directories and files. These are the libraries used by the Zend Framework.

That's it! You've installed the Zend Framework.

Installing symfony

Download symfony (see Resources). You are free to install symfony via any of the methods listed on the download page, though for our purposes, it's recommended that you download the tarball. Unpack the tarball into the /column/src/symfony/ directory. You should wind up with four directories (data, doc, lib, and licenses), as well as some README docs. Not all of these are necessary for installation of a finished application, but for now, they will be fine. That might seem too simple for an installation. Keep in mind that these frameworks generally consist of utilities and libraries, so getting them installed isn't difficult. Using them will take a little more configuration. This will become clear later.

Not everyone has the option of using PHP Extension and Application Repository (PEAR) installation in their environment, which is why we refer to the installation method above. However, if you can use PEAR, by all means, do so. Both methods are described on the symfony installation page (see Resources).

Installing CakePHP

Download CakePHP (see Resources). This series was written using the version. The 1.2 branch of CakePHP, despite being a mature alpha, has been widely adopted by the CakePHP community as the norm. Download and unpack the tarball, placing the contents in /column/src/cakephp. You should wind up with four directories (app, cake, doc, and vendors), as well two files (.htaccess and index.php). You will be moving some of these files around later, but for now this is OK.

The test application

You've downloaded and installed three frameworks. But you'll have noticed that you didn't really do anything with them yet, like verify the installations with a Hello World application. That's because you're going to jump right past Hello World and into something a little (but not much more) meaty.

Building a Hello World application in a PHP framework can be a little painful. Using a framework involves some overhead, and that overhead gets in the way when you're trying to do something simple like Hello World. But that same overhead should seem like a well-spent expense when dealing with more complicated applications.

The test application you will build isn't much — yet. It's going to allow you to post text to the application using a text area. That text will be saved in a database and retrieved by the application for display on request. Using such an application, one would be able to easily create and update content on his Web site without having to edit HTML or upload new files. This highly innovative and ground-breaking application will be called Blahg.

What does Blahg look like?

Based on the description of Blahg, you have probably inferred several things about how the application will be designed. Blahg needs four elements:

  1. A page that contains a form — This form will need to contain at least a text area. This page will be the write page.
  2. A page that reads a post — This page will need to be passed some kind of post Identifier. This page will be the read page.
  3. A page that lists the available posts — This page will be the index page.
  4. A database table to hold posts — This table will need to at least hold the post text and the post identifier, and probably a Post title and the post's last-modified date.

Obviously, Blahg could be much more robust than this, and later in the series, you'll do a number of enhancements. But for now, let these simple requirements suffice. Unfortunately, you're not going to get a chance to build Blahg in any of the frameworks just yet. That comes in Part 2. But now is a good time to set up the databases you will be using.

Setting up the databases

Before you can really build Blahg, you need to get the databases set up. It's not at all necessary to set up a database for each individual framework, but for the purpose of this series, it will help keep things a little more organized while avoiding the necessity for table prefixes.

Create three databases, called Zend, symfony, and Cake, and grant full rights to each database to an appropriate user. The instructions for each framework below will contain the SQL necessary to create the posts table.

While you're in there fiddling with the databases, you may as well create the tables that Blahg will use in the beginning. Create a posts table in the Zend and symfony databases using the following SQL.

Listing 1. Creating a posts table in Zend and symfony
CREATE TABLE 'posts' ( 
'title' VARCHAR( 255 ) NOT NULL , 
'text' TEXT NOT NULL , 

For Zend and symfony, you're leaving the maintenance of the modified column up to the database. For CakePHP, you're going to use a slightly different SQL. Doing so will allow Cake to perform some magic on your behalf (specifically, CakePHP will maintain the modified column automatically).

Listing 2. Creating a posts table in CakePHP
CREATE TABLE 'posts' ( 
'title' VARCHAR( 255 ) NOT NULL , 
'text' TEXT NOT NULL , 

That is about as simple as table syntax can get. Based on how these tables look, you should have a pretty clear image for how Blahg is going to look and work. You might even try your hand at building Blahg yourself.

Next steps

Resist the temptation to jump in and start fiddling with the frameworks right away. Instead, take some time and build Blahg without using any frameworks. Write it the way you are accustomed to writing your applications, whatever way that may be. Just be sure to stick to the requirements listed above while building Blahg — don't get too fancy yet. By building up the test application outside the context of a framework and modifying the application to include the enhancements you build throughout the series, you can give yourself a good gauge for how well a given framework suits your needs and how well a given framework fits with your development style.


We covered good ground here. I hope your installations went smoothly, but if you ran into any issues, you should dig into the installation documentation for each respective framework (see Resources). Take the time to build up Blahg according to the instructions above. It will be time well spent.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Open source on developerWorks

Zone=Open source
ArticleTitle=PHP frameworks, Part 1: Getting started with three popular frameworks