Want to get Lullabot article, videocast, and podcast announcements delivered right to your in-box?
Let us know your email address (we won't share it) and we'll let you know when anything exciting happens.
Using Macro Module to Move Content Type Changes Live
Drupal version: 5.x
October 31, 2007
Moving field changes from development to live doesn't have to be a stressful, error prone, and tedious process. Leveraging the macro module to test and package your field changes can make pushing changes painless. This video accompanies an article on the same topic: Moving CCK Field Changes from Dev to Live
Twitter
Mailing list
RSS Feed
Comments
So wait-- in the demo there
So wait-- in the demo there was an error the first time you ran the macro. You cleared some cache stuff in the macro module itself, and then everything ran as expected. Two questions:
1. Is it generally a good idea to re-run a half completed macro like that, or is there a chance you'll be doing some of the stored commands more than once (and create multiple fields or whatever)?
2. Was the bug in the macro module something we'd need to change if WE were running the module? Or was that just some debugging commentry (a word I made up now) left accidentally that we normal users don't need to worry about?
Thx, and nice demo..
Oh no! Busted.
So honestly I skipped a step in there during editing (I didn't record it at the time it seems). After the first error, I went in and deleted the half-created content type and started over. Thanks for pointing out that you would NOT want to just run the same macro twice after it screwed up the first time. You'll need to cleanup the mess that might have occurred during the failed macro.
The problem pointed out and corrected in the video is an actual problem you'll run into when running macros. The code mentioned will solve the short-comings of macro module for this scenario, but there's a chance additional changes might be necessary for other special forms.
Does "macro" also record actual content creation.
I was just wondering if this module goes a step further in being able to record any database values; i.e. a new node created from the new content type?
I am very interesting on
I am very interesting on this, but when running macros, it will reports some errors, "argument is expected ....", it seem need one upgrade.
Thanks for the great post,
Thanks for the great post, just moved a few sites to Drupal and this is tremendous help.
new module uses macro to track changes for a custom module.
I just posted the first release of a tool I wrote to make this procedure much easier.
Been studying all the options for change management, deployment, etc. for months now, and I never found something that was able to deal with absolutely every part of drupal. Most projects compartmentalize the different drupal objects and only deal with those.
There are tons of modules that store their own information, imagecache, custom_breadcrumbs, custom_links, etc.
After seeing macro.module, and journal.module, it hit me... save pertinent form submissions, and you would be able to capture any changes made through the web interface, regardless of the module being used or the data structure underneath it.
http://drupal.org/project/custom_module_tools
What the module does is track form submissions (only when a box is checked) and associates them with updates to your site's custom module. It then generates the code for your custom module's next hook_update_N() function for easy exporting. Then, all you have to do is upload the new version of yourcustommodule.install and the associated include files, then run update.php to execute all of the changes chosen to be saved for that update.
After initial testing, it seems to work swimmingly.
In theory, this should work with all form submissions, including views, panels, and CCK changes... more research is needed.
Post new comment