River flows…

I’m currently working on two medium sized Drupal projects. The first website is mainly a content rich marketing / “brochure” site with several content types, blocks, views, feeds and some bespoke tools.

The other project is a large scale “front-end” to several web services, offering much more functionality than static content.

Drupal fits in quite well in both cases although I’ve noticed a different paradigm in each case on HOW we use Drupal.

Project #1: Give flexibility to the content manager / webmaster

In this scenario the main aim is to offer the content manager great flexibility so that he can – as an administrator – make quick configuration changes, touch menus, change views in the LIVE environment. Keeping the content and configuration settings in the database while using the standard templating system for theming.

The only exceptions here are the content types, those are quite unlikely to change regularly over time so it’s safe to store them on the code level.

Regularly backing up the LIVE database and replicating it on STAGING and on DEV can keep the environments consistent.

Pros:

• once deployed to LIVE the content manager / webmaster has “full control”
• allows quick changes in configuration
• allows you to change the “logic” behind some of the views / sections

Cons:

• since we store most things in the database it could be slower than approach #2
• new configuration settings (during development) must be captured and recorded on DEV, then re-played on STAGING and on LIVE

Project #2: Keep everything on the code level / under version control

In this case our aim is to minimize the deployment “overhead”, taking most of the configuration settings (that we previously had to capture with scripts and later re-play them on STAGING and on LIVE) and put them into module code.

This approach is good if the functionality / configuration we provide does not change often.

Pros:

• since the configuration settings are stored in the code it can be accessed much faster (advanced caching can be applied here)
• everything is under version control, rollback is relatively easy

Cons:

• you need to touch the code to make a small configuration change, test, package a release, and finally deploy to LIVE

Conclusion

You can, of course combine the two approaches, that’s where Drupal really shines.