A few days ago, I have announced the Alternate Content Copy module, which hopefully is going to be accepted on the Drupal.org project repository (as soon as I submit it).
In that article I explained the general reasons why those modifications should be part of the official Content Copy module.
Now, I do realise that Fields in D7 might be so different that everything I am about to say could not make any sense in the near future. However, I would like, with this article, to explain why the programmatic update of CCK content types does benefit of my modifications.
Programmatic CCK content types update: Markus’ way
In another post I explained how to get programmatic CCK content types done, including a programmatic update. My way of doing this last bit only works if the Alternate Content Copy module is used.
Markus_petrus claims that my way is not the safest and the correct one to go about that. Instead, in the
hook_update_N() the CCK CRUD APIs should be used there where the Schema APIs would be used for regular Drupal content types.
Basically, the procedure suggested my markus_pretrus can be summarised as follow:
- Update the content type using the UI to reconfigure the structure and export the new definition to code (the
.def.incfile in my example);
- Write a new
hook_update_Nusing CCK CRUD API to resemble the new definition.
At this point both a fresh install of the module or an update of it should take us to the same version of the content type.
This is fine and it resembles exactly what one would be doing for a regular content type:
- Update the content type schema within the
- Write a new
hook_update_Nto resemble the changes made to the schema definition at the previous point;
My way: less error prone
By using my solution to implement CCK content types update, we can improve things in two ways.
Firstly, we make the updates less error prone, as both the
hook_install and the various
hook_update_N would be relying on the same content type definition, and there is no way the update procedure and the installation procedure could end up with a different result. There is no CRUD API (directly) involved, so no human error can occur while writing them into the
hook_update_N that could make an update be different from a fresh installation.
Secondly, we make the job easier for the developers, because everything they need to do is to export the new definition to code and then add a new
hook_update_N that will have a standard format, i.e. all the
hook_udpate_Ns will look the same.
CRUD APIs vs Alternative Content Copy. Really?
I have been writing this article so far because of a supposed divergence of opinions about how to implement CCK content types updates programmatically. Well, whether you believe it or not, that is all an imagination.
My modifications to the import procedure you can find in the Alternate Content Copy module make exactly use of CCK CRUD APIs. Also, I have been comparing my solution to the CCK_sync module. At the end of the day, we do exactly the same thing, but the latter has been referred to as one possible way to go for those who require a proper update of the whole content type.
The only real difference between CCK_sync and Alternate Content Copy is that the former provides the functionality as alternative functions to be called via code and/or a separate interface for “synchronising” the content types via UI. My solution, instead, alters the already existing functions and APIs, integrating into CCK seamlessly.
I still believe my approach is all right and I would dare to say even suggested, as the import procedure of CCK Content Copy should provide a way to perform a complete update of a content type, that is erroneously called synchronisation by the CCK_sync module.
Nevertheless, my full update functionality is provided on top of the already existing functionalities in Content Copy, which means you will still be able to create a brand new content type (of course) and also to import just new fields in a pre-existing content type.