User tests: Successful: Unsuccessful:
title="Print article < Title of article >"
=> invalid HTML
After patch
title="Print article < Title of article >"
Status | New | ⇒ | Pending |
Category | ⇒ | Language & Strings |
Title |
|
Yes, it is invalid when used outside of attributes. In such cases the user could escape the whole string. But I guess this fixing this in the string is better. Just note that if someone does escape the string already, this will cause double encode for them.
I have tested this item
This will apply to several other strings as well if they are used where they are not intended to be used
I have tested this item
OT: I was previously by mistake in Joomla 4 :-) There I didn't find a print button.
OK, J 3.9.12 after Patch.
(added Code removed).
Don't know about "several other strings"
Status | Pending | ⇒ | Ready to Commit |
RTC
If someone is already using this string outside of its intended purpose then they may have
escape the string already, this will cause double encode for them.
And if someone is using it without escaping, they're getting invalid HTML. Let's just leave this for @HLeithner to decide whether he wants to merge this.
If we do this we have to be consistent over the complete code base, so if brian found other strings that have the same problem they have to be escaped too, also I'm not a fan of encoding strings in the ini file because you should do this on output. At least that's the way joomla handles variable output and language string output in scripts context.
Our documentation doesn't say much about the content of the language string https://docs.joomla.org/Specification_of_language_files
The simplest solution would be not to use critical characters in language strings.
Status | Ready to Commit | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-10-24 00:21:25 |
Closed_By | ⇒ | ReLater | |
Labels |
Added:
?
?
|
Why close this? I thought it was agreed that this PR is fine. Just that there are more instances of this. For example
I doubt that an xml description would be be used in another context... ;)
In any case, as you may guess, I am not in favor of modifying all the ini files containing <a href ... a>
(107 of them...) or other of this type... <br>
<span
strong
img
etc. It would be an enormous task for all TTs...
<
is used 1817 times.... and >
1843 times....
Anyone having a problem with a specific core ini containing one of these characters in a non-intended use should create overrides...
@infograf768 you misunderstood. HTML markup in language strings is fine. HTML in extension descriptions is allowed. So the issue with above example is here:
(in Users > Manage > Options)
These unescaped >
symbols cause invalid HTML markup, same way as described in this PR.
If it concerns only that type of value, I'm ok with correcting them.
This is not invalid because it's within quotes. At least HTML validator doesn't see this as invalid.