You are here

function hook_field_info

Along with this hook, you also need to implement other hooks. See
Field Types API for more information.

Return value

An array whose keys are field type names and whose values are arrays
describing the field type, with the following key/value pairs:

label: The human-readable name of the field type.

description: A short description for the field type.

settings: An array whose keys are the names of the settings available
for the field type, and whose values are the default values for those
settings.

instance_settings: An array whose keys are the names of the settings
available for instances of the field type, and whose values are the
default values for those settings. Instance-level settings can have
different values on each field instance, and thus allow greater
flexibility than field-level settings. It is recommended to put settings
at the instance level whenever possible. Notable exceptions: settings
acting on the schema definition, or settings that Views needs to use
across field instances (for example, the list of allowed values).

default_widget: The machine name of the default widget to be used by
instances of this field type, when no widget is specified in the
instance definition. This widget must be available whenever the field
type is available (i.e. provided by the field type module, or by a module
the field type module depends on).

default_formatter: The machine name of the default formatter to be used
by instances of this field type, when no formatter is specified in the
instance definition. This formatter must be available whenever the field
type is available (i.e. provided by the field type module, or by a module
the field type module depends on).

no_ui: (optional) A boolean specifying that users should not be allowed
to create fields and instances of this field type through the UI. Such
fields can only be created programmatically with field_create_field()
and field_create_instance(). Defaults to FALSE.

no, _field_info_collate_fields() takes care of adding empty 'settings' and 'instance_settings' arrays if they are left undefined in hook_field_info().
Same goes for hook_field_widget_info() and hook_field_formatter_info().

If you're having problems getting your fields to appear in the Fields UI screens, be sure you have a formatter and widget available to handle your custom field type. This is done in your hook_field_widget_info() and hook_field_formatter_info() implementations. If your field type is compatible with existing formatters or widgets you can use hook_field_formatter_info_alter() and
hook_field_widget_info_alter().

For a custom field that requires additional settings and view formatting the following list may be useful:
hook_field_info
hook_field_formatter_info
hook_field_formatter_info_alter
hook_field_widget_info
hook_field_widget_info_alter
hook_field_is_empty
hook_field_instance_settings_form
hook_field_formatter_info
hook_field_prepare_view
hook_field_formatter_prepare_view
hook_field_formatter_view

In many tutorials i read that this hook must be implemented in .module file , but looking inside the Image module in drupal core , I realized that this hook is Implemented in .inc file and then called using require_once function . So why is that ?

I'm no expert, but after looking around a bit I can't find any good reason for it.

'require_once' is rarely used in core modules, but a quick grep search shows that file.module use it in the same fashion. I think that it is simply to save some lines in the module file, but I'm not sure that it is the best practice.