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
\Drupal\path\Plugin\Field\FieldType\PathItem extends FieldItemBase which defines its main property name as simply 'value'. This is incorrect for PathItem which should instead be alias.
Proposed resolution
Override mainPropertyName() method on PathItem
Remaining tasks
Tests?
User interface changes
None
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#32 | 2683431-32.patch | 3.57 KB | penyaskito |
#17 | 2683431-17.only-tests.patch | 2.17 KB | penyaskito |
Comments
Comment #2
EclipseGc CreditAttribution: EclipseGc commentedPatch!
Eclipse
Comment #3
EclipseGc CreditAttribution: EclipseGc commentedComment #4
klausiMakes total sense, we should add a tiny unit test that asserts the output of this method.
Comment #5
EclipseGc CreditAttribution: EclipseGc commentedShould there not be a larger unit test that asserts that the main property value is one of the defined properties of the field? In this case right now, 'value' isn't even an option and that feels like it should throw a big fat error somewhere instead of blowing up when I ask for ->getDataType() on a returned NULL value. How I found this is thus:
$property_definition->getFieldStorageDefinition()->getMainPropertyName() returns 'value' and $property_definition->getFieldStorageDefinition()->getPropertyDefinition('value') returns NULL, so NULL->getDataType() doesn't work, and this could magically start failing again for FieldType that makes this same mistake. While ideally I think I'd prefer an optional exception thrown for the getPropertyDefinition() method, I realize that's an api change, and for the moment I think I'd just like to see every field type tested in a loop proving that their main property actually exists on the field somewhere. Is that reasonable?
Eclipse
Comment #6
klausiOh yes, I'd like to see such a test. How would you make sure you catch all possible fields provided by all possible modules in core?
Comment #7
EclipseGc CreditAttribution: EclipseGc commentedOk, first pass at the test, ironically, path doesn't seem to show up there... probably because path module's not on. But even this test right now shows we have problems.
Eclipse
Comment #9
penyaskitoRelated: #2681241: Path doesn't behave as a regular field and #2539634: PathItem::delete() never runs because the path field type is a computed field in disguise.
Comment #10
dsnopekRe-titling in an attempt to understand the issue. This isn't about documentation, but returning the name of it's main property via the API.
Comment #11
dsnopekEr, it doesN'T do that :-)
Comment #12
penyaskitoRerolled the tests at #7.
Comment #14
penyaskitoAdding path to the enabled modules ensures those errors are discovered.
Edited: Also modified the tests so we cover cases with no properties defined, as the MapItem does.
Also fixed
ShapeItem
while we are here, so the tests are green after the patch. I'm wondering how could we ensure that at least all core modules are added, so we check all the field type plugins.Comment #15
dawehnerLet's use
{@inheritdoc}
what about file and image, just to be sure.
$this->enableModules
Super cool idea!
we use sprintf / literal php strings now.
Comment #17
penyaskitoLet's try enabling all modules then.
Comment #18
dawehnerCool, thank you!
Comment #19
penyaskitoFQCN (see interdiff)
Comment #21
penyaskitoComment #22
penyaskitoClosed #2622300: PathItem must override mainPropertyName() as duplicated, it's older but tests are much better here.
Comment #23
alexpottThis should be limited to core modules only. Test modules should be chosen to be enabled. I was wondering if this includes test modules too - imho test modules shouldn't be enabled here either.
Comment #24
alexpottNot used.
Needs a docblock.
Not shape?
Comment #25
penyaskito#23: Tests module were being installed. Filtering now that only core modules and non-testing modules are installed. The only way I knew for filtering those is looking at their path. Please suggest a better way if any.
#24: Fixed.
Comment #27
penyaskitoRe-testing, that doesn't look related.
Comment #28
penyaskitoBack to needs review then :-)
Comment #29
dawehnerLet's move that into its own method
We can use $this->assertArrayKeyExists or so
Comment #30
penyaskitoHere you are.
Comment #32
penyaskitoOoopsie
Comment #34
penyaskitoRe-testing, looks like #2724871: Random failure in \Drupal\migrate_drupal_ui\Tests\d7\MigrateUpgrade7Test
Comment #35
dawehnerIt was @penyaskito!
Comment #36
alexpottCommitted 8f61056 and pushed to 8.1.x. Thanks!