Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Follow-up to #2341357: Views entity area config is not deployable and missing dependencies. In that patch, we add the following hardcoded check in EntityManager::loadEntityByConfigTarget():
// For configuration entities, the config target is given by the entity ID.
if ($entity_type instanceof ConfigEntityTypeInterface) {
$entity = $this->getStorage($entity_type_id)->load($target);
}
// For content entities, the config target is given by the UUID.
else {
$entity = $this->loadEntityByUuid($entity_type_id, $target);
}
Proposed resolution
Instead of hardcoding this check, we could allow entity types to return their target identifier key.
Remaining tasks
Decide if this would be a worthwhile change following #2341357: Views entity area config is not deployable and missing dependencies.
User interface changes
None.
API changes
TBD
Postponed until
#2341357: Views entity area config is not deployable and missing dependencies
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2412983.patch | 700 bytes | amateescu |
Comments
Comment #1
xjmForgot to correct the issue title. :P
Comment #2
xjmComment #3
amateescu CreditAttribution: amateescu commented@xjm, you said in #2341357-124: Views entity area config is not deployable and missing dependencies:
PHP provides a nice way for this if we really want to ensure it :)
Comment #4
xjmUh. I don't think that's what I meant, exactly. :) Or at least, it's not what I was thinking about. I meant, ensure that we don't accidentally store UUIDs for config entities and thereby break config dependencies, with the default implementations, in messy cases like Views. If someone wanted to override some config service to do dependencies with UUIDs, uh go for it and have fun? Or something.
Comment #5
xjmBasically, my thought here was that our distinction between configuration and content is arbitrary (e.g. taxonomy terms) and so providing API rather than hardcoding instanceof checks seems more sound and offers the potential for alternate implementations.
Comment #14
bradjones1