How to customize the default Directory Structure

One of the great advantage of using a framework is the consistent structure it gives across your projects. All projects share the same coding standards, and also the same directory structure. This structure allows several developers to work on the same project at the same time. But it also enhances the maintainability of the developed applications. When someone ask you to maintain a symfony project that you haven't developed initially, you know where all the files are stored and you can start hacking right away.

But sometimes, you need to be able to customize the directory structure provided by symfony. Let's take two very different examples.

First, let's say you host your symfony project in a shared host environment, where the web root directory is named public_html. By editing the ProjectConfiguration class, it's very easy to change the default web root directory from web to public_html as show below:

// config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->setWebDir($this->getRootDir().'/../public_html');
  }
}

Let's take another example. Your symfony project is now hosted by a very big company with strict security rules. They don't allow your applications to write on the disk except for some specific directories (/tmp for example). As symfony only writes in two directories (cache, and log), it's very easy to update the ProjectConfiguration class again to move these directories under /tmp:

// config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->setCacheDir('/tmp/myproject/cache');
    $this->setLogDir('/tmp/myproject/log');
  }
}

The setCacheDir() method not only changes the sf_cache_dir constant but also all the cache related ones: sf_app_base_cache_dir, sf_app_cache_dir, sf_template_cache_dir, sf_i18n_cache_dir, sf_config_cache_dir, sf_test_cache_dir, and sf_module_cache_dir.

And last but not least, as the configuration classes are also used for the symfony CLI, all these customization are also active for all the bundled symfony tasks and your specific tasks.

Thanks to the new configuration classes of symfony 1.1, the configurability of the framework has never been so easy.