Improved Edit handler

[dartar]

(source:  http://wikka.jsnx.com/EditHandler) The current edit handler has a number of issues:

1. Bad structure makes the code hard to understand and fix (see TimoK)
2. The function of some of the code is unclear - possibly it is never used and could (should) be eliminated
3. Various statements lead to notices because of reference to undefined variables
4. Indents consisting of (4) spaces are translated into tabs in only a limited number of cases (only the first group of 4 spaces at the start of a line, and not on the first line of the page (see Indenting not working properly in handlers/page/edit.php on WikkaBugs)
5. The code generated is not actually valid XHTML; in particular the <script> elements are not valid.
6. Unicode characters that were entered as Unicode characters (rather than as character or numeric entity references) are rendered as numeric entity references in the textarea when editing the page, making the text very hard to edit since it becomes essentially unreadable (this bug was actually introduced in version 1.1.6.0; see 1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit: on WikkaBugs)
7. There is also an issue with Unicode characters in code blocks (such as in comments!) being converted to numeric entity references but it's unclear for now whether this is caused by the edit handler or by the GeSHi code highlighting. (An example of this is (still) found in the SandBox - see also Missing language-support in the code formatter on WikkaBugs)
8. For some sites it's desirable to have the edit note be a required field; this is currently not supported (see Note on edit, mandatory field on SuggestionBox)
9. While registered users do have an option to set whether or not to use double-click editing, they cannot set a preference for using the WikiEdit toolbar. Since some people don't actually use the toolbar while this slows down editing, this really should be an option.
10. There is no way to indicate whether a page edit is "minor" (for instance, correcting a typo or a small change to layout without effectively changing the page content); minor changes should not be displayed in RecentChanges, and not broadcast in the RecentChanges RSS feed or WikiPing. Especially RSS feeds and WikiPing will be more valuable if they are not cluttered up with with irrelevant changes.

The code posted by JW addresses some of the above issues (3, 4, 5).

Related comments migrated from WikkaBugs

A page contains unicode characters looks OK when viewed but displays ""&#*****;"" while edited in WikiEdit Simplified Chinese Test:

中文是一种美丽的语言，除了具有音节上的美感，同样拥有视觉上的美感

In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php #from

<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />

#to

<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n

Wikka is wonderful! -- ZhuangYuyao

This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman

[CyneBeald]

I found a problem with the "workaround" suggested by Zhuangyuyao. htmlspecialchars_ent($body) assumes UTF-8 encoding, while the whole wikka pages are currently in iso-8859-1.

The problem will appear for non-ASCII characters that actually have an iso-8859-1 representation. My browser (FF) supports unicode, and automatically escapes characters not in the character set defined for the current page with HTML entities. So, for example, the word "scénář" becomes automatically scéná&#345; (the letters é and á are iso-8859-1 with the code 233 and 225 respectively, the letter is ř not).

When you use htmlspecialchars(), you get the problem with entities appearing in the edit field (FireFox already escaped characters not in the current codepage as entities (actually, they're called character references)).

Unfortunately, when you use $this->htmlspecialchars_ent() (which calls htmlspecialchars with the UTF-8 encoding), all characters that are not valid UTF-8 characters get stripped. Characters that were previously escaped by the browser are still intact, but some valid non-ascii characters from iso-8859-1 are removed (since they're not UTF-8).

The (temporary) solution is to supply $this->htmlspecialchars_ent() with the correct character set used for the pages (either explicitly, or by changing the default value in wikka.php).

[MasinAlDujaili]

Isn't this a double post of #10?

[NilsLindenberg]

Yes, it is. Dartar needs more coffee ;)

[DarTar]

ahum...Dartar needs more people around to help :p

[MasinAlDujaili]

Well, I'll do my best ...