PKP Bugzilla – Bug 3316
standalone < tag in abstract field stops text from displaying
Last modified: 2009-01-08 08:08:24 PST
If a standalone < tag appears in an abstract, neither it nor any other text following it will display when the abstract is viewed.
Example provided here: http://pkp.sfu.ca/support/forum/viewtopic.php?f=3&t=2945
I've managed to replicate the issue.
Note: I just realized that the forum poster was referring to OCS; however I replicated this in OJS. Probably safe to assume then that it's inherent in both systems.
This is because OJS and OCS allow limited HTML in abstract fields, so "<" is being treated as an invalid HTML tag. This should already be addressed in OJS > 2.1.1 using the TinyMCE plugin (and in CVS OCS) -- James, were you using TinyMCE when you duplicated this in OJS?
(In reply to comment #2)
> This is because OJS and OCS allow limited HTML in abstract fields, so "<" is
> being treated as an invalid HTML tag. This should already be addressed in OJS >
> 2.1.1 using the TinyMCE plugin (and in CVS OCS) -- James, were you using
> TinyMCE when you duplicated this in OJS?
Yep -- OJS 2.2 stock install, using TinyMCE. I've tested a bit further, using both stock and CVS, and actually, this behaviour only happens when the tag is followed by a non-space character: "<word" and "<." trigger the display stoppage, but "< word" appears as "< word".
This was an issue with Core::cleanVar() -- by default it would convert HTML entities to their respective characters. Behaviour has been changed to skip this if TinyMCE is enabled (assuming HTML entities coming from TinyMCE are intentional).
MJ, the core shouldn't mention any plugins by name -- the TinyMCE plugin should be in charge of this kind of behavior modification. If necessary, you can add a hook to Core::cleanVar. (Also, don't forget OCS and the Harvester!) -- Thanks.
Mea culpa; thanks for your comments Alec. I actually reproduced this incorrectly -- the issue is that strings starting with '<' followed by alphanumerics are caught by the strip_tags call in String::stripUnsafeHtml().
This may be bad behaviour on PHP's part, but I'm not going to make any drastic changes to code that we rely on for preventing XSS attacks. Data is stored correctly, this is a display (Smarty) issue.
Deferred as a known issue.
MJ, do you know where these &#someNumberHere; entities are coming from? AFAIK, TinyMCE should use the expected < and > etc.
(FYI, you should defer issues by marking them against a subsequent or to-be-decided release, rather than resolving them as LATER.)
Needs further testing -- but for the moment, either TinyMCE or a space between the < and the number (when TinyMCE is disabled) should be good work-arounds.
MJ, is this entry still relevant, or should we close it?
Alec, this should be fixed as part of the new phputf8 code (#3807):
Marking as resolved.