View Single Post
  #2 (permalink)  
Old February 7th, 2009, 05:55 AM
victorkane victorkane is offline
Wrox Author
Join Date: Nov 2008
Location: Buenos Aires, , Argentina.
Posts: 23
Thanks: 0
Thanked 5 Times in 4 Posts
Default You hit the nail on the head

First of all, thanks so much for your praise. Basically, in writing the book I have tried to achieve just that, the possibility of folks not having to go through a steep learning curve by putting everything you need in a single place.

Your two questions point to a huge difficulty in Drupal architecture, namely that of the configuration, both in terms of things like blocks and module installation, being mixed with content in the database in such a way that it is no trivial task to "merge" similar databases in the way you describe.

On the one hand, there are possible solutions, that need to be digested and adapted to your process. On the other, there are integration and build strategies you must set up in your team.

Regarding possible solutions, every now and then in the Drupal community, solutions have been promised, but there has never been a straightforward, practical solution that just works.

Reading and ways forward on this topic:

2. Also see Kathleen's Database scripts, published on Drupal, which may very well be the answer to your question, but it needs to be digested and adapted to your process:;
3. Greg's deploy module:
4. The Aegir group of modules, with hosting, provisioning and site install/deploy scripts:
5. Other solutions that have been suggested over the years, like incrementing the node counter by odd or even increments on development and production machines, and the like.
6. Installing content remotely via protocols such as REST and XML-RPC (blog api and the services module) allow some separation of configuration and content. See my own article:

So, the other side of the coin is that a team strategy has to be developed, and it involves an "integration moment". That is, individual developers, who may use the SVN repository to branch, must each be invited to merge.

This may not be as painful a moment as might be imagined. By branching the code, that is, the Drupal instance, a developer may be able to abstract their work into a module, including code-based views as .inc files (dealt with in Chapter 14), where the database configuration can be dealt with as an install script that accompanies the module. Installation profile resources (also dealt with in Chapter 14) are another method, especially taking into account modules that export database configuration to scripts.

This is as realistic an answer as I can give you at this point in Drupal history.

On a practical level, you may simply need more than ever to work on a test site, figure out what you want to do, then repeat that work on the production site where the content is held.

We can explore this in more detail, as need be, and you are invited also to join in the Leveraging Drupal Workshop Central, by leaving comments, which is just getting underway (there is a separate child page for each chapter):

I will place the gist of this discussion under Chapter 3.

Thanks again for your feedback.

Victor Kane
Victor Kane
Reply With Quote