Building a Custom PHP Framework with a custom template caching engine using Output Control functions

In past 1 year or so, I had opportunities of using a lot of php frameworks including zend, symfony, cakephp, codeigniter. All frameworks have their pros and cons, however that is out of scope of this blog post. You may want to checkout this comparison list of php frameworks here.

In this blog post I will build a custom PHP framework (MVC Architecture). Then go on to discuss in brief about the output control functions and finally show how to build a custom template caching engine using these functions for our framework.

Source Code
You may want to download the complete source code for this blog post from here.

Building a custom PHP Framework
We will choose a MVC architecture for our framework. Here is a basic directory structure for our custom framework:


The view, model, controller, log and cache directories contains the following framework modules respectively:

  1. view directory contains our view level files. i.e. files containing our HTML, js, css code.
  2. model directory contains the model class responsible for interacting with database and other storages
  3. controller directory contains our controller class. Each incoming request is first received by the controller class constructor, which thereafter controls the flow of request in the framework
  4. log directory contains our logger class. This class is auto loaded for every request providing a basic logger::log($log_message) logger method throughout the framework. This class logs all data in a file called log.log.
  5. cache directory contains our cache class. For this blog tutorial, we will only write the template caching engine class. In production systems, we might have individual classes for other types of cache systems e.g. memcached (Read Memcached and “N” things you can do with it – Part 1 to know more about memcached and MySQL Query Cache, WP-Cache, APC, Memcache – What to choose for a complete comparison lists of various other caching techniques.

Lets see in details, what all file each and every directory contain contains.

Root directory files
We have 4 files in our root directory, namely .htaccess, index.php, config.ini.php and 404.php in order of relevance. Lets look through the content of these files:


RewriteEngine on
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
  1. 1st two lines essentially means that Switch on the apache rewrite module and set RewriteBase as / i.e. the root directory
  2. Last 3 lines mean that, if incoming request is for a file or directory which physically exists under the root directory serve them otherwise route all other requests to index.php in the root directory

Hence now for an incoming request like http://localhost/test1.php, apache will route the request to index.php in the root directory because there is no test1.php under the root directory. Cool, lets see what index.php has to offer.



  // include configuration file

  // include controller files


index.php doesn’t do much except for including our core configuration file and controller class file. Controller class constructor is initiated as soon as the class file is included.

config.ini.php is our core configuration file. It provides the framework with an array called $config containing various information like: mysql database credentials, requested url details and various other global parameters. Lets see what all parameter does it provide us with.



  $config = array(
                                'name' => "http://".$_SERVER['HTTP_HOST'].'/',
                                'uri' => $_SERVER['REQUEST_URI'],
                                'url' => parse_url($_SERVER['REQUEST_URI']), // note it contains the parsed url contents
                                 'host' => 'localhost',
                                 'name'=> 'testdb',
                                 'user' => 'root',
                                 'pass' => 'password',
                                 'template' => 'On', // template caching switched on by default
                                 'memcached' => 'Off', // switch off memcached caching


$config[‘host’] array saves various parameter about the host itself, e.g. hostname, hosturi (the requested uri, hosturl (it contains the parse_url(hosturi)).

$config[‘mysql’] array contains mysql database parameters. However in this blog post we will not interact with databases.

$config[‘cache’] tells the framework what all caching modules are switched on.



    <h1>404 Page</h1>

Controller directory files
For this blog post, controller directory consists of a single class file. i.e. controller.class.php. We saw this being included by index.php in the root folder above. As soon as controller class is included, it’s constructor is invoked. Before we dig in more, lets see the controller class file:



  // include logger class

  // include cache class (contains template caching)

  // include model class

  class controller {

    function __construct($config) {
        global $config;

        // generate requested template name and path
        $config['template']['name'] = $config['host']['uri'] == '/' ? 'index.php' : substr($config['host']['uri'], 1, strlen($config['host']['uri']));
        $config['template']['path'] = "view/".$config['template']['name'];

        // check 404
        if(!file_exists($config['template']['path'])) {
            $config['template']['name'] = "404.php";
            $config['template']['path'] = "404.php";
        logger::log("Requested template name ".$config['template']['name'].", path ".$config['template']['path']);

        // invoke template caching engine
        $template_cache = new template_cache();

        // include the template

        // cache template


  $controller = new controller($config);


At the top, controller class includes the logger.class.php, cache.class.php and model.class.php files. At the bottom, the controller object is instantiated.

The constructor performs the following 5 tasks:

  1. At first it generates a template name and a template path for the incoming request i.e. for http://localhost/, $config['template']['name']='index.php' and for http://localhost/test1.php, $config['template']['name']='test1.php'.
  2. Second it checks for 404. For the above generated template path, e.g. $config['template']['path']='view/test1.php', it checks whether this file exists inside root directory. If it doesn’t template path and names are set to 404.php
  3. Thirdly, It invokes the template caching engine. i.e. $template_cache = new template_cache();
  4. Forth, it includes the generated template path above i.e. include_once($config['template']['path']);
  5. Fifth and finally, it caches the generated HTML, js, css code by the template file includes above. This is achieved by the following code, $template_cache->setTemplate();

Before we move our attention to, lets see in short the content of log and view directories.

Log directory files
Log directory contains our logger class. This class is auto loaded for each incoming request that is being routed to index.php in the root directory (as we saw above). The logger.class.php provides a static logger::log($log_message) method, which can be used throughout the framework for logging messages. We will be using it everywhere.



  class logger {

    static $log_file = "log/log.log";

    static function log($log) {
      if($log != '') {
        $fh = fopen(self::$log_file, "a");
        fwrite($fh,date('Y-m-d H:i:s')."n".$log."nn");



The logger class by default logs all data to a file called log.log.

View directory files
For this blog post, we have two simple test pages in view directory namely test1.php and test2.php, which can be access by typing http://localhost/test1.php and http://localhost/test2.php respectively in the browser.



      <?php echo model::test1data(); ?>

test1.php simply calls the model class method called model::test1data() (static method). This method extracts some dummy text from the database and returns it back.

Model directory files
Model directory contains the model class file. In production systems, model class file will provide various methods to select and insert data in the databases. However for this blog post we will simply return some static dummy test.



  class model {

    // This method will return data generally from a database table
    // To keep it simple for the post we return some dummy lipsum text
    static function test1data() {
      logger::log("Returning test1data() from database");
      return "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin ut nulla ac risus viverra ornare. Nulla consectetur, metus eleifend pharetra posuere, lacus nibh elementum leo, in fermentum lectus lorem in ipsum. Nullam pulvinar purus at erat pharetra volutpat. Pellentesque egestas rutrum lectus, ut rutrum tellus tristique sed. Integer diam est, ornare ac ultricies vel, aliquam non mi. Etiam tempor leo eu lacus tempus sagittis sagittis turpis dictum. Sed leo sapien, pharetra sit amet faucibus et, mollis id nulla. Praesent feugiat mi nec dui scelerisque mollis vehicula magna feugiat. Aliquam erat volutpat. Curabitur quis velit ut nibh rhoncus convallis. Proin mauris nunc, rhoncus vel laoreet vel, aliquet quis nunc. Aenean interdum risus non neque blandit sed adipiscing ipsum mollis. Vivamus enim orci, ultrices at scelerisque vel, laoreet a turpis. Nullam posuere ante sed nisl porta porta aliquam metus suscipit. Fusce enim odio, iaculis at suscipit eget, vestibulum volutpat enim. Nam dictum turpis quis velit posuere in malesuada mi convallis. Donec faucibus, felis id dictum imperdiet, orci tortor tristique neque, vitae lobortis libero tellus sed lorem. Duis tellus magna, commodo eget blandit ut, auctor nec nibh. Maecenas ornare ornare risus nec ultrices. Pellentesque lectus eros, imperdiet ut rhoncus vel, tempus ut nisi.";

    static function test2data() {
      logger::log("Returning test2data() from database");
      return "Vestibulum laoreet nibh sed nulla mollis cursus. Maecenas sodales mauris sit amet ligula euismod a lacinia turpis adipiscing. Nulla gravida porta augue, id adipiscing libero tincidunt ac. Morbi non velit id odio porta tempus id eget massa. Cras nibh purus, gravida sed suscipit ut, tincidunt eu neque. In id est eros, ac sodales orci. Ut lectus augue, feugiat sit amet consectetur id, pharetra quis tellus. Maecenas eget lobortis urna. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce tincidunt eleifend neque. Aenean accumsan orci vitae erat blandit porttitor. Aliquam tristique dolor ac nibh elementum id lacinia diam cursus.";



Cache directory files
For this blog post, cache directory contains the main cache.class.php file which in turn includes various other cache classes e.g. template.cache.class.php



  // check for switched on cache modules
  foreach($config['cache'] as $key => $value) {
    // include all cache classes, which are swicted on
    if($value == 'On') {
      // naming convention is <modulename.cache.class.php>


Output Control Functions
PHP is a very simple language. You can write a Hello World! code or calculate similarity between two strings (see similar_text()), both with a single line of code. And hence there are a lot of fundamental concepts of PHP, which not only beginners but even some advanced coders can ignore. One such concept is Output Control in PHP.

The Output Control functions allow you to control when the output of your PHP script will be thrown to the browsers (console). i.e. You can pre-process the final html output (append, prepend, chip-chop, inserting ad-codes, url linking, keyword highlighting, template caching), which will otherwise be thrown on the browser. Interesting, isn’t it? Can you feel the power of Output Control functions?

  1. ob_start: This turns on output buffering. i.e. no output is sent from the script, instead the output is saved in an internal buffer. However output buffering doesn’t buffers your headers. ob_start() also takes an optional callback function name. The function is called when output buffer is flushed (see ob_flush()) or cleaned (see ob_clean()). We can access the this internal buffer using functions like ob_get_contents()
  2. ob_end_flush: This function send the content of the buffer (if any) and turns off output buffering. We should always call functions like ob_get_contents() before ob_end_flush(), since any changes after this functions will not reflect on the browser

Building a custom Template Caching Engine
We saw above some of the output control functions PHP has to offer. ob_start(), ob_get_contents() and ob_end_flush(); are the 3 functions we will use to create our custom template caching engine.



  class template_cache {

    var $template_cache_file = FALSE;
    var $template_cache_file_ext = ".tmp";
    var $template_cache_dir = "cache/template/";
    var $template_cache_ttl = 300; // secs

    function __construct() {

      // initiate template caching


    function init() {
      // get template path
      $this->template_cache_file = $this->generateTemplatePath();

      // get template from cache if exists

      // start output buffering

    function generateTemplatePath() {
      global $config;

      // generate template file name
      return $this->template_cache_dir.$config['template']['name'].$this->template_cache_file_ext;

    function getTemplate() {
      global $config;

      // check if a cached template exists
      if(file_exists($this->template_cache_file)) {
        if(time() - filemtime($this->template_cache_file) < $this->template_cache_ttl) {
          logger::log("Cache hit for template ".$config['template']['name']);
          $content = file_get_contents($this->template_cache_file);
          echo $content;
        else {
          logger::log("Cache stale for template ".$config['template']['name']);
          return FALSE;
      else {
        logger::log("Cache miss for template ".$config['template']['name']);
        return FALSE;

    function setTemplate() {
      global $config;

      // get buffer
      $content = ob_get_contents();

      // save template
      logger::log("Caching template ".$config['template']['name']);
      $fh = fopen($this->template_cache_file, 'w');
      fwrite($fh, $content);

      // Flush the output buffer and turn off output buffering



As we saw above in controller class, the template engine class was instantiated before including the actual template file. Template engine constructor do the following 3 tasks:

  1. Generate a cached file name for the requested uri by calling the $this->generateTemplatePath(); method. e.g. if http://localhost/test1.php is the requested uri, test1.php.tmp is it’s static cached template
  2. Secondly, it tries to fetch the cached template file by calling the method $this->getTemplate(); (read on for details of this method)
  3. Finally it turns on output buffering by calling ob_start();

List of methods provided by template.cache.class.php are:

  1. generateTemplatePath() method generates a cache file name for incoming request. By default extension of all cached files in “.tmp” and are stored under the /cache/template directory.
  2. getTemplate() method do a number of tasks. First, it checks if a cached template exists for the requested uri. If it does not exists or if it is not a fresh cache (see $template_cache_ttl), this method simply returns control back to controller which go ahead and include the actual template file. However if the file exists and is fresh it reads the content of the file and throw back to browser. At this point control is no longer transferred back to the controller, hence saving various un-necessary processing and database calls.
  3. setTemplate() method is called by controller after including the actual template file from under the view directory. Point to note is that, before getTemplate() returns control back to controller (in case of missed or stale cache), the template cache class constructor does switch on output buffering. And when setTemplate() method is called, we can access this buffer using output functions like ob_get_contents() and then save the template for next incoming request. Bingo!. Finally this method throw away the buffer to the browser using ob_end_flush();

Is it working?
To verify the flow of framework, I hit the url http://localhost/test1.php 3 times, with $template_cache_ttl = 10; (seconds).

  1. Once after clearing the template cache folder
  2. Once within next 10 seconds
  3. And finally after 10 seconds

Here is how the log file looks like:

2009-08-16 19:50:49
Requested template name test1.php, path view/test1.php (1st REQUEST)

2009-08-16 19:50:49
Cache miss for template test1.php

2009-08-16 19:50:49
Returning test1data() from database

2009-08-16 19:50:49
Caching template test1.php

2009-08-16 19:50:54
Requested template name test1.php, path view/test1.php (2nd REQUEST)

2009-08-16 19:50:54
Cache hit for template test1.php

2009-08-16 19:51:03
Requested template name test1.php, path view/test1.php (3rd REQUEST)

2009-08-16 19:51:03
Cache stale for template test1.php

2009-08-16 19:51:03
Returning test1data() from database

2009-08-16 19:51:03
Caching template test1.php

Moving forward, What’s Next? Extending template.cache.class.php
Template cache class can be extended to do a lot more, other than caching the template files. For instance we might want to perform (chip-chop, append, prepend etc) a few tasks, before we cache the final template and throw back to the browser. Few tasks which look quite obvious to me are:

  1. Short Codes: We can insert short codes in our HTML templates, which later on can be expanded into full fledged codes. e.g. For embedding a YouTube video, we can simply put something like [[YouTube yjPBkvYh-ss]] into test1.php. And in setTemplate() method we can call helper/plugin methods to process such short codes. More professionally, we can add hooks for various tasks we might want to perform before caching the template. Read How to add wordpress like add_filter hooks in your PHP framework for a more professional approach.
  2. Inserting page header and footer: Instead of including page header and footer inside test1.php, we can simply put our main <body> code inside test1.php. Then before caching the template file, we can append and prepend header and footer modules to the buffer of each page. Thus avoiding including the same header and footer files across various pages.
  3. HTML module caching: There are several instances where we can have a common module across all pages. For instance, I can have a events module across all my pages, which basically displays a calendar with various events for the week or month marked on it. The event details are extracted from the database. Since this module of mine is a static HTML chunk for atleast a week, I would like to have a difference cache for this module. Intelligently hooking up these modules with template caching engine, can allow us to do module level caching

I can probably write down 10-15 more such applications and probably there might be many more such applications of the above coded template caching engine. (Note: The power actually lies in Output Control Functions provided by PHP).

Let me know if you liked the post or any bug in it.

How to build a login-registration system using Symfony – A PHP Framework – Part 2

Hello again,

In the last tutorial we saw a very basic implementation which will simply print “Hello World” on your browser screen. For those who have landed up here straight here, you may want to go through this blog post. Getting started with Symfony – A PHP Framework – Part 1 By now if you have decided to go ahead with symfony and use it for your site development, this is what you will be looking for next.

You can download the code for this tutorial from google code base.

svn checkout
Frameworks/Symfony/Authentication abhinavsingh-read-only

A Registration-Login-Logout System for your site
This is mostly the first thing you end up building for your site. To be frank, I myself haven’t made this application. I will make it as I write this blog, and note down all my steps here, so that I don’t miss any detail.

  1. We will name our project as Authentication
  2. Create a folder called Authentication under the Symfony directory we made in the last tutorial. For me its here C:WorkspaceSymfonyAuthentication
  3. Open your command line and point it to the above created folder
  4. Type “symfony init-project Authentication” and it will create same directory structure that we discussed in last tutotial.
  5. Lets create an application inside this, we will name it as Auth
  6. Type “symfony init-app Auth” and it will create an application named Auth under the apps folder. (C:WorkspaceSymfonyAuthenticationappsAuth)
  7. First we need a module called Registration, to allow our users to register.
  8. Type “symfony init-module Auth Registration” and it will tell symfony to create a module named Registration inside our application Auth
  9. As told in last tutorial copy the C:php5peardatasymfonywebsf folder to C:WorkspaceSymfonyAuthenticationwebsf. At the end of this part, we will learn how can we skip this copying again and again
  10. Open C:WorkspaceSymfonyAuthenticationappsAuthmodulesRegistrationactionsactions.class.php and comment out the forwarding as discussed in last tutorial.
  11. Go to your command line and type “symfony clear-cache“. Read why we do this in the last tutorial.
  12. Open http://localhost/Symfony/Authentication/web/ in your browser and you must get something like this.

Figure 1

OOPS! Did we missed something? Yes we did and intentionally. We could have gone to C:WorkspaceSymfonyAuthenticationappsAuthconfigrouting.yml and redirected our Authentication application to our Registration Module by default. In that case we would have seen an empty page since indexSuccess.php file inside C:WorkspaceSymfonyAuthenticationappsAuthmodulesRegistrationtemplates is empty. But since we didn’t modified the routing.yml file, it took us to the default module of symfony.

So how do we access our Registration module without modifying routing.yml file??
http://localhost/Symfony/Authentication/web/Registration/index is the answer 🙂

As a convention
this is the standard for symfony.

Hence it went to Registration module and then indexSuccess.php page inside that. Cool so we actually just followed up from our last tutorial till here. Lets now do the actual development.

Defining a layout for our website
Before we do any backend stuff, lets atleast get our site out of that blank page (http://localhost/Symfony/Authentication/web/Registration/index). However, If you view the source of that blank page, you will actually find that there are already some header, css, body tags in the source code. How is this coming? when we have an empty indexSuccess.php file.

From our last tutorial we saw the flow which symfony follows to finally display a page on the browser. But then I actually skipped a step to ease down the tutorial. In symfony we follow the Decorator Design Patterns (I hope i m not wrong here) , to get the front end stuff. Essentially Decorator Design Pattern consists of a Layout and a Content page.

In symfony our layout file is located under at C:WorkspaceSymfonyAuthenticationappsAuthtemplateslayout.php. Open it up and you will know the answer to “How are those meta tags, head tags and body tags coming”.

Cool enough. Lets go back to our indexSuccess.php file of Registration module and design our website. With a little CSS and HTML, I came up with this design page for our site. Mostly inspired and stolen from my new site

Figure 2

We will shift a bit of code from this page to our layout.php page later on so that we need now write the same modules again and again. Download all the code, from the my google code vault location given at the beginning and end of this tutorial.

Designing the backend database:
Now we need  a databases schema which will save our registered user’s data.  Lets create our database structure.

As talked about in last tutorial, symfony follows ORM programming technique. For this, they provide a method through which you actually need not go to your database and create tables. Symfony will do that for you. Not only this, Symfony will also allow you to skip most of the SQL queries. Lets see how.

  1. Open C:WorkspaceSymfonyAuthenticationconfigschema.yml . From extension we know that symfony follows YAML structures which is similar to XML, but a bit easy to write. We will define our table structures in this file.
  2. Type the following in the schema.yml file:
        id:        { type: integer, primaryKey: true, autoIncrement: true }
        username:  varchar(100)
        emailid:   varchar(100)
        password:  varchar(100)
  3. Note the indentation, it is very very important when you are using YAML. Indentation actually decides how the YAML parsers will read and interpret the information you want to write in .yml files. In our case we have a very simple schema.yml file having only one table. We will learn about what that “Propel” is all about later, but lets focus from line 2.
  4. We are trying to make a table called users having fields like id, username, emailid and password
  5. Now before Symfony makes this table for you, we need to tell symfony the database username and password. For this we have a configuration file called propel.ini, located at C:WorkspaceSymfonyyahooconfigpropel.ini
  6. Open it and change the lines as below:
    propel.database.createUrl  = mysql:[email protected]/
    propel.database.url        = mysql://root:[email protected]/authentication

    Now go to your mysql database and create a database named authentication, which symfony will use from now on.

  7. Type “symfony propel-build-all” in your command line. This command will happily create a table named “users” in youy MySQL database “authentication”. Some of the possible errors which I got in the past are:
    • Your PHP must be compiled with XSLT, hence enable it by going in your php.ini file
    • In schema.yml file never use TABS. The YAML parsers don’t understand TABS. User SPACES intead of that.
  8. To cross verify check your database, if the table has been created. Now a bit about Propel.

Propel is nothing but a third-party-vendor plugin which Symfony use. It helps in parsing the YAML files, creating and executing the whole ORM module including parsing of schema.yml , creating tables, creating ORM data objects. We will slowly and gradually learn a lot more about ORM.

A look at the model layer
Another thing which the propel command did was, it created the whole ORM module. If you go to C:WorkspaceSymfonyAuthenticationlibmodel you can see 2 folders being created and a few files too.

For every table, propel build 5 files under the model folder. These files are basically the class files, which will provide use with a database object which we can use to select or insert data in the database.

C:WorkspaceSymfonyAuthenticationlibmodelomBaseUsers.php &
C:WorkspaceSymfonyAuthenticationlibmodelomBaseUsersPeer.php are the only 2 files which will be re-created when you run the propel command again.

The file positioned at
C:WorkspaceSymfonyAuthenticationlibmodelUsers.php &
C:WorkspaceSymfonyAuthenticationlibmodelUsersPeer.php will be as it is from this point in time. If you write your own methods in them, they will remain as it is even when you re-create your database schema.

We will use these created ORM files to insert, delete, select data from the databases. In symfony we can actually skip writing a SQL query (though we can always write a direct query too)

Writing the backend Code:
With UI and database in shape, its time to write our backend code which will handle the registration form submission. If you notice the source code of our form, the action field is set as :

<form id=”registration” action=”<?php echo url_for(“Registration/index”); ?>” method=”POST”>

In symfony we have a lot of helper functions which we can use. In this case we users url_for helper function, which helps in generating a url with <module>/<modulefile> being passed as parameter.

So we have our form being submitted to indexSuccess.php itself, i.e. SELF.
Hence lets go to executeIndex() method in action.class.php and write the code which will handle the submitted form.

Copy the modified action.class.php file from the vault location. I have documented every line inside the code, which will walk you through the code. Understand the flow and continue reading.

However before we insert any data in the database, we need to give the database parameters. Go to
and uncomment the lines of code in there. Finally it should be of the following structure:

    class:          sfPropelDatabase
      dsn:          mysql://root:[email protected]/authentication

Lastly open:
and go to the last line of the file. You will find
# compat_10    off
being commented out
Uncomment it and then turn on compat_10 i.e.
compat_10    on

Clear your cache, before submitting the form (symfony clear-cache) and then try to register.

If you have followed everything, you will be able to successfully able to register and visit mainSuccess.php of the module.

I have documented all the code which you can download from the vault location. Read it, try it, play with it.

PS: The best documentation is available at symfony-project website. This tutorial was intended to
build a real life scenario application using Symfony. Though I must admit that I still haven’t used 100% possible symfony
for this application, just to make it simple but still give you a feel of how things flow in symfony.

Leave a comment if you have any doubt or difficulty in implementing the code.
Do leave a comment even if you like the code 😉

Getting started with Symfony – A PHP Framework – Part 1

Hello Friends,

Since past few weeks I have been pushed into something which I have never favored i.e. using a framework for my development. Using a framework can become even more harder if you know all the actual HTML, CSS, JS, PHP coding. Then you just wonder WHY? WHY? WHY?

Anyways I had to do it using Symfony PHP framework and there was no way out. As I couldn’t find much help outside , it made even more difficult for me to implement and understand symfony.  So I thought of writing a tutorial, which can help many others like me out there and also act as a reference for me in future. Here instead of giving a theory lecture straight up, we will learn along with little hands-on developments.

Before installing Symfony I assume we already have Apache, PHP 5 and MySQL installed on your system. If you don’t have them already installed, read this post of mine on how to configure WAMP on your windows. How to Install Apache, PHP 5 and MySQL on Windows?

This method works equally on Windows and Unix systems. On windows open your command line and on Unix open a terminal window.

  1. Go to My Computer -> Right Click -> Click on Properties -> Advanced Tab -> Environment Variables -> Create a PATH variable if it doesn’t already exists -> Add C:PHP as the PATH variable value.
  2. Go to Start -> Run -> Type cmd -> Type C:> pear channel-discover
  3. Type C:> pear install symfony/symfony-1.0.18 , it will install symfony latest stable version for you. (1.0 at the time of writing this tutorial)
  4. If you are having trouble installing, post a message here or refer for more details.

So now you have symfony framework installed and we will learn how to build our first project in symfony.

My first Project:
Before we go ahead in making our first php project using symfony, just a little theory without which its impossible to understand the flow. Symfony projects are designed as follows:

       My First Project –> Application 1 —-> Module 1
                                  |                              |
                                  |                              –> Module 2
                                  -> Application 2 —-> Module 1
                                  |                              |
                                  |                              –> Module 2
                                  |                              |

                                  |                              –> Module 3
                                  -> Application 3 —-> Module 1

So in your Project your can have multiple Applications and inside every application you can have multiple Modules.

  1. Go to your Apache Web Folder (Document Root) which in my case is C:Workspace.
  2. Create a folder called Symfony. We will keep all our symfony related development work in this folder.
  3. Go inside the folder C:WorkspaceSymfony and create another folder for our 1st project. Lets name it HelloWorld
  4. Open your command line and go to the above folder path i.e. type ‘cd C:WorkspaceSymfonyHelloWorld’ on your command line.
  5. Type ‘symfony init-project HelloWorld’ and press enter. This will automatically create the project directory structure for you. Don’t be afraid if you see some 10 folders being create by the last command.

Don’t close the command line window, we will need that throughout.

So by now we have our first symfony project folder ready (structurally). But to view this on your browser we need atleast 1 application and atleast 1 module in that application. Lets create them quickly.

  1. Type ‘symfony init-app HelloWorld’ and press enter. This will create an application folder C:WorkspaceSymfonyHelloWorldappsHelloWorld. Now lets create a module inside this application
  2. Type ‘symfony init-module HelloWorld HelloWorld’ and press enter. This command means, create a module named HelloWorld inside application HelloWorld. Generic level syntax is ‘symfony init-module [application] [module]’

So we have our first symfony project ready. Type http://localhost/Symfony/HelloWorld/web in your browser window and press enter. You will see a page like this:

Figure 1

But this is not what it should be. If you read the page, it says “If you see no image in this page, you may need to configure your web server so that it gains access to the symfony_data/web/sf directory”.

So all you need is to copy folder C:php5peardatasymfonywebsf (in my case) to C:WorkspaceSymfonyHelloWorldwebsf. If you don’t find sf folder at the specified place, kindly search for it on your system. It was created when we were installing symfony.

After copying the folder refresh your web page again and see if you see any difference. For me it looks like:

Figure 2

Well Congratulations ! You just made your first symfony project. But unfortunately you know 0% of what did. Right? Lets understand what exactly is going in the background.

A bit about MVC Architecture:
Symfony follows MVC (Model-Viewer-Controller) Architecture to the core. If you haven’t worked with MVC architectural frameworks before, it can really take sometime to get a feel of it. I took about a week to actually understand what goes in the background.

MVC Architecture is nothing but breaking your whole page code into three parts namely Model (Database) , Viewer (Frontend HTML Pages) and Controller (Which fetches data from Model i.e. database and provide it in required format to Viewer i.e. what we finally see on our browsers). This is a very layman definition which I have given. We will slowly and gradually see each aspect of MVC in Symfony.

A bit about ORM (Object Relational Mapping):
This is yet another programming technique which you will find in each and every framework. In layman language, ORM provides you an object to handle your database. You need not write a SQL Query in actual at any point in your project. You will access all your database rows using this ORM Object.

Strange it may seem at first, but consider a big project running on MySQL with a lot of INSERT queries. Now at some point in time when database size reaches > 50 Gb or so and you are finding MySQL not efficient enough to handle such a large database, you would want to change to a database like Oracle. In such a scenario, ORM takes all the headache off from you, as you need not care about the actual SQL queries that goes in the background. ORM automatically takes care of this stuff.

Understanding Symfony Directory Structure:
The Symfony directory structure of our first project will look like this:

Figure 3

Remember we still don’t have anything dealing with the databases, hence I can say that Model layer is still missing from the directory structure. But let us first complete our targeted “Hello World” application.

  1. Go to HelloWorld/apps/HelloWorld/config folder and open the file rounting.yml
  2. Change the 4th line in that file from – param: { module: default, action: index } to param: { module: HelloWorld, action: index }
  3. We will learn about all .yml files which you see, but as of now lets focus on what we just did. By default our Symfony project points to a default module created by Symfony. Thats why we see Figure 2 above. By changing the above piece of code, we are telling our HelloWorld application inside HelloWorld project that, by default point to my HelloWorld Module. Confusing! Read the last line again and continue reading 😉
  4. Go to HelloWorld/apps/HelloWorld/modules/HelloWorld/actions and open the file actions.class.php
  5. Comment the following php code $this->forward(‘default’, ‘module’); inside executeIndex() method.
  6. Go back to your command line and type: ‘symfony clear-cache’
  7. Type http://localhost/Symfony/HelloWorld/web in your browser window and press enter.

Bingo! You see a blank white page. Lets understand what we actually did. But before that just a few points on how a page is actually displayed in Symfony.

  1. When we type http://localhost/Symfony/HelloWorld/web in our browser, index.php in the web folder goes to routing.yml file
  2. Routing file then tells which module to follow by default. By following Step 2 above, we directed the flow to our HelloWorld module.
  3. Then flow goes to the actions.class.php file of the module provided by Routing file. Hence in our case it must have gone to actions.class.php file of HelloWorld module.
  4. It looks for executeIndex() method in the class file, executes it and
  5. Finally goes to indexSuccess.php file placed under the template folder of our HelloWorld Module.

But since our actions class method was already diverting the flow to the default module, flow won’t have come to step 5 above and would have gone to default symfony module. By commenting out the line in step 5 above, we actually skip this forwarding and the flow comes to indexSuccess.php file under templates module. And finally since indexSuccess.php file is a blank file, we see a blank page. 🙂

Read the above 2 point charts carefully. If you can understand this flow, you already conquered half the symfony.

Note: All this will go waste if you forget ‘symfony clear-cache’ in step 6 above. As a rule of thumb, always run this command when ever you make any changes to any of the .yml files.

My First Project “HelloWorld”
Open indexSuccess.php and type <h1>Hello World</h1> into it. Run http://localhost/Symfony/HelloWorld/web in our browser, and thats it 🙂 You will see a page like below.

And with that we completed our Part 1 of this Symfony tutorial series. In upcoming parts of the series we will learn how to manage databases and build a bit more complex application and modules. Post your doubts and comments if any.

Note: I am myself learning many parts in Symfony and I myself gather knowledge by experimentation and through various web sources. Hence if a Symfony expert is reading this and find anything wrong, kindly correct me.