Attached patch adds full support for the Import / Export API to CCK. The patch makes the CCK module implement the i/e API's hook_def() and hook_db_def_tables(). It also defines a new hook specific to CCK, called hook_content_def_references(), to allow proper referencing support from the userreference and nodereference field types in the i/e API.

This stuff is currently in the importexportapi package, in the 'definitions/contrib/cck' directory. This patch is identical to what's in there at the moment. If and when this patch gets committed to CCK, I will remove CCK support from the importexportapi package.

To test this patch, you will need to rename or delete the CCK files in the importexportapi package. Note that this patch has been generated against the 4.7 branch of CCK. I have no problem with it getting committed to CCK HEAD as well, but please be aware that the i/e API currently only supports 4.7.

CommentFileSizeAuthor
cck_importexportapi.patch12.9 KBJaza

Comments

dkruglyak’s picture

dkruglyak commented

Has anybody tested this? Looks like the patch is not in sync with the latest 4.7...

karens’s picture

karens commented

Jaza, do you have time to get this patch current? I have been getting questions about porting info into CCK and I think the import/export module is going to be the best way to do it, so it would be good to have the necessary integration working.

Jaza’s picture

Jaza commented

@KarenS: if you need the integration now, all the CCK definitions are already included with the importexportapi module. This patch is simply to take those definitions out of importexportapi, and to put them into CCK itself. I will be updating this patch soon, when I get a chance.

yched’s picture

yched commented

I'm not familiar (yet) with the Import / Export API.
Is there a way to avoid loading / parsing the .inc files on each page - they are likely to be actually required only once in a while, am I right ? (this differs from Views or pathauto stuff)
Maybe have the hook functions in the .module file, and let them include the right .inc and call the right helper function ?

karens’s picture

karens commented

I agree with yched on .inc vs hooks. That's a big file to drag around if it isn't needed most of the time. Also, would it make sense for the .inc file to remain in import/export instead, since that's the module that needs to maintain it if changes are needed in the future.

We could maybe just add hooks where needed and make that the only actual change in cck and you leave the .inc file in the import/export module. Plus it may be that other modules will need hooks in the future, so it might be nice to have generic hooks that could be used in other ways.

karens’s picture

karens commented

Jaza, where is the module project page located? The import-export module that shows up on the downloads page looks like something very old and hasn't been recently updated, so I don't think I'm finding the right one.

dkruglyak’s picture

dkruglyak commented

I might have filed a duplicate that includes a link to what seems to be this module: http://drupal.org/node/98287

+1 on getting this integrated. I am wrestling with how to migrate a complex CCK content model into production system and this seems to be the answer (if it works).

yched’s picture

yched commented

dkruglyak : what do you +1 exactly ?
The question here is not to know if the 'import / export API' module should provide the feature - it does.
The question is to know whether the definition files should be shipped with CCK - and how -, or stay in the import/export module, where they currently are.
Please don't cast an unconsidered vote, it just adds confusion.

dkruglyak’s picture

dkruglyak commented

The vote is on making sure this feature is continously supported and updated. This is one of those things that risks "failling through the cracks" of two module development efforts - especially since CCK module is still evolving.

I am testing the current importexportapi module right now. So far was able to export and import content definitions (4 types & 26 fields), but data export fails (out of memory), even on a simple content type with only two records. Even content type / field def transfer may need more extensive testing to see if there are any problems.

Probably this should be maintained within CCK, to keep up with changes. I updated the handbook page for what is working now: http://drupal.org/node/98432

Thanks to all for your help.

dkruglyak’s picture

dkruglyak commented
Status: Needs review » Needs work

Found a bug.

When CCK types are imported the field/type mappings are not set correctly. In field_instance table, type_name column is not being filled. Plus the fields that exist in multiple content types only show up in instance table once.

dkruglyak’s picture

dkruglyak commented

One more problem.

The import does not create node_content_X & node_data_field_X tables, rendering itself useless.

Looks like one more vote for moving import / export support into CCK proper.

karens’s picture

karens commented

But I got inspired by moshe's macro module (see http://drupal.org/node/98895) to find a way to get a decent import/export capability into CCK. I don't want to pollute this issue, which is about the Import/ExportAPI, so I put it in another issue at http://drupal.org/node/99446.

karens’s picture

karens commented
Status: Needs work » Closed (won't fix)

I see that Jaza has posted that he's looking for a new maintainer of this module since he doesn't have time to maintain it, so I'm going to close this issue. If someone else takes over the module and wants something done, they can open a new issue.

In the meantime, if anyone is interested in importing into CCK fields, I posted a patch for the node_import module and it seems to be working except for some problems with multiple value fields. See http://drupal.org/node/105982 for my patch.