Problem/Motivation
Moderation state fields extend string and rely on string's sample generation during FieldItemList::generateSampleItems(). This leads to sample data which could be unsave-able since this has a tendency to produce strings like:
"fskldfjwlekrjasdknflkaweruasjkdnfaklsjdjrajsdnfkasdlfjasdklfjaweklrajsdffkl"
Unsurprisingly, that string is unlikely to match to any real moderation state names.
Proposed resolution
ModerationStateFieldItemList should implement generateSampleItems() itself and provide sane sample values.
The method could look thus:
public function generateSampleItems($count = 1) {
$state = $this->getModerationStateId();
$values = [];
for ($delta = 0; $delta < $count; $delta++) {
$values[$delta] = $state;
}
$this->setValue($values);
}
Big thanks to @abarrios for hunting this down.
Remaining tasks
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
Moderation state fields will now generate useful sample data.
Comment | File | Size | Author |
---|---|---|---|
#13 | 3048962-13.patch | 2.67 KB | paulocs |
#13 | interdiff-10-12.txt | 747 bytes | paulocs |
#10 | 3048962-10.patch | 2.74 KB | anmolgoyal74 |
#10 | 3048962-10-test_only.patch | 2.01 KB | anmolgoyal74 |
#4 | 3048962-4.patch | 2.58 KB | Sam152 |
Comments
Comment #3
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext for Brisbane City Council commentedGood catch, crediting @abarrios.
I think we could actually just empty out the whole method, or just call off to
computeValue
:The moderation state field is computed on demand, and would be populated depending on the sample value generated for the 'published' field. Any getters on the FieldItemList already call off to
getModerationStateId
.Comment #4
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext for Brisbane City Council commentedComment #9
scotwith1tTested against 8.9.8 and works like a charm. We ran into this with devel_generate creating nodes with entity reference field values and the related entities being created to populate those fields were subject to moderation states and being assigned weird devel_generate-y strings instead of valid values. Thanks for this!
Comment #10
anmolgoyal74 CreditAttribution: anmolgoyal74 at OpenSense Labs for DrupalFit commentedRe-rolled against 9.2.x.
Comment #12
LendudeDo we still do these alphabetically? can't remember if we care about that
Other then that this looks great.
Comment #13
paulocsSome issues I see that people say about it, but not sure if I already saw a maintainer saying about the alphabetic order.
I attach a patch that fixes it just to prevent.
Comment #14
alexpottCommitted and pushed 486bab8b49 to 9.2.x and e8a0c86a6a to 9.1.x. Thanks!