EBDUG #1 Session - One Man's Battle Versus the Drupal Staging Problem
As a freelancer and Drupal specialist, I've worked with a number of website-building teams. It seems like each group reinvents solutions to the problem of sharing settings between multiple copies of Drupal. Frankly I'm not sure "solution" is the best word, because with each team, there have been headaches in setting up a new copy of the site for development, and further headaches getting changes to other developers' copies and to the live server.
This problem has been called "the Drupal Staging Problem" (in an excellent summary by Dominique De Cooman). If you ask around, you'll hear about a number of solutions, including but not limited to hook_update_N, backup_migrate.module, features.module, deploy.module, and possibly others I don't know about. In this post I describe a new(-ish) approach that I call site_update.
So many solutions! Does that mean the problem is solved? Or could it mean the problem is widespread, but not solved at all?
Dave Cohen is a software engineer who has worked with web standards since before there was a web. Seriously, he was an early adopter of SGML, the parent standard of XML and HTML. With a background in C++ and Java programming, Dave was drawn to Drupal for its power and extensibility. His drupal.org user page describes him as "member for 8 years." Wait, can that be right? Dave suspects a bug! However long it has been, he's known for several contributed modules including tac_lite and Drupal for Facebook. Dave is currently a freelance Drupal developer based in San Francisco.