Patrick kindly took the time to let me know about an issue with my Share This plugin for WordPress: apostrophes/single-quotes in post titles break things.
The thing is, the string looks fine in the source. The title:
This title's got an apostropheis turned into:
This+title%27s+got+an+apostrophejust as I’d intended.
What I didn’t realize was that the browser would decode the URL string and allow the %27 to behave as a ', thus breaking the JavaScript string that was enclosed in ' marks.
I’m not sure what to make of this – the JavaScript string is perfectly valid on its face, there is no single quote in the string to backslash/escape, yet the browser’s url-decoding seems to create the problem.
A little more research shows this to only be a problem if the string is in the href attribute. If I put the string in an onclick attribute, everything is hunky-dory1.
Any web or browser developers out there that can enlighten me on this one? Perhaps this is standard documented behavior and I need to handle the string in a different manner? Perhaps it’s a known bug with a good work-around?
I eagerly await waking in the morning to your sympathetic sentiments, stinging criticism and lambasting in the comments. 😉
- Which looks like a suitable work-around, but I’d still like to understand how and why this works as it does. [back]
Hi
😉 nothing “honkey donkey” googlebot doesn’t like links with ‘onclick’ 😉
regards
Monika
I don’t understand much from Javascript, but you may try ” ’ “, how about that?
The browser first ‘urldecodes’ the attribute, then evaluates it, so the ‘%27’ gets turned into a single quote before JS even sees it.
Just use JavaScript escaping – turn any ‘ into \’.
(This works because \ has no special meaning in HTML.)
Of course, these should be simple apostrophes 😉
I am pretty sure that is how it’s supposed to be 😉 As Matthias wrote, the browser decodes the string before it passes it on to javascript, which is also why this works:
href=”javascript:%76%6f%69%64%28%61%6c%65%72%74%28%27%48%65%6c%6c%6f%20%57%6f%72%6c%64%21%27%29%29″
Note what you can’t encode “javascript:” as that is a link further down the parsing – Protocol first, then decode the rest, I guess 🙂
The thing of it is, yes that is right, you do need to escape and encode, and then decode and unescape if you get my drift. So in the end %27 will be %5C%27 so not only does it validate correctly but it also encodes, and escapes to get passed correctly. But once it hits the actual Javascript part it needs to be decoded (possibly might still be encoded) and then unescaped, because it if isnt you will have issues.
I fixed the script and added a little bit of eye candy to it, hope you don’t mind.
Post about it:
http://v1.ghettopixe[...]x-king.xhtml
Download it:
http://v1.ghettopixe[...]are-this.zip
Interesting choice to edit and re-release version 1.1 when version 1.2 (which no longer has this problem) has been out for nearly a week.
Besides, shouldn’t we use encodeUri() and encodeUriComponent() instead of encode()? encode is AFAIK not charset-safe…
Those are JavaScript functions (and you mean encodeURIComponent()), this is referencing PHP code.
I did use version 1.2. Again mate, if you have a problem with me trying to help then please do let me know I have no problem retracting my post and download.
No problem – perfectly allowable under the license I choose. But since there was no problem with the url encoded strings anymore in 1.2, I’m curious as to what you “fixed” there. Your post previously said you had modified version 1.1, which did have this problem.
That was a mistake of confusion on my behalf, I had guessed based on my download that it still had this problem, but after comparing what I did to what you had, you did fix it, I simply moved it, not thinking correctly (obviously) back to HREF and then encoded and slashed it so it would work there. Then added a decode and de-slasher function to the Javascript class so it could be corrected before entering into the world of Javascript. What I thought I corrected was already corrected (get more sleep to me) and I am assuming now all I did was class it up and then tweak it out.
[…] Titles with apostrophes work properly. […]