Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
r1745 plugin edit form doesn't show non-ISO-8859-1 characters properly
If a plugin contains a UTF-8 character that does not exist in ISO-8859-1, the plugin edit form shows a questionmark instead of that character. If you don’t notice this and save again without putting the correct character back, that questionmark is saved. For plugins like zem_contact_lang which contain translation strings, this makes editing very difficult.
A possible fix would be to change line 144 in txp_plugin.php:
Old:
<code>$textarea = ‘<textarea id=“plugin-code” class=“code” name=“code” rows=“28” cols=“90”>’.htmlentities(utf8_decode($thing)).’</textarea>’;</code>
New:
<code>$textarea = ‘<textarea id=“plugin-code” class=“code” name=“code” rows=“28” cols=“90”>’.htmlspecialchars($thing).’</textarea>’;</code>
Because htmlspecialchars only replaces some 7-bit characters, it shouldn’t be a problem (UTF-8 encodes anything outside us-ascii using bytes that have the high-bit set).
Last edited by ruud (2006-08-21 18:54:08)
Offline
Re: r1745 plugin edit form doesn't show non-ISO-8859-1 characters properly
Unfortunately, r1749 does not fix this, because it still uses htmlentities instead of htmlspecialchars.
Try editing a plugin, add the word ‘êta’, save, then edit again. You’ll see that the letter ‘ê’ is gone and replaced by 2 characters.
This is caused by the fact that ‘ê’ is a 2 byte character in UTF-8, but htmlentities tries to escape all characters that have a known HTML character entity equivalent… based on a default charset that is ISO-8859-1 (1 byte per character). Those 2 bytes that form ‘ê’ in UTF-8 look like 2 separate ISO-8859-1 characters to the htmlentities function and are escaped separately.
The htmlspecialchars function doesn’t have this problem because it only replaces some characters (> < & “ ‘) in the us-ascii range (7-bit) of the charset which is the same in UTF-8 and ISO-8859-1.
The only other file that uses htmlentities is classTextile.php, but there the charset is explicitly set to UTF-8. In all other places in TXP the htmlspecialchars function is used.
Last edited by ruud (2006-08-27 17:29:07)
Offline