I have a Drupal 6 website that uses a lot of custom content types and along with a lot of CCK fields. Now with each new hotfix/patch/amendment new content types and CCK fields are added. Once the new code is developed in DEV Server it is moved to another to test. Then again after testing it is moved to QA then to the Production.

But with the increasing Content Types and CCK fields we are finding very hard to manage all those in moving to server to server. So I googled and found http://www.lullabot.com/articles/moving-cck-field-changes-from-dev-to-live But the problem is, this tutorial is based on Drupal 5 and an older version of devel module packaged with macro module. Now a days, macro is a separate module and it is not working as expected, its giving a lot of errors and the available patches are not able to solve it.

So is there any way to track all the Content Type Addition or Changes and the New Field or Existing Field addition or changes?

It would be really helpful if any solution is provided. Thanks!

  • you can simply export/import content-types too, but below answer is good to go too.
    – Sohail
    Commented Feb 14, 2013 at 17:01

1 Answer 1


Take a look at the Features module. Exporting your CCK fields as a feature set creates a new module in which the fields are defined in code. You can then deploy the code to another server and enable the feature there. Every time you make a change you export the feature again to update its code, deploy it, then revert it on the other server.

Features is very useful, but takes some practice to get used to its limitations and quirks. Once you get past that point it'll save you a lot of time.

  • thanks, but the main problem is that I have to keep the fearures module enabled in the Production site as well. But I do not want to do that. Actually client is very choosy about the enabled modules. Also I created a content type then used Features module to import those in a test site. It worked. But the "Delete" Link from admin/content/types is gone. I suppose that all those are stored in code so any other way to deploy in the production's database? Commented Feb 14, 2013 at 17:28
  • As regards having Features enabled, yes, you will need it but the UI can be turned off when not required. Drush can be used for deployment. Obviously that may not be practical for you. Commented Feb 15, 2013 at 12:15
  • There are alternative approaches. I seem to remember there being another module that applied only the difference between a CCK export and the target database, though I cannot find it on Drupal.org now. None of the alternatives work as well as Features. There's probably some way of using Features to perform the import, ensuring it's all in the database, then turning Features off again. Essentially you want the configuration to be 'overridden' so it goes into the database. Commented Feb 15, 2013 at 13:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.