Unless a Replacement Variable is added to the "Then output this..." or "Otherwise, output this..." fields, any HTML entered into these fields is output "escaped", i.e. as plain text with "<" and ">" entities instead of angled brackets ("<" and ">").
A simple workaround is to create an empty "Global: Custom text" field, and add this as a Replacement Variable to the fields above.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 3053293-html-17.patch | 6.46 KB | shelane |
| #15 | 3053293-2.patch | 6.27 KB | dbielke1986 |
| #11 | 3053293-1.patch | 1.24 KB | dbielke1986 |
| #7 | 3053293-striptagsoptions.patch | 825 bytes | shelane |
| #7 | 3053293-translate.patch | 1.12 KB | shelane |
Comments
Comment #2
robbm commentedComment #3
codesmithThis just happened to me too. Thanks for the workaround. It's displaying HTML correctly in other views. Can't figure out what's different in this view.
Comment #4
chucksimply commentedYup, same thing happening to me as well.
Comment #5
naresh_bavaskari am unable to re-produce this issue.
steps i have followed:
1) created dummy contents, and created view.
2) added view conditional fields, added html text in `Then output this...` field
3) in output -> not able to see "<" and ">" (i can see proper output here)
please find the attached screenshot for more information.
let me know if i missed any anything on it.
Comment #6
freddy rodriguezI can confirm the problem. I have attached the screenshots of the field setup (Captura1), and the view output (Captura2)
Regards
Freddy
Comment #7
shelaneThere were only two commits made that have the potential to cause this issue. Please see which patch fixes it.
Comment #8
dbielke1986 commentedhttps://www.drupal.org/files/issues/2020-10-13/3053293-translate.patch
=> Is woking for me and version 1.1 of this module.
Comment #9
dbielke1986 commentedThe problem I see is to use t() to render the output. It will fill up the drupal user interface translation table with every output.
In my opinion it would be better to use html like this
Comment #10
shelaneThat is why I took them out originally. I restored so that I could get a fix out quickly. I will look at the suggested solution in a few weeks when I have some time to look at it. If you want to submit a patch, that would be great too.
Comment #11
dbielke1986 commentedHi Shelane,
attached you will find my patch to review. It seems to work fine for me.
Comment #12
dbielke1986 commentedComment #13
freddy rodriguezHello Shelane 8.x-1.2 Works perfect!
Comment #14
shelaneThe patch caused errors when the $equalto, $then, $or variables are later run through other str_replace functions.
Comment #15
dbielke1986 commentedOk, I did not run into these problems, but I think this is a valid point.
Therefore:
Next try. This patch fixes the problem for me as well and does not write strings into the translation table.
Comment #16
chucksimply commentedPatch from #15 worked for me on 1.2 (#11 patch wouldn't apply). Thanks for the work!
Comment #17
shelaneUpdating patch for testing. This patch differs from the previous only in the path of the source file.
Comment #19
shelaneComment #21
anybodyFollow-up as this removed translations completely in dev while they were enabled by default in 8.x-1.2. The next release from current dev would break this functionality!
#3195086: Add option for translation and exclude replacements from translation
Comment #22
eit2103 commentedRan into the same problem, following this topic as well.
Comment #23
anybody@eit2103: Then it would perhaps help if you could review #3195086: Add option for translation and exclude replacements from translation :)
Comment #24
tahu22 commentedThis issue is still active in 8x-1.5. I needed to go back to 8x-1.2 and apply the patch
Comment #25
anybody@shelane (Maintainer) is @Tahu22 right? If yes, was this removed by accident? Do you have tests to ensure this won't break again? Reopen? Or is he just wrong?