Good job, Alessandro!

Now I have to go, but later I'll test this and publish result.

@smz thanks! please also take a look to the other PR #7328

@elpaso can you add soeme quick steps to check that the issue is fixed for non-developers also to the other on? Normaly suche issues gets faster tests and merges ;) Thanks.

@elpaso Alessandro,

I've tested this and #7328 and can confirm that in both cases the new generated URLs for the serviceUrl: parameter in the jQuery autocomplete() functions have correctly escaped ampersand when your patches are applied. Furthermore autocomplete functionality is not affected, so this is a positive test.

but...

As @Fedik suggested, I'm not sure this is necessary: these are URLs used by the JQuery autocomplete function, they are not part of any HTML link (e.g.: href="...") and in theory they shouldn't be exposed to HTML validators.

Did you actually checked with the W3C validator? I don't have any globally accessible site using com_finder right now, so I can't check myself... Can you provide a link to a globally accessible Joomla site where W3C validator complains about this?

From our point of view (I mean our router) both are correctly parsed, so both are acceptable.

<ot>
As @zero-24 suggested, it is good practice here to provide some more detailed description of your PR and some testing instruction, and assign a title that puts your PR in context.

You could had used "Fix for unescaped ampersands in com_finder URLs" as the title and then in the description put something like that (Markdown code):

### Description
This fixes a couple of unescaped URLs generated by com_finder/mod_finder.
Ampersands characters are inserted verbatim and not as the `&` HTML entity.
W3C validator complains about this.

### Testing instructions
- Configure the "Smart Search" component in your test site
- Publish the "Smart Search" module in your home page
- Compare the generated HTML without and with this patch
- Ampersands in the `serviceUrl:` parameters of the JQuery autocomplete functions
  should now be correctly escaped.
- Verify that autocomplete is still working

I also think that as this PR and #7328 are strictly related, they could had been merged into a single PR...
</ot>

Cheers! Sergio

