One of my first tasks in building the Boston Review's new OpenPublish site was adding some custom fields to the Article type in OP 2.0. But when I upgraded to OpenPublish 2.1 I ended up having to start from the stock Article type in 2.1 and re-add the extra fields.
So what is the best way to add some CCK fields to the stock OpenPublish article type in a way that is upgradeable?
The obvious thing to me as a Drupal developer is simply adding the fields with CCK, but the Features module does not recognize that the Article feature is then in the state "overridden" (see http://drupal.org/node/401948). And the standard CCK export and import functionality doesn't work right for this task.
The end of that discussion on d.o node 40198 refers to the Content Type Exporter module at http://drupal.org/project/content_type_exporter. Does that module solve the problem?
Thanks all,
Steve Cronen-Townsend
Comments
I am afraid neither CCK nor
I am afraid neither CCK nor Ctools/Features provide anything, at this point, that fully automates the scenario described by you.
.............................................
http://twitter.com/inadarei
An Important Capability
My $0.02 are that this is a very important capability since the temptation to add custom fields will be hard to resist. Or, perhaps, this is a capability that will come with D7, which incorporates CCK into core.
HAJ
IMO the proper upgrade should have
IMO the proper upgrade should have two components to it:
1) application server upgrade part - folders and files only new to the previous OP version of code; changes to the existing files should be done using kind of module's patch mechanism.
2) database upgrade part - this just to add new and modify some existing tables in order to support new functionality and bugs removing.
This way none of the added custom fields/modules/settings will be changed/removed.
Also this two parts should have version control component to protect database from changes by wrong application version: application server should check version of the database (field in the table) to know if it's safe for it to work with that database (range of the safe versions is hard coded in application). If not - error message, that the application will not work with this database version.
Also all customization should be done the way that it is addition code that overrides OP code like custom subtheme overrides OP theme.
Does all this make sense to you guys? I'm sure it will require much more time to package upgrade this way, but will be much less headache for OP users to upgrade.
Thank you,
Gennady
How content types and upgrades should work
@irakli: How do you think this should work? I may be able to do some development around this, so how do you think I should direct my efforts? How does the impending switch of OP to D7 effect this?
Thanks!