settings

Getting an error inside a core function? Infinite Redirect? debug_backtrace() to the rescue!

Published April 20, 2011

We are all very familiar with the White Screen of Death in the Drupal world, AKA WSOD. One very common cause is a lack of memory for PHP - yet another is having errors turned off.

In development mode, you should probably make sure you are showing PHP errors on the screen, if this is an option. This is the kind of thing you can edit in your site-specific settings.php file, by using:

All my files disappear when I move from localhost to production - Drupal 7

Published December 18, 2010

Every Drupal site I build involves at minimum two environments: one is on my laptop, which I call the local server; another is what most people call the production server. Drupal has a very straightforward way of allowing you the developer to use a single code base to run both environments, even though they are on different machines, in different corners of the world, with different passwords, etc.

Keep Local Database and Filesystem Settings in a Site-specific settings.php

Published August 6, 2009

A common development practice is to keep a local web server running on your laptop, or a development/staging server. A feature of Drupal designed for multisite installations can actually help you out in this situation.

Different servers often mean different databases, database users, and passwords. Sometimes, you may also need to point to a different files/ directory or tmp/ directory, especially if you are moving between Windows to Linux, or a local machine to a server.

Module Development: Settings Variables in settings.php Using $conf

Published May 21, 2009

Sometimes you need to set some global variables in Drupal that aren't used by just a single module, but rather a set of modules. You can take advantage of the $conf array in your site's settings.php file to set these variables that your various modules can then access them using the "variable_get()" method.

For example, I have a client that pulls in some data from an external SQL Server database to their Drupal site. Data is pulled in by a variety of custom modules and they wanted to have a single, secure place to set the database connection information.