@smz sorry for the quick and dirty patch, given the limited time I had yesterday, the choice was between submitting a quick patch from github online editing (that's the reason for double patch) and not doing it at all.
You can test W3C validation by uploading HTML if your site is not on the internet (be sure to choose an XHTML template), and no, I have no online examples because I've already patched all my online sites through a template override.
BTW, probably the right patch would be wrapping JS code with CDATA, because other unescaped & will eventually break validation.

I believe we should really change addScriptDeclaration to add CDATA wrapper for all js code.

To give you some more context, I'm involved in the development of joomlafap (accessible Joomla!) which uses XHTML+WAI-ARIA DTD. Validation is a mandatory requirement, enforced by law for all Italian public administrations.

Any chance to see this implemented? Should I submit another PR? (I promise this time I'll write a full report)

@elpaso Alessandro, I'm not part of the PLT nor any other formal team, so I can't officially speak, but usually when a patch has two positive tests and doesn't break anything it receive the RTC flag and then it gets merged at the earliest opportunity, which can be the next patch release or the next minor release depending on such factors such if it introduces new functionalities, deprecates some method or class vars, etc.

For this I personally don't see anything precluding a merge in the next patch release.
You have already my positive test... let's see if we can bring someone else in to test this...

I believe we should really change addScriptDeclaration to add CDATA wrapper for all js code.

This is true for XHTML, but not necessary for HTML, which apparently is what everybody's doing at this time (me too). Any reason why you use the XHTML+WAI-ARIA DTD? Is that part of the requirements of the Italian law? (I wouldn't be surprised...)

@dgt41: Dimitris can you look at this interesting issue and express your opinion?
And... while you're here, why don't you give this (and #7328) a test?

Cheers! Sergio

BTW, probably the right patch would be wrapping JS code with CDATA, because other unescaped & will eventually break validation.

I guess the best option here is to use the right document declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
In such case //<![CDATA[ will be automatically included for all inline scripts

@dgt41 there is no such a thing like "the right DTD", it depends ona case basis, and my is:

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
  "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it-it" dir="ltr">

The only way I see to force CDATA wrapping is to set:

JFactory::getDocument()->setMimeEncoding('text/xml')

which is NOT the right thing to do, because the browser will then interpret the page as XML not XHTML.

@smz previous requirement (since 2013) was XHTML 1.0 strict. Now you can choose whatever accepted stardard you want but HTML5 is not recommended because of its poor support from assistive technologies. XHTML+WAI-ARIA is definitely the way to go.

So, at this point I feel that the patch should allow to enable CDATA wrapping independently from setting the HTTP header.

I'm afraid it might not be that easy: I don't think we have access to the DTD (which is part of the template) from within the application, so how can we decide when to add CDATA and when not?

I'll look into that, but you'll have to hold your breath for some time...

In the meanwhile I think what you did in this two PRs is totally acceptable and correct.

@elpaso
<ot>
I also think you can force the insertion of the required CDATA in your HTML by using a 3rd party extension: ReReplacer, by NoNumber (@nonumber) , allows you to replace stuff into the generated HTML, also through regular expressions and "by area" (head v.s. body).

TBH I can't live without it for my sites...
</ot>

@smz I do regexp too on my own "swissknife" plugin but having joomla full support for XHTML valid code would be definitely good.

All I need is an API call to activate the XHTML compliance without setting the mime-type.

All I need is an API call to activate the XHTML compliance without setting the mime-type.

This is a lot easier said (and programmed) than actually implemented into the core mainly for two reasons:

1. Semantic versioning: Joomla has adopted a semantic versioning scheme (http://semver.org/), and under those rules a new public accessible method can be introduced only with a MINOR version change (in our case it will be with Joomla! 3.5.0)

2. Backward compatibility commitment: This too follows the rules of Semantic Versioning and once a new public accessible method is added to the API, this represent a commitment by the Joomla! community to maintain it at least up to the next MAJOR release.

For the above reasons you would not see too often the adoption of new API methods, and only after an accurate screening by the community and, of course, the PLT.

But do not desperate... asking is always allowed!

@bakual, @wilsonge and all the others of the PLT, what do you think about this? Would it be possible to introduce an "XHTML compliance" switch (a class var), with possibly just a getter and a setter, and have relevant methods (e.g.: addScriptDeclaration) correctly adapt their behavior to the state of that switch? Of course with the default state the generated HTML should not change...

or (easier) ...

can we just have addScriptDeclaration wrap scripts between //<![CDATA[ ... //]]>, if this is all that is needed to get XHTML compliance (others will know better than me, but I seem to remember that this is not enough...)

I'm not even sure I understand the issue. Is there a downside to escape &?

However, we usually don't serve XHTML or XML pages. Our JDocumentHtml class is built to serve HTML5 pages, and to my knowledge JavaScript can contain unescaped & just fine in HTML5.

If the template really has to use an XHTML doctype, then the best approach would probably be to have a plugin which interacts with the script property of JDocument which then adds the cdata around it.

Not sure if it's worth it, as the browsers will work fine either way. It's only an issue if you are going to run the website through an XML parses. Which I'm not even sure if that is a valid usecase.

@Bakual

I substantially agree with you, but...

... It's only an issue if you are going to run the website through an XML parses. Which I'm not even sure if that is a valid usecase.

In @elpaso case this seems exactly to be the case, due to requirements enforced by law for all Italian public administration's websites (has to do with accessibility...)

I thought Italian a11y required WCAG 2
On 5 Jul 2015 6:58 pm, "Sergio Manzi" notifications@github.com wrote:

@Bakual https://github.com/Bakual

I substantially agree with you, but...

... It's only an issue if you are going to run the website through an XML
parses. Which I'm not even sure if that is a valid usecase.

In @elpaso https://github.com/elpaso case this seems exactly to be the
case, due to requirements enforced by law for all Italian public
administration's websites (has to do with accessibility...)

—
Reply to this email directly or view it on GitHub
#7327 (comment).

I honestly really don't know... I leave the word to @elpaso...

... in any case I think this PR and its sister #7328 are correct as they fix the & representation within URLs ...

@brianteeman yes, WCAG 2.0 AA is required. But IMHO WAI-ARIA is better. But this is OT, the question is if it is possible to output proper XHTML CDATA-wrapped js.

I asked because @smz stated this was why you needed to do this

... here: #7327 (comment)

To give you some more context, I'm involved in the development of joomlafap (accessible Joomla!) which uses XHTML+WAI-ARIA DTD. Validation is a mandatory requirement, enforced by law for all Italian public administrations.

I have tested this item successfully on 8eccc84

succesfully tested. the URL ampersands are escaped.

@seagul30 is there any hope to see this land into master?

@elpaso that's not up to me. I only tested succesfully. There is one more test missing.

@elpaso please write a full test scenario.
If you want to have a PR in the core, people need to be able to test it.

I have tested this item ✅ successfully on 8eccc84

didnt find the "suggest link", but checked the php code and filled the file with random data. Every character was escaped. @icampus

IMO this is not correct.
For not having the W3C validation error your site pages need to be rendered with the correct mimetype.

See #10697 (comment) for more info on a a similar issue, but with the session keepalive json URL.

It's passed more than one year, we have of course solved the problem with our own solution. But IIRC, if you change the mime type (to XML in this case, since we are using XHTML) you get the incorrect header and the browser interpret the page as XML instead of HTML, which of course introduce a much bigger issue.

But IIRC, if you change the mime type (to XML in this case, since we are using XHTML) you get the incorrect header and the browser interpret the page as XML instead of HTML, which of course introduce a much bigger issue.

Yes, that's correct.

The best solution, IMHO, is to move that to a data-* attribute attached to the input element

<input type="text" name="q" id="q" size="30" value="<?php echo $this->escape($this->query->input); ?>" data-serviceurl="<?php echo JRoute::_('index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component'); ?>" class="inputbox" />

and then read it in js through:

serviceUrl: document.getElementById('q').getAttribute('data-serviceurl'),

I have tested this item ✅ successfully on 8eccc84

tested @icampus
Compared with a validator. It works, Ampersand are escaped now.

@mehmetalipamukci no way: data-* is not a valid attribute in XHTML, if you are using HTML5 you dont' even need to enclose js code in CDATA at all.

no way: data-* is not a valid attribute in XHTML, if you are using HTML5 you dont' even need to enclose js code in CDATA at all.

right, sorry, forget data-* are HTML5 attributes.

but why use XHTML in the first place? Isn't it more or less discontinued?

@elpaso The result by @mehmetalipamukci is correct, he checked the link and in the link the ampersand is changed to it's HTML equivalent. I think you meant to mention @andrepereiradasilva instead.

I have tested this item ✅ successfully on 8eccc84

Before the patch the link contained regular & and after the patch this was changed to &

RTC