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
With a combination of processors the content of 'Rendered Item' was being removed and replaced with an empty array. The value of Rendered Item was originally a string, later an array of items, which tokenizer was overwriting.
Proposed resolution
Rather than the value being set as a string it should be handled by the text datatype handler.
Suggestion to move the data type handing code from Utility::extractField() to Field::addValue().
Remaining tasks
Do it.
User interface changes
None - except for less fatal error :)
API changes
None
Comment | File | Size | Author |
---|---|---|---|
#14 | 2752963-14--data_type_value_processing.patch | 9.18 KB | drunken monkey |
#14 | 2752963-14--data_type_value_processing--tests_only.patch | 4.49 KB | drunken monkey |
Comments
Comment #2
ekes CreditAttribution: ekes as a volunteer commentedCut and Paste patch - for tests (seems like it's working, but tests failing locally).
Question, shouldn't the Data Type plugin be loaded with the class?
Comment #3
ekes CreditAttribution: ekes as a volunteer commentedComment #6
ekes CreditAttribution: ekes as a volunteer commentedTest fixes.
Comment #7
ekes CreditAttribution: ekes as a volunteer commentedComment #8
ekes CreditAttribution: ekes as a volunteer commentedComment #9
drunken monkeyGreat job, thanks a lot for working this out!
The patch already looks quite good. The attached revision includes a bit of clean-up, documentation for the newly defined differences between
Field::setValues()
andField::addValue()
and some more tests to ensure this doesn't happen again.Please test/review!
Also thanks for thinking of the tag!
Comment #14
drunken monkeyComment #17
ekes CreditAttribution: ekes as a volunteer commentedThe handling of the Datatype manager in Field class makes a lot more sense, plus clarifying the use of the two set/add methods.
I'm not actually sure how to test that it doesn't happen again. The values were being removed by the set method working correctly, but being passed bad data (an empty array) by the processor.
I assume the theory of the additional test is that If the processors are always handling the typed data (is this now _always_ the case?) it shouldn't happen that the incorrect data gets passed?
Comment #18
drunken monkeyThanks for reviewing, good to hear you like the changes!
I'm just testing more or less exactly what our fix was: we just changed the field to always use the data type plugin for processing when adding values, so as long as that happens correctly this error shouldn't happen again.
If the values are correctly processed by the data type plugin, the correct further handling of the values by the processors is already verified by
FieldsProcessorPluginBaseTest
.So, is this RTBC, in your opinion?
Comment #19
ekes CreditAttribution: ekes as a volunteer commentedMakes sense. So just adding the reason? But for the rest all good.
Comment #21
drunken monkeySure, makes sense. Thanks!
Amended and committed.
Thanks again for your great work on this!