About IT and Sports

My Web development experiences and sports encounters


Posts Tagged ‘Drupal’

Handling settings.php in Drupal

When working with Drupal there is a moment where you have to think about the way you want to manage settings.php. This file contains important configuration settings like the database credentials. It is most often also used to add custom configuration settings. Drupal comes with a default version of this file and during installation Drupal will write the database settings to this file.

The problem
Many projects run in a DTAP (Development, Testing, Acceptance and Production) development process, using a SCM tool like git or svn in a multi developer and multi location environment. The following problems/requirement should have your attention:
1. Each DTAP environment have their own specific settings as does every developer. For instance the database settings. Changes to settings.php will probably lead to SCM conflicts.
2. From a security point of view you don’t want database passwords in version control. Especially when you are using an online service like github.com.
3. You want to be able to make environment specific settings (develop, test, acceptance, production). For instance when you have a Varnish instance which only runs on acceptance and production.
4. General configuration settings for all environments should be possible
5. You want to prevent working with local changes or unversioned files on any environments

The solution
To handle the requirement above, we have worked out way to achieve this:
- Database settings are taken out of settings.php and moved to a separate file env.settings.inc. This file is included from settings.php
- The file env.settings.inc is not added to version control. In git you can use .gitignore to keep it out of version control.
- In env.settings.inc a variable is included to define the environment:
$environment = “develop”; // Possible values: develop, acceptance, production

- Per environment a settings file is created: develop.settings.inc, etc. These files are included in settings.php and added to version control.
- General configuration settings which are needed for all environments are added to settings.php. Settings.php is also added to version control.

In settings.php we add the following:

if (file_exists (‘./’ .conf_path(). ‘/env.settings.inc’)) {
include_once(‘./’. conf_path(). ‘/env.settings.inc’);

if (file_exists (‘./’. conf_path(). ‘/’. $environment . ‘.settings.inc’)) {
include_once(‘./’. conf_path(). ‘/’. $environment . ‘.settings.inc’);

This solution meets all the requirements. It’s clean and and well-ordered. And most importantly it prevents a lot of irritations, because you don’t have conflicts on settings.php anymore. If you found any flaws in this configuration or if you have another strategy on settings.php, please share them.

This article was originaly posted on the Colours blog.

Building webapplications on top of Drupal

Drupal is best known as one of the most popular CMS products used on the web. But the Drupal community likes to call Drupal a Content Management Framework; a tool which gives you the ability to quickly and efficiently tailor a webapplication to your needs. Drupal is not just a content publishing tool but can be used on a broad range of applications.

Web applications often contain functionalities which CMS tools also have. Users need to register and login. Autorisation is needed to distribute permissions. A template engine separates data from layout. You want to have tools for consistent interfacing. These are a few important functions you will probably need  in every web application. But there are many more which might be useful in the more specific requirements of your project.

An important part of the Drupal framework is the module system. It gives you the ability to separate custom code from the Drupal core and  modules. This makes updating Drupal to newer versions much easier and packages functionality in a orderly fashion. Drupal furthermore gives modules the ability to hook into core functionality. For instance to create new url’s or to change forms.

A good example of a webapplication we have build at Colours is the web application for the anual World Press Photo contest. This application contains 3 parts:

  1. A frontend in which photographers can register, upload and manage their photos
  2. A backend for administration of photographers and uploaded photos
  3. A tool for judging photos

A custom tailored web application was needed to accomodate for a high performance website and complex functionality. Good performance is need to smoothly upload 100.000 large photo files in a short timeframe. Most of the images are uploaded in just a few days before the deadline. During the upload proces some cpu and memory consuming operations are needed to convert images to a custom size. A separate imageserver was responsible for image conversions. The webservers communicated with the imageserver through SOAP webservices. We used the YUI Uploader to facilitate a user friendly(multi file select, progress tracking) and high performance (faster upload, asynchronous events) method of uploading files.

The backend functionality for administration and judging implement the Contest rules. These screens make good use of the Drupal Form api to efficiently create forms and permissions to implement autorisation.

A more specific functionality is the link to Salesforce CRM. A contributed module was used to make the connection to Salesforce. Custom code was writen to map the custom user profile to the specific user account fields in the CRM database.

Drupal offers an excellent environment if you want to mix a CMS with specific application functionality. You can easily use what the Drupal core has to offer. Use contributed modules to incorporate more specific functions. All this gives you great power and flexibility.

Dutch version posted on drupal.nl:

This article was originaly posted on the Colours blog which has recently been taken offline.