Problem/Motivation
\Drupal\field\Entity\FieldStorageConfig::id()
:
public function id() {
return $this->getTargetEntityTypeId() . '.' . $this->getName();
}
and \Drupal\field\Entity\FieldStorageConfig::loadByName()
:
public static function loadByName($entity_type_id, $field_name) {
return \Drupal::entityTypeManager()->getStorage('field_storage_config')->load($entity_type_id . '.' . $field_name);
}
and worse:
\Drupal\Core\Field\FieldConfigBase::id()
:
public function id() {
return $this->entity_type . '.' . $this->bundle . '.' . $this->field_name;
}
and \Drupal\field\Entity\FieldConfig::loadByName()
:
public static function loadByName($entity_type_id, $bundle, $field_name) {
return \Drupal::entityTypeManager()->getStorage('field_config')->load($entity_type_id . '.' . $bundle . '.' . $field_name);
}
(Same thing for \Drupal\Core\Field\Entity\BaseFieldOverride::loadByName()
: 3 parameters that together create the name/ID.)
The corresponding config entity type annotations do not have any metadata at all that would allow us to construct these IDs automatically. They contain a config_prefix
key-value pair, but not something like a config_name_parts
key-value pair.
Until Drupal core provides an API for this, we have no choice but to hardcode these three. We can find them by searching for .*.*
in *.schema.yml
files.
But β¦ that's how we can discover there's actually several more: core.entity_view_mode.*.*
, core.entity_form_mode.*.*
, core.entity_view_display.*.*.*
and core.entity_form_display.*.*.*
. For these, all of the mapping/loading logic is embedded in \Drupal\Core\Entity\EntityDisplayRepository
.
Steps to reproduce
Proposed resolution
Harden \Drupal\jsonapi_schema\StaticDataDefinitionExtractor::extractConfigEntityType()
.
Remaining tasks
User interface changes
API changes
Data model changes