This patch add charset argument for htmlentities function.
"htmlentities($text)"
replace to
"htmlentities($text,ENT_COMPAT,get_string("thischarset","moodle"))"
Whithout this PLAIN_TEXT resurses is corrupt if used non ISO-8859-1.
This method can be used and in WIKI
More this http://www.php.net/manual/ru/function.htmlentities.php.
Patch for charset encoding bug in weblib.php (1.4.3+)
Number of replies: 5
Re: Patch for charset encoding bug in weblib.php (1.4.3+)
Hi Alex,
some days ago I was examining this function to use it in another place (inside Moodle, of course
). And, although it seems to be perfect for non ISO charsets, I found that such parameter was relatively new and only works under PHP 4.3.x, what is over Moodle's supported PHP versions. Perhaps, some day, such req. should go up?
Ciao
some days ago I was examining this function to use it in another place (inside Moodle, of course
Ciao
Re: Patch for charset encoding bug in weblib.php (1.4.3+)
Eloy,
actually I think it's within Moodle's required versions... see
http://nz2.php.net/htmlentities indicates 4.1.0, which is the same version that Moodle requires.
Being charset aware is good, specially as PHP treats UTF8 (somewhat naively) as a charset, at least for these functions.
ASCII is such a limited view of the world...
actually I think it's within Moodle's required versions... see
http://nz2.php.net/htmlentities indicates 4.1.0, which is the same version that Moodle requires.
Being charset aware is good, specially as PHP treats UTF8 (somewhat naively) as a charset, at least for these functions.
ASCII is such a limited view of the world...
Re: Patch for charset encoding bug in weblib.php (1.4.3+)
Ah, there I read this: "following character sets are supported in PHP 4.3.0 and later." so I assumed that those charsets weren't available (I don't know which exact charserts were available in 4.1), that was the cause of my doubts... and if the function, the parameter and some charsets (unknown!) exist in previous versions, how can we check it? If solved (previous versions) I agree 100% about such change!
And yes, ASCII is a limited view of the world, like the world is a limited view of the universe.
Ciao
And yes, ASCII is a limited view of the world, like the world is a limited view of the universe.
Ciao
Re: Patch for charset encoding bug in weblib.php (1.4.3+)
Yes, I see that table -- puzzling, sounds like 4.1.0 implements the option but doesn't support any charsets, or something close to that.
If it doesn't recognize the charset, it'll fail 'softly' -- this is both a good and a bad thing:
- we can actually use the parameter (and I believe we should)
- we cannot be certain of whether it's doing something
We could add some logic when loading the language packs -- or when the admin selects language packs -- to compare charsets and PHP versions and warn the admin.
It's really nasty that there doesn't seem to be a way to query PHP and for its supported charsets.
If it doesn't recognize the charset, it'll fail 'softly' -- this is both a good and a bad thing:
- we can actually use the parameter (and I believe we should)
- we cannot be certain of whether it's doing something
We could add some logic when loading the language packs -- or when the admin selects language packs -- to compare charsets and PHP versions and warn the admin.
It's really nasty that there doesn't seem to be a way to query PHP and for its supported charsets.
Re: Patch for charset encoding bug in weblib.php (1.4.3+)
As a general note, it's OK to implement new functions if they are really useful, as long as something is provided to keep Moodle working when the function isn't available. eg see stripos() in weblib.php