Field Attach API
- cis7 modules/field/field.attach.inc field_attach
- cle7 modules/field/field.attach.inc field_attach
- elmsmedia7 modules/field/field.attach.inc field_attach
- icor7 modules/field/field.attach.inc field_attach
- meedjum_blog7 modules/field/field.attach.inc field_attach
- mooc7 modules/field/field.attach.inc field_attach
Operate on Field API data attached to Drupal entities.
Field Attach API functions load, store, display, generate Field API structures, and perform a variety of other functions for field data attached to individual entities.
Field Attach API functions generally take $entity_type and $entity arguments along with additional function-specific arguments. $entity_type is the type of the fieldable entity, such as 'node' or 'user', and $entity is the entity itself.
hook_entity_info() is the central place for entity types to define if and how Field API should operate on their entity objects. Notably, the 'fieldable' property needs to be set to TRUE.
The Field Attach API uses the concept of bundles: the set of fields for a given entity is defined on a per-bundle basis. The collection of bundles for an entity type is defined its hook_entity_info() implementation. For instance, node_entity_info() exposes each node type as its own bundle. This means that the set of fields of a node is determined by the node type. The Field API reads the bundle name for a given entity from a particular property of the entity object, and hook_entity_info() defines which property to use. For instance, node_entity_info() specifies:
$info['entity keys']['bundle'] = 'type'
This indicates that for a particular node object, the bundle name can be found in $node->type. This property can be omitted if the entity type only exposes a single bundle (all entities of this type have the same collection of fields). This is the case for the 'user' entity type.
Most Field Attach API functions define a corresponding hook function that allows any module to act on Field Attach operations for any entity after the operation is complete, and access or modify all the field, form, or display data for that entity and operation. For example, field_attach_view() invokes hook_field_attach_view_alter(). These all-module hooks are distinct from those of the Field Types API, such as hook_field_load(), that are only invoked for the module that defines a specific field type.
field_attach_load(), field_attach_insert(), and field_attach_update() also define pre-operation hooks, e.g. hook_field_attach_pre_load(). These hooks run before the corresponding Field Storage API and Field Type API operations. They allow modules to define additional storage locations (e.g. denormalizing, mirroring) for field data on a per-field basis. They also allow modules to take over field storage completely by instructing other implementations of the same hook and the Field Storage API itself not to operate on specified fields.
The pre-operation hooks do not make the Field Storage API irrelevant. The Field Storage API is essentially the "fallback mechanism" for any fields that aren't being intercepted explicitly by pre-operation hooks.
Field Language API provides information about the structure of field objects.
See Field API for information about the other parts of the Field API.
||Notify field.module that a new bundle was created.|
||Delete field data for an existing entity. This deletes all revisions of field data for the entity.|
||Notify field.module the a bundle was deleted.|
||Delete field data for a single revision of an existing entity. The passed entity must have a revision id attribute.|
||Add form elements for all fields for an entity to a form structure.|
||Perform field validation against form-submitted field values.|
||Save field data for a new entity.|
||Loads fields for the current revisions of a group of entities.|
||Load all fields for previous versions of a group of entities.|
||Prepares an entity for translation.|
||Prepare field data prior to display.|
||Populate the template variables with the field values available for rendering.|
||Perform necessary operations just before fields data get saved.|
||Notify field.module that a bundle was renamed.|
||Perform necessary operations on field data submitted by a form.|
||Save field data for an existing entity.|
||Perform field validation against the field data in an entity.|
||Returns a renderable array for the fields on an entity.|
||Act on field_attach_create_bundle().|
||Act on field_attach_delete().|
||Act on field_attach_delete_bundle.|
||Act on field_attach_delete_revision().|
||Act on field_attach_form().|
||Act on field_attach_insert().|
||Act on field_attach_load().|
||Perform alterations on field_attach_prepare_translation().|
||Alter field_attach_preprocess() variables.|
||Act on field_attach_presave().|
||Act on field_purge_data().|
||Act on field_attach_rename_bundle().|
||Act on field_attach_submit().|
||Act on field_attach_update().|
||Act on field_attach_validate().|
||Perform alterations on field_attach_view() or field_view_field().|
||Alter field_available_languages() values.|
||Perform alterations on field_language() values.|
||Invoke a field hook.|
||Invoke field.module's version of a field hook.|
||Helper for _field_invoke(): retrieves a list of instances to operate on.|
||Invoke a field hook across fields on multiple entities.|
||Invoke field.module's version of a field hook on multiple entities.|
field/ field.attach.inc, line 71
- Field attach API, allowing entities (nodes, users, ...) to be 'fieldable'.