The Sustainable Drupal Manifesto

Mel Brooks' 15 Commandments

NOTE: This topic was presented (with an expanded slide deck) as a session at Baltimore DrupalCamp.  

What is Sustainable Drupal?

Sustainable Drupal is our approach to developing systems that can be used, maintained and enhanced as easily as possible, with the lowest level of knowledge required to be effective.

As far as site-building approach, the basic development philosophy is to have a goal of a deliverable system maintainable by non-developers (or, at least, non-expert developers) that will benefit from the most community enhancements without having to do new development:

  • Use core
    • Don't Hack Core
  • Use contrib module if core can’t do it
    • Don't Hack Contrib
      • Better to improve a contrib module with the needed feature (and contribute it back!) than write a custom module
      • If you need different functionality than the module offers:
        • If not, define a new module hook where needed, contribute the patch for the new hook, and then make your changes in a custom module using the new hook.
        • See if you can get the alternate functionality added to the module (if it's useful to many people)
  • Better to use contrib than write custom code  
  • Only if all else fails, write custom code.  
    • Make sure all configuration options have admin pages and are exportable
    • If possible, make your custom module flexible/generic enough to make it a contrib module that others can benefit from and make it available to the community.
  • It's better to do it in the UI than in code
    • Code is invisible magic.
    • Don't use invisible magic.
    • Things like views hooks are especially hard to debug later 
      • If you must use invisible magic, try to point to it from somewhere (custom module description, view description, etc)
  • Document strangeness in the system
    • Use Help Text, Advanced Help module, content content fields, views descriptions or other ways of building documentation directly into the system.
      • It will make future debugging much less painful (a.k.a "expensive")
  • Feature-ize config, not content.
    • Structure (menus, "lookup" taxonomy terms) may be considered content in some instances
  • Configuration should be configurable through the UI whenever possible
    • Any configuration overrides made in settings.php (or elsewhere) should indicate the changes are present on the UI page (Example: SMTP module)
  • PHP programmers are not automatically Drupal programmers.  
    • Make sure devs understand Drupal’s way of doing things, or they will likely cause present and future problems.
  • Better to solve the problem now than to make it someone else’s problem later (that someone might be you, anyway)
  • Maintenance is part of the development cycle.  
    • Schedule into sprints keeping core and modules updated at least quarterly.  Wait longer than that and updates become upgrades.
  • Code review is good, at least skim code changes for pull requests/merges to develop branch.

That’s my off-the-top-of-my-head (and will probably be evolved) thoughts.  Feel free to comment, disagree, cheer or scream in horror as you see fit.