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
It is currently possible to override of the uuid key in configuration entities. However this is problematic because the configuration importer needs to detect configuration renames, recreates and deletes using the uuid key and this is hardcoded because the module that supplies the configuration entity type might not yet be installed.
Proposed resolution
Ensure that the uuidKey is uuid.
Remaining tasks
Write patch with tests
User interface changes
None
API changes
Restrict uuidKey to only being uuid.
Data model changes
None
Why is this an rc target?
If a configuration entity used an uuid key other than uuid it would break ConfigImporter.
Comment | File | Size | Author |
---|---|---|---|
#28 | 2604450-28-test.patch | 3.84 KB | Nikhil_110 |
#28 | 2604450-28.patch | 5.17 KB | Nikhil_110 |
#24 | interdiff_23-24.txt | 1.37 KB | Nikhil_110 |
#24 | interdiff_23-24-test.txt | 1.37 KB | Nikhil_110 |
#24 | 2604450-24.patch | 5.33 KB | Nikhil_110 |
Comments
Comment #2
alexpottI think this is the simplest thing to do.
At the moment the UUID key is basically enforced through the constructor of the ConfigEntityType constructor but this patch hardens and tests the implementation.
Comment #5
alexpottDoh...
Comment #6
tim.plunkettRan these as test-only locally, they did not fail.
Comment #7
tim.plunkettSee #2052083: EntityType::getKey() should be used instead of hardcoding id, status, weight, etc., is this actually a bug these days?
Comment #8
tim.plunkett\Drupal\Core\Entity\Entity::uuid() still hardcodes uuid and #2052083: EntityType::getKey() should be used instead of hardcoding id, status, weight, etc. won't change that, so why do we have \Drupal\Core\Entity\EntityStorageBase::$uuidKey at all? Unless the entity class also overrides that method...
Shouldn't we just hardcode this in all entities?
Comment #9
xjmComment #22
larowlanIs this still relevant? Can we get a failing test from the test changes above?
Comment #23
Nikhil_110 CreditAttribution: Nikhil_110 at Srijan | A Material+ Company commentedRe-roll patch and added tests, please review.
Comment #24
Nikhil_110 CreditAttribution: Nikhil_110 at Srijan | A Material+ Company commentedFixed Issue #23 Please review
Comment #26
smustgrave CreditAttribution: smustgrave at Mobomo commentedSeems reroll showed the issue does exist. Ran the tests for 11.x and all green there.
Comment #27
larowlanThanks for breathing life into this long stale issue!
Couple of minor observations/questions but this looks close.
I also think there's a risk of disruption here, so moving this to 11.x so it will be 10.2 only (next minor release).
Can we also get a change notice and release notes snippet?
Thanks!
Are we using this in any of the tests?
I don't think we need class properties if we're only using them in one test case, let's just make these inline variables
Comment #28
Nikhil_110 CreditAttribution: Nikhil_110 at Srijan | A Material+ Company commentedPatch added against #27 Point - 2 and still Pending 1 point so need work.