Skip to main content

Our approach to site development

June 10, 2010
Body paragraph

Here are the principles and steps we take to planning a site.

Get everything you can out of existing modules and configuration

Drupal comes with a powerful core and a good selection of well maintained add-on modules. Even for a relatively complex project, you're likely to get at least 80% of your needs covered out of the box with pure configuration as opposed to new development.

Key steps

  • Match up desired functionality with existing, proven solutions.

Pitfalls to avoid

  • Throw out an available solution because it doesn't exactly match preconceived ideas.
  • Extensively override an available solution.


  • Be open to a range of solutions. Does that piece of functionality really need to be exactly the way you pictured it? Can an available implementation instead meet the need, maybe with a few tweaks?
  • Embed your configuration in code and make it reusable.

Improve the software, not your copy of it

If you've adjusted your expectations and still need new functionality, look first to how you can enhance existing code.

Pitfalls to avoid

  • Patching/hacking without contributing your changes and working to get them accepted.

Because the source code is available, it's quite possible to patch the modules you use, or even Drupal core, and in fact it's done all the time. But doing so is dangerous.

  • Lack of testing and review. Patches haven't had the level of scrutiny and testing that applied code has and could provoke unforeseen errors or security holes.
  • Barrier to updates. Having patched code presents problems when a new release version is available. Rather than just downloading and installing the new improved version, you have to worry about integrating your changes. And your changes may well conflict with other changes that have been made meantime.

On a more general level:

  • Needs bypassed. Because your solution is running only on your own site, it's likely to be bypassed when others address the same problem you faced. So solutions, when they're developed, may present upgrade challenges and may not include your particular needs.


  • Contribute changes. Make all changes as contributions and allocate sufficient time and resources to get them through the patch review and revision process.
  • Never patch core or contributed modules, unless:
    • The patch you're applying has already been accepted and applied, and so will be available in a future release, and
    • It addresses a need that's critical to your project.

If needed, invest in contributable development only in areas that are really critical to your mission

  • Any new development done for your site is a long term investment, since it will require maintenance and upgrading.
  • If you're investing in custom development, make sure it's in areas that are truly core to your work.

Pitfalls to avoid

  • A solution that's highly tied to a particular implementation. It's not flexible if
    • the needs change or
    • a similar need arises elsewhere.


  • Build your solutions on available hooks and APIs.
  • Consider whether the developer will contribute the code in the form of a project.
  • Include a maintenance plan for the contributed project.
  • Ensure custom code
    • rigourously adheres to Drupal coding standards
    • is well documented by in-line comments
    • includes automated test coverage

Keep site-specific customizations limited and contained

Pitfalls to avoid

  • Extensive custom module-level code specific to the site.


  • If absolutely required, put site-specific customizations in a small custom module specifically for the site.

Minimize custom theming

Pitfalls to avoid

  • Extensive logic and functionality in the theme.
  • Burgeoning theme overrides.


  • Handle display wherever feasible at the module level:
    • Field renderers
    • View renderers
    • Panel styles
  • Keep logic and functionality out of the theme layer.
  • Do everything you can with style sheets (CSS) as opposed to template overrides
  • If possible, do your customization purely through a local stylesheet for an existing, well maintained theme.
  • If you need to build a custom theme, use an established base theme like Zen or Fusion.

In summary, some key points

  • Get as much as you can out of existing solutions. Often, this means adjusting your expectations or adopting different solutions for the same problems.
  • In each case, weigh the advantages of customization against the costs.
  • Ensure that code-level improvements use available APIs.
  • Focus the bulk of your development work on contributed enhancements rather than custom code.
  • Make your configuration-based structures reusable.
  • Contributing back improvements is not just altruistic--it's key to successful use of open source.