Skip to main content ↑ ↓
Preview in PM Started by Ruth · · Read 8463 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Re: Preview in PM

Reply #15 –

Still getting several PMs with the preview button but the charset problem seems to be fixed  :)
Thorsten "TE" Eurich
------------------------

Re: Preview in PM

Reply #16 –

me may have forgot to upload the code. O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: Preview in PM

Reply #17 –

Quote from: Spuds – Would you have to update all the xml to json ?  I don't know if  xml is going to handle all of utf8 stuff
Uh, XML is like the (initial) UTF-8 stronghold, lol. I reckon it's far more likely that some old version of PHP had issues with it. ;)

Edit: I just got nothing (white page) trying to submit this from preview. Could've been that a new reply had been posted while I was typing this.

Re: Preview in PM

Reply #18 –

QuoteUh, XML is like the (initial) UTF-8 stronghold, lol. I reckon it's far more likely that some old version of PHP had issues with it. ;)
Then I look forward to your PR where all that encoding is removed ;)

Re: Preview in PM

Reply #19 –

I thought @emanuele did that already. :P

Re: Preview in PM

Reply #20 –

Nope ... I had updated the code in 1.1 to use some built in "php to 8 bit" JS functions since we did not have to concern ourselves with older browser support. 

A couple of those calls were missed causing double encoding.  However if we feel that no encoding is required for 1/2/3/4 byte utf8 then cool, but that was not a step I took in my original PR.

Re: Preview in PM

Reply #21 –

It supposedlly shouldn't be for PHP 5.recent,  but I don't know enough about strings and characters in 5.older to say. It's just not XML that has the issues. ;)

Edit: posting from mobile and finally saw the loading... during quick edit!

Re: Preview in PM

Reply #22 –

Next time I'll be sure to read all the specifications before I ask a question  O:-) XML is the one.

Re: Preview in PM

Reply #23 –

My original idea (the one that I pushed) was to remove all the calls to php_to8bit from the js, and now I feel it was the way to go since from what I understood, Spuds added this to the urlencode function, and it seems to work! :)
I wouldn't touch for now anything else, just to avoid break something in some odd manner, though in 2.0 it may even be beneficial to consolidate all the AJAX calls passing through jQuery, so that we have to care only about how the jQuery developers decide to change the methods to call. LOL
Bugs creator.
Features destroyer.
Template killer.

Re: Preview in PM

Reply #24 –

I assume jQuery uses fetch with a fallback?

Re: Preview in PM

Reply #25 –

Note to self: jQuery.get() doesn't use fetch, probably nor should it.

@Spuds I don't really see any places where php_urlencode should be dropped? I mean, it's applied to URI components after all. And on the PHP side of things all I see is the correct filtering of a couple of disallowed characters:

Code: [Select]
function cleanXml($string)
{
	// http://www.w3.org/TR/2000/REC-xml-20001006#NT-Char
	return preg_replace('~[\x00-\x08\x0B\x0C\x0E-\x19\x{FFFE}\x{FFFF}]~u', '', $string);
}

Long story short, I set out to perform the cleaning you suggested and all I found was the php_urlencode() function itself.