Keeping Blocks in Synch

liberatr@drupal.org's picture
public
liberatr@drupal.org - Tue, 2008-04-15 22:08

Hey folks,

I've worked on a number of Drupal sites where we needed to keep multiple sites in synch, and Drupal has been a challenge to keep that way because so many options are changed through the UI - this tends to show its weakness when we want to keep the settings across all sites (don't even mention content). Moving content types and views is easy with the import/export tools, but blocks are another story. The visibility rules, Roles, and input formats all require your time and attention to detail - time you could be spending working on other features.

Today I came across a very simple system for keeping blocks in synch: just move the database tables.

This works well, because even if block id numbers get out of synch, you are just overwriting the entire table, so no harm done. Also, if you want to create a new block, you will always be doing so at your integration point, before you push the changes to a testing/QA/beta area and then the production area, right?

Just do a mysqldump on these three tables:

blocks
blocks_roles
boxes

and import the resulting data into your production server. It saves you lots of time clicking checkboxes on those pesky Block visibility settings and trying to get all the weights and regions just right. You can also keep a copy of the SQL data in your revision control system, so you always have a snapshot of how your blocks looked at the time of the snapshot.

There was a time when I used the Insert Block module to include blocks, and that would break blocks based on IDs, but if you really need to include blocks in the content area, please look at using regions.

For panels, you might just have to move the panel data along if your site is dependent on block ids. Blocks generated by views or modules should not be so hard.

What else might prevent someone from just moving these tables over? Discuss.