Ampersand (&) in event title is converted to html &

[yorkshire-pudding]

If an event title has an ampersand (&) in, then Full Calendar display this as & whereas other views display normally:

Actual result:

Expected result:

[indigoxela]

That's known behavior in the FullCalendar library. Not sure if I could do anything about that.

See also:

• https://github.com/fullcalendar/fullcalendar/issues/6716
• https://github.com/fullcalendar/fullcalendar/issues/1024
• https://github.com/fullcalendar/fullcalendar/issues/378
• https://github.com/fullcalendar/fullcalendar/issues/671

[yorkshire-pudding]

There are some comments in those tickets by Adam Shaw that suggest it should accept a single & character. I've managed to workaround by changing it to "and". Thanks @indigoxela

[indigoxela]

Having a closer look ... the html encoding to $amp; happens in views (check_plain), the next encoding happens when the js setting is rendered in backdrop_pre_render_scripts(), so we end up with \u0026amp;

We need the rendered field because of token replacements, so falling back to the raw value in renderRow isn't an option - and questionable security-wise.

We could do strip_tags(decode_entities($rendered_field)); FullcalendarViewsStyleCalendar::renderRow, but I'm not sure if that's a smart idea.

[indigoxela]

Here's a PR: #27 - but I'd really appreciate some more feedback. Are there any pitfalls with this approach?

[yorkshire-pudding]

That works. I can't think of any issues but may be worth getting someone who knows more about security to check.

[indigoxela]

My concerns are not so much about security, because markup gets stripped (strip_tags). My concerns are more like "is this a valid approach, or a silly workaround, or does Views provide something easier for cases like that"? :wink:

[yorkshire-pudding]

Looks valid to me. As other views with the same data don't have the issue, it makes sense to me that the FullCalendar view fixes it. Thanks @indigoxela

[indigoxela]

Another look... it seems like views uses something similar for paths, so at least the approach isn't wrong per se.

Markup in the title field never worked, as FullCalendar would encode it, anyway. Decode back after Views ran check_plain over it and stripping html tags explicitely makes no difference re markup. I'm pretty sure, this change won't break anything, but fixes double encoding.