Hello,

As a module developer, it would be very handy for me to be able to define a few fields in CCK, combine them with pre-existing fields from CCK and distribute the resulting node. Moreover, I would like to be able to act on that node, just as if I defined all the hook_view, hook_load, etc functions.

As a first step, I would suggest porting the views module code to import and export views to CCK, so that we can package the CCK created content types.

The next step is providing a hook that modules can implement to expose default CCK based types (like views does with 'default views').

Finally, when loading/viewing/editing a default CCK type, the implementing module should be allowed act on the event - optionally ignoring the usual sequence of events.

Can you suggest a process to this feature? I am happy to help, but I am still sketchy on the differences between fields and widgets, and exactly what would need to be included in the "serialized" CCK object(s).

CommentFileSizeAuthor
#4 exporting.20060523.patch2.09 KBmfredrickson
#2 cck.importexport.0.patch11.07 KBmfredrickson
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dado’s picture

dado CreditAttribution: dado commented

+1 this sounds useful for my needs as well, to add CCK fields to any non-CCK node type
http://drupal.org/node/58269

mfredrickson’s picture

mfredrickson CreditAttribution: mfredrickson commented
Status: Active » Needs work
FileSize
cck.importexport.0.patch11.07 KB

Here is my first stab at exporting and importing CCK objects. it is very rough.

Here is how it works:

  1. To export, the content object is serialized and outputted to the screen
  2. To import, the text is put into a text area. User clicks submit.
  3. The object is unserialized and validated to make sure that the content type does not already exist, and that the necessary modules are installed.
  4. The object is mangled to look like a form submission and _content_admin_type_edit_submit is called.
  5. For each field, it checks to see if a similarly named field exists. If not, it adds a new one.
  6. Then it adds the existing field to the content type.

Right now, this is pretty hackish. Since there aren't any useful functions to save data (only the form submission forms) I've had to mangle the input data to look like a form. This works ok for some things, and not very well for others. Specifically, handling field submission is tricky - especially in setting the widget settings. I'm still not sure exactly how to structure this process.

It would help me greatly if there were programmatic ways (not just form submission methods) to content types and (more importantly) fields. This would require significant refactoring of the code in content_admin.inc.

I thought I should get this under some eyes before I get much further.

-Mark

oscnet’s picture

oscnet CreditAttribution: oscnet commented

+1 this is very useful for my needs as well.

mfredrickson’s picture

mfredrickson CreditAttribution: mfredrickson commented
FileSize
exporting.20060523.patch2.09 KB

Hmm. Not a lot of interest in this lately. I'm going to update the patches to the current version of CCK. I'm also breaking them into smaller, more digestible parts.

This one just does exports. Instead of serializing it uses PHP's var_export() function. Much easier to read and manipulate.

Next, I'll have patches to do imports.

(NB: This patch also includes the patch to http://drupal.org/node/64905 -- I was lazy and didn't clear this out)

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

I think there's plenty of interest in this - I know I have plenty of interest.

@mfredrickson - can you comment on the status of your last patch? I imagine it has some problems, but is it evern worthy of testing?

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

Well, now that I've actually looked at it it appears that the patch from 0523 got cut off somehow and is only the first few lines of the full patch.

@mfredrickson - do you have the rest of it somewhere?

mfredrickson’s picture

mfredrickson CreditAttribution: mfredrickson commented

My patches are against

// $Id: content.module,v 1.64 2006/06/12 19:36:54 JonBob Exp $

If you want it I'll tar it up or create a patch.

I doubt it would apply cleanly. Frankly, it was never great code. CCK is really, really complicated. I think I might wait or work on simple CCK like addons to core. Perhaps even writing some database level code to do what CCK does at the PHP layer.

-Mark

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

programmatic form submission is in core now so maybe this approach merits another look? i know i want this badly too.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Title: Port views import/export and default views to CCK (plus add module call backs) » Move content types between Drupal installations (plus add module call backs)

lets try a simpler title

yched’s picture

yched CreditAttribution: yched commented
Title: Move content types between Drupal installations (plus add module call backs) » Content types Import / Export (+ hook for module-defined types)

Yes, I want go forward on this too.

I was not thinking of programmatic form submission, though, but rather of types / fields / instances API.
content_crud.api has all the functions that should be required, except... most of them are empty placeholders ATM. JonBob has not finished moving the code from content_admin, I don't know if he has plans on this. I sort of started looking at it, but this is really hardcore - and quite central, of course... Plus this might be outside of my prerogatives. So for now I gave it a rest.

Right now the API only has delete functions - that is, exactly those we don't need for this :-)

The programmatic form path would probably deliver the feature faster, but I think the API path would be cleaner - and the API job will have to be done one day or the other anyway.

Side note : if that's OK with you, I set the title back to the notion of 'import / export', which I think is more general.

yched’s picture

yched CreditAttribution: yched commented
Status: Needs work » Active

removing the 'patch' status, since mfredrickson's patch is more a 'first try', as he says himself.

yched’s picture

yched CreditAttribution: yched commented

side note :
dkruglyak added a placeholder handbook page for explanations on how to move content type settings from one install to another, in the absence of the import / export feature.
http://drupal.org/node/98432 - it's still empty, waiting for contributions.

yched’s picture

yched CreditAttribution: yched commented
Status: Active » Closed (duplicate)

Karen has gone for the import / export feature : http://drupal.org/node/99446.
I'm marking this as a duplicate - the module hook question will come later.