I'd like to implement an entity hook, and act on all fields defined by Computed Field FieldType plugins. So I either need a list of all FieldType plugins provided by the module or need to know which fields are associated with it in order to know which fields to work on (or avoid). Is this possible?

I'd rather not hard-code the list of plugins (computed_string, computed_decimal, etc.) because new ones could be added later, and then the list would have to change.

And I can't use computed_* because another module, Computed Field Plugin, defines its own field type with that prefix, and I don't want to touch it.

I was expecting something like FieldDefinitionInterface::getDefiningModule(), but that doesn't seem to exist.

For those interested, I'm working on adding support for computed cardinality.

  • I don't think this method exists. You could create an interface that each of the plugins in the module implements. Then you can loop through the plugins and see if they implement that interface.
    – Jaypan
    May 29, 2020 at 2:55
  • Ugh, what this module allows users to do just screams bad practice.
    – No Sssweat
    May 29, 2020 at 3:10
  • I'm inclined to agree, but I didn't want to prejudge, since maybe there is some reasonable use case for this.
    – Jaypan
    May 29, 2020 at 4:40
  • 1
    @NoSssweat: Computed Field in general? It's good for eliminating boilerplate code so you don't have to write a whole field plugin. As a maintainer, what I'm seeing on the roadmap is (1) disallowing PHP from the Web UI so code must come from modules, and (2) replacing the hooks with Events or Plugins. There are already some issues open for that. Please comment in the roadmap issue or the other ones. Any help would be appreciated!
    – colan
    May 29, 2020 at 14:12

1 Answer 1


The answer to the question title should be straightforward. You can get the extension from plugins via getProvider(). So you could make a list of all FieldType plugins or get the provider of a specific field type directly from the plugin defintitions:

$module = \Drupal::service('plugin.manager.field.field_type')

For field definitions this is a bit more complicated. Field storages have this method as well, but for configured fields it always returns the module field. This is not what you want. But there is a different place. When creating field storages the provider of the field type plugin is stored in the property module. So starting from FieldDefinitionInterface you should be able to get the module name:

$module = $field_definition->getFieldStorageDefinition()->get('module');
  • The latter one doesn't work: Call to undefined method Drupal\Core\Field\BaseFieldDefinition::get(). I think it's because getFieldStorageDefinition() just returns itself, not storage. Trying the other one...
    – colan
    May 29, 2020 at 20:50
  • The first/former one works; thanks!
    – colan
    May 29, 2020 at 21:00
  • 1
    module is a config property. Base fields don't have config values. I've assumed the use case for computed fields are configured bundle fields.
    – 4uk4
    May 29, 2020 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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