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