Support field hierarchies

fieldgroup_groups() provides this pretty well by itself. However not just fieldgroup, but other modules provide fields in hierarchies. eg. A Link field can be seen as a fieldgroup with URL, Title, etc. Maybe we need a new hook so that all these modules can return information about how the "flattened" field names fit into the overall field hierarchy.

Think the way to deal with this is to introduce the concept of "grouping fields". Any field can be a parent of other fields. We'll need a new hook so that plugins can declare which fields are children of a field. Also need a new function like fieldtool_get_tree($content_type, $depth) which would give us the same sort of structure you'd get from the node edit form.

Probably also best to establish conventions for field names. For anything other than standard fields for an entity (handled by node_standard.inc, user_standard.inc, etc.) the convention should be module_name_field_name_subfield_name_sub-subfield_name (CCK/D7 fields are already prefixed with 'field_' so we'll stick to that). This should hopefully deal with namespace collisions.

To illustrate, in the case of fieldtool_fields() might return something like:

array(
  // [...] (other fields)
  'field_phone' => array(
    'cck field type' = 'text',
    // [...] (usual stuff)
    'weight' => 1,
  ),
  'field_link' => array(
    'cck field type' = 'link',
    // [...] (usual stuff)
    'fields' => array(
      'field_link_url',
      'field_link_title',
      'field_link_attributes',
    ),
    'weight' => 0,
  'field_link_url' => array([...]),
  'field_link_title' => array([...]),
  'field_link_attributes' => array([...]),
  'field_contact' => array(
    'cck field type' = 'fieldgroup',
    // [...] (usual stuff)
    'fields' => array(
      'field_link',
      'field_phone',
    ),
  ),
)

... and fieldtool_get_tree() might return something like:

array(
  // [...] (other fields)
  'field_contact' => array(
    'cck field type' = 'fieldgroup',
    // [...] (usual stuff)
    'fields' => array(
      'field_link' => array(
        'cck field type' = 'link',
        // [...] (usual stuff)
        'fields' => array(
          'field_link_url' => array([...]),
          'field_link_title' => array([...]),
          'field_link_attributes' => array([...]),
        ),
        'weight' => 0,
      'field_phone' => array(
        'cck field type' = 'text',
        // [...] (usual stuff)
        'weight' => 1,
      ),
    ),
  ),
)

So here you can still just pass the import callback of 'field_link' a string and it will assume it's a URL and pass it on to the import callback of 'field_link_url'. CCK Fieldgroup fields would be just like any other fields, only without getter/setter/import/export callbacks.

Didn't require a new hook at all. Plugin developers just have to add an array of child field names to the array returned by hook_[plugin]_fieldtool_fields(). This doesn't affect existing functionality at all, just adds a new fieldtool_tree() function which returns an array as suggested above.

Seems to work with the attached fieldgroup plugin. Will commit both when I've modified relevant existing plugins (location, link, taxonomy, etc.) to work like this. In the meantime testing appreciated.

Whoops, should have changed status.

Fixed another glitch where function fieldtool_export() wanted a $value argument. Copy and paste error by the looks of it; fieldtool_import() has that argument in the same place. I know it's bad form not to raise a separate issue, but let's be honest - who's reading this, anyway?

Will create separate issues for support for this in various plugins. Wanted this committed, as I've now got support for this in the taxonomy plugin I'm about to commit (#649848: Support taxonomy (not content_taxonomy) fields).