Closed (fixed)
Project:
Drupal core
Version:
8.2.x-dev
Component:
views.module
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
6 Nov 2015 at 16:26 UTC
Updated:
14 Oct 2016 at 14:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
marcingy commentedThis isn't critical and exact steps to reproduce the issue would be super helpful
Comment #3
jclopez commentedThe same it's happening on my end
Ones I create a view block and on any field I set the "No results behavior" with HTML
On the render I can see the tags and everything as plain text, according to the help text for that field "You may include HTML" so clearly something is broken.
Comment #4
cilefen commentedThere is really no such thing as Views 8.x, it is in core. That is probably why this issue was ignored #2585205: No results behavior showing html markup code
Comment #5
cilefen commentedComment #6
cilefen commentedWhat kind of "No results behavior" field are you using? Is it "Text area"?
Could add the steps to reproduce to the summary please?
Comment #7
cilefen commentedI just tested with HEAD and HTML in a "Text area" and the HTML was rendered, not escaped.
Comment #8
jclopez commentedOk, here are the steps:
First you go to Administration->Views->edit one of your views (Screen Shot 2015-11-06 at 3.19.34 PM.png)
Then under "Fields" you click to edit one of the fields (Screen Shot 2015-11-06 at 3.20.12 PM.png)
Under "No Result Behavior" enter HTML (Screen Shot 2015-11-06 at 3.20.28 PM.png)
And in the preview you'll see the tags and rendered as plain text (Screen Shot 2015-11-06 at 3.21.08 PM.png)
Here are the screenshots:
Thank you
Comment #9
cilefen commentedThank you! Could you put the steps in the issue summary? Also, yes, it is definitely a real problem.
Comment #10
gceja commentedComment #11
cilefen commentedThank you!
Comment #12
cilefen commentedComment #13
dawehnerWe ideally would have tests ...
Comment #14
cilefen commentedSomething like this, but not exactly like this, should work.
Comment #15
dawehnerWe could also check that the result is a ViewsRenderPipeLineMarkup object ...
Comment #17
aerozeppelin commentedTests as per #14 and #15.
Comment #18
joelpittetThank you @aerozeppelin for the assertion.
Comment #20
dawehnerJust a future tip: You can use ViewsRenderPipelinkeMarkup::class to get the full classname here, pretty handy in some places
Comment #21
catchCommitted/pushed to 8.1.x and cherry-picked to 8.0.x. Thanks!
Comment #25
joefry commentedI'm using 8.0.3 and the module has the changes in patch 2610236-17.patch included.
but i still get this result:
entered in "no results":
<h2>{{ field_vegetable }}</h2><span> some text</span>view shows:
<h2>Rutabaga</h2><span> some text</span>(escapes html)
Comment #26
cilefen commentedJust some housekeeping: This was Major priority. It still is Major if not fixed. Branch 8.0.x is closed for changes. It would be good to see if this is reproducible on 8.1.0-rc1.
Since this is fixed, and has tests, I am not sure what is going on here.
Comment #27
lendudeI can't reproduce the issue on the current HEAD. HTML (with tokens) works when set in 'No results text'. If you still have this issue, please give some detailed steps to reproduce.
Comment #28
frazacDrupal 8.1.3, but this patch isn't still included?
give
<div class="noimage">&nbsp;</div>Tell me if you need more details
Thanks!
Comment #29
leksat commentedI have found a way to reproduce the bug on the latest 8.2.x. The "No results text" is escaped when the "Hide rewriting if empty" checkbox is unchecked.
Comment #30
leksat commentedViews render logic is pretty complicated, but I think I found the bug reason.
Here is the value-is-safe check:
But the MarkupTrait::create() always returns empty string if an empty string was passed in.
Comment #32
leksat commentedPatch works.
Comment #33
dawehnerThank you for your patch!
Do you mind changing this small bit?
foreach in tests should be always replaced by a
@dataProviderComment #34
leksat commentedSorry, somehow I never heard of @dataProvider :D Cool stuff actually!
Comment #36
lendudeTest and fix look good.
Feels weird to cast it to a string twice in two consecutive lines but can't really think of a way to handle this logic with doing it just once.
Issue summary could really use an update to reflect the problem that still exists after the committed fix in #21.
Comment #40
cilefen commented@timplunkett, @alexpott, @dawehner, @xjm and I discussed this in a triage session at DrupalCon Dublin. We feel the special case is no longer major. Please open a normal priority follow-up issue for the improvement in #34.