UPDATE 02/12/2009: this patch is out of the date, please refer to the Alternate Content Copy module now.
A few days ago I wrote a HowTo for creating CCK Content Types programmatically, including their update. Unfortunately, I must have missed something in my tests, so I found out later on that the updates won’t work properly.
This is due to the behaviour of the CCK import procedure, that skips already existing fields, so these don’t get updated. Plus, it also keeps fields no longer available in the updated content type definition, i.e. you cannot drop fields either.
I submitted a patch to the content_copy module, which turned up to be kind of a duplicate. Now the discussion is going on here, and my latest comment (including my patch) is here.
At the moment, Markus does not seem keen to include this patch, or any similar one, at all. We’ll see what happens.
In the meantime, I am using an alternative approach, because I don’t like to have patched modules in my installations. Basically I wrote a module called custom_content_copy that implements an alternative submit handler for the Content Copy import form. This way, you just need to install this module alongside of the content_copy module provided by CCK.
If you want, you can download this module here:
Custom Content Copy. Please refer to the Alternate Content Copy module now.
I agree, a hook hijacking module is a solid solution if you have multiple installations to cover.
However, I don’t consider having patches around bad /per se/. If you use some automation like quilt to manage patches, then patching modules, or even drupal core, becomes quite sustainable.