By dman on

OK, so in Drupal 4 and Drupal 5 days, the docs and examples, and many of the contrib modules used to just create their own DB table, add one or two extra fields to a node type via nodeapi and stuff, and do the loading and saving themselves.

Now everyone is using CCK for most things. Adding a field to a node type can be done easily - in the UI.
But we still have modules doing it the old way, and
node_example is now a learning exercise ... but hardly best-practice any more!
Current docs Create new content-type for Drupal 6.x don't include this idea.

So I want to make a module that provides a content type, that has a few extra text fields which I'll treat specially, but don't really want to do all the database stuff again when CCK is sitting there. I could set it up by hand+CCK, but I need to do it in code.
By hitching myself to the CCK bandwagon, then post-install the fields can be tweaked, and used in views etc without providing a whole layer of CCK-like emulation.

So what is the best way to approach this?

  • Distribute a content definition config file and invoke it on install?
  • Mess through the available CRUD to create a content type definition programatically?
  • Reverse-engineer CCK enough to call its internals to get what I want?

I see convergence in the future - "If you want to create a module that provides a custom type with extra fields, use this API to set it up, not your own DB queries"
But is that convergence here now?
Anyone got examples of a best-practice integration of a module that leverages CCK to do that stuff?

⋅ Categories: Drupal 6.x

Comments

Dublin Drupaller’s picture

Dublin Drupaller commented

hi Dman,

I was looking at something similar recently. Can I point you at the following links which might offer some help?

Programatic CCK Now Possible! - I just wanted to point out a very important change to content_copy.module that makes it much more fasible to create CCK field programatically as part of an install profile.

Features.module - The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case. Here's a quick overview and some video demos

Patterns.module Patterns module is built to bypass this bottleneck by managing and automating site configuration. Site configuration is stored in XML or YAML* files called Patterns which are easy to read, modify, manage, & share and can be executed manually or as a part of an automated web site deployment.

Based on your post, I think the features.module might satisfy your needs, without having to get into coding...as an example..when you "export" a feature using the features.module, the export includes a .module, .install and the other necessary files to set the same cck content type on another drupal site. Check out the video demos to see how it works from the UI perspective. It's a relatively new module...and very interesting for the sort of thing you're trying to do.

dub

Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate

dman’s picture

dman commented

Sounds about right.
Yes, over the last few days I've been trying to develop with "Patterns" (good theory, but YAML is ... well exactly what it calls itself) and over the last few hours since this post did take CCK apart enough to find its CRUD layer. It's possible (only took me two pages of code) but i'm not sure it's ready for public use yet.

I'm looking at 'Features' now - I'm not sure it's the right answer. My custom module isn't JUST about setting up a CCK content type, it's more than just a recipe. It does stuff too, but I thought I could enlist CCK for the boring bits, use it as a library of data storage routines and let me get on with the value-add.

I think I've got it - seems to work for me in a few tests. I'm just not sure it will continue to work...

FYI, code (in development) below.

Background: druplet.module provides an (old-style) custom content type. A node that represents admin info about a drupal subsite.
I want to add some more fields to that node type, and use those fields in my own extension module 'wrapper_proxy.module'.
But I don't want to do it by adding yet another column to the druplet table and dealing with get/set/theme/validate/view/filter adjustments for my new fields. That's a solved problem now.
So I use get my module to get CCK to add the fields to the druplet node definition for me: as follows:

/**
 * The druplet module may require additional fields (the original URL) added as
 * a CCK field so we can store required data there,
 */
function wrapper_proxy_setup_druplet() {
  $type_name = 'druplet';
  $node_types = node_get_types();
  if (empty($node_types[$type_name])) {
    drupal_set_message("Druplet module is required for wrapper to create its own subsites", 'error');
    return FALSE;
  }
  $node_type_def = $node_types[$type_name];
  $content_type_def = content_types($type_name);

  $field_definitions = wrapper_proxy_druplet_additional_fields();
  // Use CRUD to create the field definitions if needed
  module_load_include('inc', 'content', 'includes/content.crud');

  foreach ($field_definitions as $field) {
    if (empty($content_type_def['fields'][$field['field_name']])) {
      drupal_set_message("No {$field['field_name']} on the druplet node. Adding it now.", 'warning');
      $field['type_name'] = $type_name;
      // Invoke the cck CRUD to add the field definition
      $field = content_field_instance_create($field);
    }
  }

  return TRUE;
}

/**
 * This is a content_import-like macro, the details that need to be submitted to
 * add a field to a content type.
 * 
 * Remember to add the type_name of the containing definition to this
 * array before submitting it.
 * 
 * Many options that looked like defaults have been trimmed from here.
 * See a content_export dump to compare with the full list of attributes that
 * may be here.
 */
function wrapper_proxy_druplet_additional_fields() {
  return array(
    array(
      'label' => 'Source',
      'field_name' => 'field_url_source',
      'type' => 'text',
      'widget_type' => 'text_textfield',
      'weight' => '1',
      'description' => 'Original location of the content',
      'op' => 'Save field settings',
      'module' => 'text',
      'widget_module' => 'text',
    ),
    array(
      'label' => 'Drupal User',
      'field_name' => 'field_drupal_user',
      'type' => 'text',
      'widget_type' => 'text_textfield',
      'weight' => '1',
      'description' => 'Admin Username on this druplet site',
      'module' => 'text',
    ),    
  );
}

I figured the layout of a field def by inspecting the output of CCK content_export.
Then I erased bits that looked boring.
The meat is of course this line:

      $field = content_field_instance_create($field);

I think I've got a way forward.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Since D5, Advanced Profile Kit has done this by programatically invoking content copy with this code:

/**
 * Helper function to import a CCK content type definition from a text file.
 *
 * @param $cck_definition_file
 *   The full path to the file containing the CCK definition.
 */
function _create_content_type($cck_definition_file) {
  include_once('./'. drupal_get_path('module', 'node') .'/content_types.inc');
  include_once('./'. drupal_get_path('module', 'content') .'/includes/content.admin.inc');
  $values = array();
  $values['type_name'] = '<create>';
  $values['macro'] = file_get_contents($cck_definition_file);

  $form_state = array();
  $form_state['values'] = $values;
  drupal_execute("content_copy_import_form", $form_state);
  content_clear_type_cache();  
}

I didn't write it but it works fairly well. The biggest problem with it is sometimes CC simply doesn't work and this fails silently. Then users come to my queue saying it doesn't work. So I'm interested in better solutions. :)

Michelle

dman’s picture

dman commented

I've also done code that looks almost the same as that - in my own install profile scripts.
But this is why I'm looking for a more elegant solution.
Programatically pasting PHP code into virtual web submission form, then simulating submitting it? EEk.

But yes, it does work :-/
I'm doing the same for views!

.dan. is the New Zealand Drupal Developer working on Government Web Standards

Phillip Mc’s picture

Phillip Mc commented

Hi Michelle,

thanks for posting that. very useful.

sorry if this is a dumb question, but, can I put that in a module - so when you install the module, all it does is create the content type? or does it have to go into an install profile?

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

It's part of a module, yes, but doesn't run on install. I don't know what it would take to do that. It's an option in settings of Advanced Profile Kit.

Michelle