Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Using the (serializable) fields, e.g. title or body, all special characters are escaped in the REST export.
E.g. & becomes & in the JSON.
When using these variables in output, we currently would have to unescape them, which I think would be a much larger security risk?
Enabling "Unmodified output" doesn't change anything here. Update: See #10
This happens in both cases: When using the (serializable) field but also the regular field, e.g. title field.
So is this really expected and best practice? And is there a functionality to disable this escaping?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Issue fork rest_views-3593538
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
anybodyComment #3
anybodyLet's turn this into a feature request, which I think is more appropriate? Still very much hope for feedback from the maintainers.
Comment #4
anybodyComment #5
anybodyComment #6
anybodyOkay I just compared the output to the regular REST entity json output and (
/node/X?_format=json) and that's NOT escaped.&is returned as&, not&.So this is a bug. I think it might have been done for XML, because in XML it might be correct to encode the output. Maybe it should be moved into that specific case?
Comment #7
anybodyComment #8
anybodyLooking into the module's code I found out that this is NOT a bug in this module, but a core issue, which has already been reported: #3549810: Views REST Export: "&" in the fields is encoded as "&" in JSON response
The workaround is NOT using the
(serializable)field AND enabling Raw output option for the affected fields!I think we should wait for maintainer feedback, is this should be closed and entirely get resolved in Core or if this module should provide a workaround.
In my eyes it should at least get documented in the README of this module, that
(serializable)is the wrong choice then and what's the workaround. At least I though(serializable)is always the right, safe choice for REST views. So I'd still vote to fix it for these fields, if possible.Comment #9
anybodyHope this title is more clear :)
Comment #10
anybodySorry guys, I wrote
but I was fooled by the Views preview or cache!
Using "Unmodified output" works and returns the unescaped value for string fields as expected! For both core views fields and the additional (serializable) fields!
After checking the *real* output again with that option set on the affected fields, the unwanted escaping is gone!
So I think this might be expected and I'm closing this. Please reopen if not.