Drupal Tips

By far the most advanced Content Management System (CMS) available today, Drupal is a community supported system with a suite of plug and play options that put their competition to shame.

The code is accessible and customizable, and the modular system does not suffer from the inter-modular dependencies we so often see plaguing other code systems. The coding standards are rigorous, as is the testing suite before modules are deployed.

In the many years we have been developing Drupal sites, we have picked up a few practices which make the experience easier.

Including Site-Specific Files and Code in a Drupal Site

With every site we develop, we include a custom module directory, sites/all/modules/mysite. In this directory we place all of the custom style sheets, javascript files and php code specific to our site at mysite.com.

First we create a file, mysite.info:

name = mysite
description = Various functions and files required by mysite.com
core = 7.x
package = Other
; Uncomment and expand the following lines as required.
; Files containing classes
;files[] = mysite.inc
;stylesheets[all][] = mysite.css
;scripts[] = mysite.js

Any special stylesheets or javascript files are placed in the modules/mysite directory, and references with the appropriate directive are put in the modules/mysite/mysite.info file. This allows the files to be aggregated and cached on a production site, improving performance, and it means that the modifications are not overwritten when the core, a theme or a module is upgraded. Any scripts or stylesheets defined in the .info file will be loaded by hook_init() and will be aggregated and included on every page. More information is available on the Drupal site here.

We also create a file, mysite.module, containing any site-specific php code which might be necessary. The most common function in this module is mysite_cron(), which implements any special maintenance tasks necessary for the site to function. Even if you do not have any site-specific functions, place an empty mysite.module file in the modules/mysite directory so your module can be activated under admin/modules.

* mysite.module
* Add any site specific tasks and hook implementations below.

The sky is the limit here, but the intent of this method is to create a repository of all those little odds and ends you include in any site development.

If you are developing a major function for your site, you are advised to do it in its own module, and perhaps put it up on the Drupal site, as others may have an interest in it. That way you have the whole community testing, coding, proposing upgrades, etc.

Block to show node data structure

One of the most frustrating tasks for a new Drupal developer is to visualize the information structures produced by Drupal during a page load. This can be extremely importand during major version upgrades, when intrinsic changes to data structures can break the php code your previous site relied on.

Rather than hacking modules, writing print_r outputs to watchdog, or other methods I have heard of, I generally create a php enabled block, restricted to the administrator role, and activate it in the page footer.

The code to display the $node object structure in D7 is:

$node = menu_get_object();
print "node " . $node->nid . " array is: <pre>" . print_r($node, TRUE) ."</pre>";

Showing the block only for the administrator role even allows you to activate it on a live site that you are trying to trouble shoot.