This article applies to Drupal 5 and higher.

If you're the maintainer of a even a small site using CCK for managing your information, eventually you'll run into a problem synchronzing your local install with your live site (or Dev and QA servers). While setting up CCK fields is a breeze and you have SVN to manage your PHP code, many Drupal developers haven't found a way to easily migrate changes in the CCK data schema or content type fields. However, using the handy macro module and a few (very important) lines of custom code, you can be moving your field changes from Dev to live in seconds.

To clarify the task at hand, say you have a content type called "article". The article type contains 3 fields at the moment: Title, Body, and Picture. The problem is, your site is about to undergo a major overhaul where articles now contain Title, Excerpt, Body, Picture, Caption, Small Picture, and Related Links. Additionally, your boss wants them seperated into different field groups to make it easier to handle the more complex form.

Here's what we want our article content type fields to look like, before and after.

This article assumes you've already made your changes to your PHP code and have them ready to deploy through SVN, but you don't want to have to setup the changes to the content type manually on the dev server, qa server, live server, and potentially several of your coworkers' computers manually.

drupal_execute and Macro module

Fortunately, Drupal has a convient mechanism for being able to execute any form programatically. It's called drupal_execute(). Though often over-hyped and under-utlized, drupal_execute() can save us tremendous amounts of work. Drupal execute takes two arguments, the name of the form to execute, and an array of values to pass into the form.

Continuing down the list of cool things Drupal gives you, if you've downloaded and installed Devel module, it comes with a bundled module called Macro. Macro has the ability to record all your form submissions, then play them all back on different servers.

Now with Macro module enabled, we need to turn on form recording at admin/build/macro.

Now at this point, Macro module is watching all your form submissions and saving all the values for you. Go to your admin/content/types page and start making all the necessary adjustments to your content types. Add new types, add new fields, change field properties, make groups, arrange them however you want. Macro module is quietly watching you.

A sample macro

When you're done, skip over to admin/build/macro/export. You should have a field waiting for you that contains something like this:

Caveats to macro module

Once you've got the contents of the macro saved to a text file (just copy and paste), head over to admin/build/macro and turn off the macro recording.

You now have a macro which you should be able to run on your QA and Dev servers. Starting with a fresh copy of Drupal, try running your macro, but pay no attention to the following lines....

Oh no! what's this? Errors galore! This example exposes some of the largest short-comings of Macro module. Reading between the lines, the first error is basically saying it couldn't find the form "node_type_form" to execute. Some of the later problems such as "There are no groups configured for this content type." signal a much different problem.

Solutions to macro shortcomings

To fix the first one, we just have to make sure that the node_type_form is loaded. As an optimization, Drupal only loads this form if you're actually on the page that uses it. For a quick job, I'd just open up Macro module and add the necessary files.

The second problem that exists with Macro module is it's inability to give each form a clean start. Because many forms assume that they are the only thing running in a single request, many of them use caching mechanisms that will cause later form executions to fail. These include static variables in several core functions, such as node_get_types(). If you make a new type early in your macro, the new type won't be available to subsequent form executions. To fix this, we can clear these caches between each form submission.

Once again, open up macro module and change these lines:

Now run your macro again. Ta-da! A complete update of all your new content types, fields, groups and properties. If you use Macro module for other work, you'll want to roll back your changes as they can cause a lot of unnecessary changes for other macros that might be run. Macro module could also probably be improved to make such hacking unnecessary via a custom module, but for the time being, each macro will require it's own set of caches cleared and PHP files included manually.