Using configurations to your benefit

Configurations play a crucial role in the workings of Zend Framework 2, therefore it is essential to know how it works.

How to do it…

Go through the following sections to use configurations to your benefit:

Creating a global configuration

When beginning to code in Zend Framework 2 there is some misunderstanding as to what the different configuration files do. By default we have multiple configuration files, and it might not always be simple to understand where things need to go. That is why we like to apply a simple rule:

Note

Is the configuration necessary throughout all our modules? If yes, place your configuration in the config/application.config.php file. If not, place your configuration in the config/global.php file at the module where it belongs.

The configuration that we usually place in the global.php file can be, for example, the caching method and configuration, the database configuration. Normally we would like to place items in there that are environment related, but nothing that is security sensitive.

Let's take a look at a bad example of global.php:

<?php
return array(

  // We want to create a new database connection
  'db' => array(

    // The driver we want to use is the Pdo, our  
    // favorite
    'driver' => 'Pdo',

    // This is our connection url, defining a MySQL 
    // connection, with database 'somename' which is 
    // available on the localhost server.
    'dsn' => 'mysql:dbname=somename;host=localhost',

    // This is exactly what we should NOT do in this  
    // file, shame on you developer!
    'username' => 'terribleuser',
    'password' => 'evenworsepassword',
  ),

  // We need a database adapter defined as well, 
  // otherwise we can't use it at all.
  'service_manager' => array(
    'factories' => array(
      'Zend\Db\Adapter\Adapter' => 
  'Zend\Db\Adapter\AdapterServiceFactory',
    ),
  ),
);

It is terrible practice to put the username and password in the global.php file. The global.php file is to be put in our version control, and therefore should contain only configuration items that are required to globally run the application, not specific information that is relevant per environment, such as database usernames and passwords.

Creating configuration that only works for a local machine

One of the benefits of the ultra-many configuration files in Zend Framework 2, is that you are able to override your global configuration with your local configuration. This certainly comes in handy when developing and you find yourself in a position where your details are slightly different in configuration than your production environment.

Let's assume that we have the following /config/autoload/global.php configuration file:

<?php
return array(

  // We want to create a new database connection
  'db' => array(

    // The driver we want to use is the Pdo, our  
    // favorite
    'driver' => 'Pdo',

    // This is our connection url, defining a MySQL 
    // connection, with database 'somename' which is 
    // available on the localhost server.
    'dsn' => 'mysql:dbname=somename;host=localhost',
  ),

  // We need a database adapter defined as well, 
  // otherwise we can't use it at all.
  'service_manager' => array(
    'factories' => array(
      'Zend\Db\Adapter\Adapter' => 
  'Zend\Db\Adapter\AdapterServiceFactory',
    ),
  ),
);

As we can see in the preceding example, we create a nice and simple MySQL database connection to our somename database which resides on the localhost. But as good developers we have not defined our username and password in here. That is where the /config/autoload/local.php file comes in.

Let's take a look at how our local.php might look like:

<?php
return array(
  'db' => array(
    'username' => 'awesomeuser',
    'password' => 'terriblepassword',
  ),
);

If we are using a version control system (please say yes), we should not commit this file, not only for security reasons but also because this is a local configuration file and wouldn't be necessary on a live system, as we would create a new one with the right details for that environment.

Editing your application.config.php file

If we look at our default config/application.config.php file we have only a few properties set, but loads of inline comments, which really come in handy when we can't remember the exact name or description of a property any more.

The main configuration that we will be changing the most in our application as we develop is the modules property. This specific property is a simple array with the different module namespaces that we have (and want to use) in our application. At default this looks somewhat like this:

<?php 

return array(
  // This should be an array of module namespaces used 
  // in the application.
  'modules' => array(
    'Application',
  ),
[..]

When we add or remove a module, this line needs to be modified as well and one can even suggest modifying this before starting a new module or removing one. The reason for this is simple, when we forget to modify this file when removing a module it will generate a 500 – Application Error when visiting the application in our browser. And because this configuration file is read quite early in the instantiation, it can sometimes be hard for the developer to pinpoint why the application fails to load all of a sudden.

How it works…

If we look at the index.php file in the public folder, we can see that we parse our initial configuration file to the Zend Framework MVC Application with the line require 'config/application.config.php'. This then loads up the main configuration file, which in its turn defines all our properties.

A nifty property in the application.config.php file is the config_glob_paths property. Any additional configuration files are by default read by finding files in the config/autoload folder as well, using a very specific file pattern namely; *global.php and *local.php. The order in which this is defined is also very important.

When we say *global.php, we can define anything from somemodule.global.php to menu.global.php to just global.php, as the file pattern (also named GLOB_BRACE) searches for anything that matches that. The same happens for *local.php.

The order this is defined is very important as said before because we want our global configuration to be loaded before our local configuration, otherwise there would be no point in overriding our global configuration, would there?

There's more…

To summarize the configuration files:

• config/application.config.php: Modules can be added and removed here, and very low level configuration happens here.

• config/autoload/some-module.global.php: Used to override your default values of your module configuration. Make sure not to put sensitive information in here, but hostnames and database names should go in here.

• config/autoload/some-module.local.php: You can put your usernames and passwords and other configuration items that are very specific to your local environment here.

• module/SomeModule/config/module.config.php: Module specific configuration happens here, use only default values and make sure nothing too specific will be entered here.