Posted by rubymuse on January 26, 2008 at 5:45am
Jump to:
| Project: | Install Profile API |
| Version: | 6.x-2.x-dev |
| Component: | CRUD functions and includes |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
The Profile Wizard currently generates statements to create node types. It would be great if it could also generate statements to create CCK custom field types.
Comments
#1
A little birdie told me that some major overhauls are in the works. Keep your ears open for the beginning of March.
#2
Looks like dmitri has gotten bored by the current version of install profiles :P
It looks like Sacha Chua has figured this out, we need to add it to crud.inc before enabling in Profile Wizard. See http://sachachua.com/wp/2008/06/12/programmatically-creating-cck-nodes-i... for discussion.
#3
This is a function I built after reading Sacha's blog post and the one on Civic Actions she refers to. It takes an array as exported by content_copy and creates a new content type from it.
function install_content_copy_create($content) {include_once drupal_get_path('module', 'node') .'/content_types.inc';
include_once drupal_get_path('module', 'content') .'/content_admin.inc';
$macro = '$content[type] = '. var_export($content['type'], TRUE) .';';
if (isset($content['fields'])) {
$macro .= '$content[fields] = '. var_export($content['fields'], TRUE) .';';
}
drupal_execute('content_copy_import_form', array('type_name' => '<create>', 'macro' => $macro));
content_clear_type_cache();
}
Using it on the second installation profile today. Works fine so far. Could use a if (module_exists('content_copy')) {} for better error handling. Does not support tacking on fields to existing content types - thought it wasn't necessary for building from scratch, I might be wrong though.
Will report back how it goes.
#4
After some more work we came across a good use case for adding fields to existing content types: adding fields to content types defined by modules such as blog module. Here is the updated function we're using:
/*** @param array $content
* associative array as exported by content_copy module.
* @param string $type_name
* If given updates an existing content type rather than creating a new one.
*/
function install_content_copy_save($content, $type_name = NULL) {
if (!module_exists('content_copy')) {
drupal_set_message(t('install_content_copy_save() requires content_copy module (part of CCK).'), 'error');
}
include_once drupal_get_path('module', 'node') .'/content_types.inc';
include_once drupal_get_path('module', 'content') .'/content_admin.inc';
if ($type_name) {
// When updating, content_copy form does not update type information
// of content type, it only adds new fields (updates existing fields?).
// save content type information seperately.
$type = (object) _node_type_set_defaults($content['type']);
node_type_save($type);
}
else {
$type_name = '<create>';
}
$macro = '$content[type] = '. var_export($content['type'], TRUE) .';';
if (isset($content['fields'])) {
$macro .= '$content[fields] = '. var_export($content['fields'], TRUE) .';';
}
drupal_execute('content_copy_import_form', array('type_name' => $type_name, 'macro' => $macro));
content_clear_type_cache();
}
I can roll this into a patch if interested.
#5
Changing this to newest branch. Should go into content.inc file in contrib folder. Please do roll a patch if it makes sense here.
The use case definitely makes sense for any module that creates node types.
#6
I referenced this issue here: #72509: Expose a "Save content type" action.
#7
I believe this is resolved with the
contrib/content_copy.inc. Re-open if I'm missing something.