function hook_node_import_fields in Node import 6
Same name and namespace in other branches
- 5 docs/node_import_hook_docs.php \hook_node_import_fields()
List the available fields for given content type.
Use this hook to list the content fields that are available for given content type.
Parameters
$type: String. The content type as returned as a key by hook_node_import_types().
Return value
Array of ($fieldname => $fieldinfo).
\par Field name
$name is a unique identifier for the field. Normally you would use the same string as the form element.
\par Field information
$info is an array describing how the field should be handled by Node import. There are a lot of options, and probably you will not need them all. The more you can specify here, the less you have to do in hook_node_import_values_alter().
It can have following keys:
- \b "title" : Human readable name (required).
- \b "tips" : A list of short informative tips for the format of this field, similar to hook_filter_tips(). The different tips will be displayed as an itemized list.
Defaults to array().
- \b "group" : Human readable group name. May be used to group fields together such as "Publishing options" or "Revision information".
Defaults to ''.
- \b "module" : String. Module that added the field.
Defaults to ''.
- \b "weight" : Integer. Weight of the form elements.
Defaults to 0.
- \b "is_mappable" : Boolean. Whether the field can be mapped by the current user. Rather set this to FALSE then omitting the field altogether.
Defaults to TRUE.
- \b "map_required" : Boolean. Whether the field is required. For example the "title" field in supported/node.inc needs to be mapped for each row.
Defaults to FALSE.
- \b "input_format" : String. Modules may set this to a string describing the expected format for the input. Examples are 'user' (a uid), 'date', 'boolean', ... Other modules may add preprocessing functions based on this to the field definition.
Defaults to '' (empty string).
- \b "has_multiple" : Boolean. Whether the field can have multiple values. For example the multiple select vocabularies in supported/taxonomy.inc.
Node import will allow multiple file columns to be mapped to this field in this case and will present the user with a "Multiple values are separated by" option.
Defaults to FALSE.
- \b "multiple_separator" : String. There are two ways to specify multiple values for a field (think taxonomy terms or any CCK field that has multiple values):
-# either the user maps more than one file column to the same field, -# or he maps one file column and wants to split that with a separator.
By default Node import will present the user with an option to set the separator, but you may set a suggested separator here (such as "," for free tagging vocabularies instead of the default "||").
Defaults to variable_get('node_import:multiple_separator', '||').
- \b "is_checkboxes" : Boolean. If "has_multiple" is set to TRUE, this boolean says how to interpret the multiple values.
If TRUE, the array of multiple values will be converted to something a checkboxes form element understands: ($idx => $value) => ($value => 1). If FALSE this conversion is not made.
Defaults to FALSE.
- \b "has_hierarchy" : Boolean. Whether the field value is a hierarchy. Typical examples can be found in taxonomy or menu hierarchies.
Defaults to FALSE.
- \b "hierarchy_separator" : String. There are two ways to specify hierarchy values for a field:
-# either the user maps more than one file column to the same field,
-# or he maps one file column wants to split that with a separator.
By default Node import will present the user with an option to set the separator, but you may set a suggested separator here (such as "/" for path aliases instead of the default ">>").
Defaults to variable_get('node_import:hierarchy_separator', '>>').
- \b "hierarchy_reverse" : Boolean. If a hierarchical value is mapped to more than one file column (option 1 above), normally the order of hierarchy is "parent >> child" which means that the "parent" needs to be mapped to an earlier file column than the "child", eg:
parent, child
If this boolean is set to TRUE then this order is reversed and so a file like:
child, parent
will still be mapped to a "parent >> child" hierarchy.
Node import will allow the user to set this on the options page.
Defaults to FALSE.
- \b "allowed_values" : Array of ($key => $title) of the allowed values for the field. A mapped value from the file can either be $key or $title. If the mapped value is in the list, $key will be assigned as value for the field.
If set, the node_import_check_values() preprocessor will be automatically added to the preprocessor list.
Defaults to array().
- \b "allow_empty" : Boolean. Whether an empty value ('') is allowed for this field. If the mapped value is empty, normally node_import will not consider this as a valid value, but will rather use the default value in that case. If set to TRUE, a empty mapped value ('') will be used and not the default value.
Defaults to FALSE.
- \b "preprocess" : Array of callback functions. Each of the functions can preprocess the mapped value. This is a way to validate and preprocess the input. These preprocess functions can be used in companion with the hook_node_import_values_alter().
The signature of the callback is:
$return = $function(&$value, $field, $options, $preview);
and it should alter the $value passed. Note that if the field "has_hierachy", the value passed will be an array (grandparent, parent, child).
The $return value should be FALSE if there is an input error, NULL if there was not, but not a valid value could be found or TRUE if a valid value could be found and so other preprocess functions can be skipped.
See @ref node_import_preprocess for examples.
Defaults to array().
\par Multiple and hierarchical fields
When a field is both "has_multiple" and "has_hierarchy" the user can map multiple columns to the field, but if he does, the has_multiple will take precedence.
If the user maps the field to exactly one column, the expected format is:
"parent1 >> value1 || parent2 >> value2";
If the user maps the field to more than one column, it is expected that each column contains a value (which can be hierarchical), so:
"parent1 >> value1" , "parent2 >> value 2"
Related topics
34 functions implement hook_node_import_fields()
Note: this list is generated by pattern matching, so it may include some functions that are not actually implementations of this hook.
- asin_node_import_fields in supported/
amazon/ asin.inc - Implementation of hook_node_import_fields().
- book_node_import_fields in supported/
book.inc - Implementation of hook_node_import_fields().
- comment_node_import_fields in supported/
comment.inc - Implementation of hook_node_import_fields().
- content_taxonomy_node_import_fields in supported/
content_taxonomy/ content_taxonomy.inc - Implementation of hook_node_import_fields()
- date_node_import_fields in supported/
date/ date.inc - Implementation of hook_node_import_fields().
1 invocation of hook_node_import_fields()
- node_import_fields in ./
node_import.inc - Returns a list of available content fields for given node_import type.
File
- ./
node_import.api.php, line 298 - Explanation of the Node import hooks.
Code
function hook_node_import_fields($type) {
}