1

I see that there is an ImageType field, machine name 'image', with a namespace of Drupal\image\Plugin\Field\FieldType. However, I can't seem to make use of it when creating a custom field and defining the property in the FieldType class.

I tried putting DataDefinition::create('image') but this later causes an abort complaining about the field type not existing, and I notice that the namespace is not referenced.

What are the correct types to use for an image field in the property section of the FieldType, in the schema of the FieldType, and in the FieldWidget?

Exporting an image field config from a bundle yields:
uuid: eecbe6e5-89d5-4708-b9c9-79f77b3cedf8
langcode: en
status: true
dependencies:
  module:
    - file
    - image
    - node
_core:
  default_config_hash: SkXIPKZYiIMMtnBmfnxk58RYfbZ8cHSw5NZPY_JByME
id: node.field_image
field_name: field_image
entity_type: node
type: image
settings:
  uri_scheme: public
  default_image:
    uuid: null
    alt: ''
    title: ''
    width: null
    height: null
  target_type: file
  display_field: false
  display_default: false
module: image
locked: false
cardinality: 1
translatable: true
indexes:
  target_id:
    - target_id
persist_with_no_fields: false
custom_storage: false

and looking at the image module's fielditem:

 * @FieldType(
 *   id = "image",
 *   label = @Translation("Image"),
 *   description = @Translation("This field stores the ID of an image file as an integer value."),
 *   category = @Translation("Reference"),
 *   default_widget = "image_image",
 *   default_formatter = "image",
 *   column_groups = {
 *     "file" = {
 *       "label" = @Translation("File"),
 *       "columns" = {
 *         "target_id", "width", "height"
 *       },
 *       "require_all_groups_for_translation" = TRUE
 *     },
 *     "alt" = {
 *       "label" = @Translation("Alt"),
 *       "translatable" = TRUE
 *     },
 *     "title" = {
 *       "label" = @Translation("Title"),
 *       "translatable" = TRUE
 *     },
 *   },
 *   list_class = "\Drupal\file\Plugin\Field\FieldType\FileFieldItemList",
 *   constraints = {"ReferenceAccess" = {}, "FileValidation" = {}}
 * )
 */
8
  • The image field type has no property image, the main property is target_id inherited from the file field type. The easiest way to define a custom image field would be to extend the three core image field classes another time, now in the namespace of your module.
    – 4uk4
    May 29, 2018 at 19:22
  • That confuses me. I was meaning that I was adding the image field type as a property (sub-field) to my compound field. I've added, above, the image field's annotation in the image module, and the export of the article bundle's image field, and both refer to field type 'image'.
    – JAyenGreen
    May 29, 2018 at 20:43
  • As far as I know there are no sub-fields in Drupal. See how ImageItem defines a new compound field by extending FileItem overriding propertyDefinitions() unsetting two properties and adding four new image specific properties.
    – 4uk4
    May 29, 2018 at 20:55
  • To clarify, each of the properties in a compound field are sometimes referred to as sub fields, which was my meaning. Looking into your suggestion...
    – JAyenGreen
    May 30, 2018 at 2:35
  • So as a standalone, i.e. if I wanted to create a new field based on the image field, I can see extending FileItem or ImageItem. But what if I need the equivalent (or exactly) the ImageItem compound field to be part of a compound field? i.e. the compound field will include an image? Is that possible given there is no multiple inheritance in php?
    – JAyenGreen
    May 31, 2018 at 15:17

1 Answer 1

1

The image field type has no property image, the main property is target_id inherited from the file field type. The easiest way to define a custom image field would be to extend the three core image field classes another time, now in the namespace of your module.

See how ImageItem defines a new compound field by extending FileItem overriding propertyDefinitions() unsetting two properties and adding four new image specific properties.

An alternative solution would be Paragraphs, more overhead (while a compound field stores the data of all fields in one table, Paragraphs needs a table for each field and also for the paragraph entity itself), but it provides unlimited nesting of field types.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.