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
ViewsUIController::reportFields() calls SafeMarkup::set() which is meant to be for internal use only.
Proposed resolution
- Remove the call by refactoring the code.
If refactoring is not possible, thoroughly document where the string is coming from and why it is safe, and why SafeMarkup::set() is required.
Remaining tasks
Evaluate whether the string can be refactored to one of the formats outlined in this change record: https://www.drupal.org/node/2311123Approach should be the same as #2505931: Remove SafeMarkup::set in ViewListBuilder (currently: adding'#theme' => 'inline_list'
Identify whether there is existing automated test coverage for the sanitization of the string. If there is, list the test in the issue summary. If there isn't, add an automated test for it.No new user-provided text is added here, sanitization is handled elsewhere.If the string cannot be refactored, the SafeMarkup::set() usage needs to be thoroughly audited and documented.
Manual testing steps
Do these steps both with HEAD and with the patch applied:
- Clean install of Drupal 8.
- Create at least two views, displaying fields, that use the same fields.
- Visit the "Used in Views" field list page at admin/reports/fields/views-fields
- Compare the output above in HEAD and with the patch applied. Specifically, review the "Used In" column.
User interface changes
N/A
API changes
N/A
Comment | File | Size | Author |
---|---|---|---|
#23 | 2501937-23.patch | 2.69 KB | stefan.r |
#23 | interdiff-21-23.txt | 1.94 KB | stefan.r |
#22 | 2501937-21.png | 64.12 KB | Anonymous (not verified) |
#22 | 2501937-head21.png | 66.32 KB | Anonymous (not verified) |
#21 | interdiff-15-21.txt | 3.58 KB | stefan.r |
Comments
Comment #1
star-szrIt would probably be nice to have SafeMarkup::implode (or ::join) again (#1825952: Turn on twig autoescape by default) for cases like this rather than this roundabout way.
Comment #2
star-szrPostponed on some further discussion on #2501975: Determine how to update code that currently joins strings in SafeMarkup::set() for now.
Comment #3
cilefen CreditAttribution: cilefen commentedRelated: #2505931: Remove SafeMarkup::set in ViewListBuilder
Comment #4
star-szrComment #5
akalata CreditAttribution: akalata commentedNo longer blocked, though the discussion in #2501975: Determine how to update code that currently joins strings in SafeMarkup::set() might be valuable to identify the best solution in this case.
Comment #6
akalata CreditAttribution: akalata commentedPostponed for real on #2505931: Remove SafeMarkup::set in ViewListBuilder. Whatever pattern we find works there can most likely be used here as well.
Comment #7
akalata CreditAttribution: akalata commentedComment #8
stefan.r CreditAttribution: stefan.r commentedThis may work once #2505931-170: Remove SafeMarkup::set in ViewListBuilder is in.
Comment #9
Wim Leers#2505931: Remove SafeMarkup::set in ViewListBuilder just landed :)
Comment #10
dawehnerPerfect!
Comment #11
stefan.r CreditAttribution: stefan.r commentedThis needs to be updated still
Comment #12
stefan.r CreditAttribution: stefan.r commentedComment #13
stefan.r CreditAttribution: stefan.r commentedComment #14
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedThe patch in #12 doesn't work, or at least broke something:
Comment #15
stefan.r CreditAttribution: stefan.r commentedAh yes, that was wrong
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedManual testing gives me the same result as #14.
And given that #12 came up green, we are missing coverage.
Comment #17
stefan.r CreditAttribution: stefan.r commented@pjonckiere did you test #15? Against HEAD? Because it works fine for me:
I'm not sure about this needing automated tests, the
item_list
already has test coverage so asserting for the correct output of that theme function (ie. a<ul class="comma-list">
etc.) in every single caller seems a bit redundant? We also can't assert for the comma list as it's CSS based, so this would need to be tested manually.If anything asserting that the field list is not empty would be a nice to have for the future?
Comment #18
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedYes. The IS specifies to look at the "Used in Views" tab. Based on your screenshot, I think you are looking at the "Entities" tab?
I was more thinking of a "is the output there" kind of test. But fair enough.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedFwiw, I see following in my source:
Comment #20
stefan.r CreditAttribution: stefan.r commentedAh, that makes sense, thanks!
Comment #21
stefan.r CreditAttribution: stefan.r commentedAdded that test and this should fix the issue from #18
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedNow it's working, but a space got lost (cf screenies). I would think that a list_type of "comma-list" would do that for you, but that doesn't seem to be the case.
Other than that, the fix and the test look good to me!
Comment #23
stefan.r CreditAttribution: stefan.r commentedI just manually tested myself and it didn't have the CSS issue (Firefox). Do you have the same problem in the comma separated item lists on admin/structure/views? Which browser was this?
Comment #24
Wim LeersNit: no need to create this variable. Just do:
(You only want to assign it to a variable if you're going to use the variable.)
Can be fixed on commit, or not at all :) Doesn't really matter.
Comment #25
alexpottCommitted 9f85d56 and pushed to 8.0.x. Thanks!
Didn't fix the unused variables... it's a test :)