Problem with html in wiki pages.
> From: Jeremy Butler mailto:email@example.com
> Sent: August 31, 2003 11:12 AM
> To: Marc Laporte
> Subject: Busted Tracker Form
> Oops. Looks like I busted the tracker form you made for DirectoryDev. It
> appears I don't have permission to enter HTML code into the Wiki
> editor. Consequently, when I "edited" it (actually, just looked at the
> code and made a small change) and saved it it didn't render the HTML code
> into Wiki code.
> Sorry about that, but it points out a problem that may happen if doc
> writers don't have HTML-coding permission.
Solution from Kristian Koehntopp (Isotopp)
On Sun, Aug 31, 2003 at 12:22:58PM -0400, Marc Laporte wrote:
> As we are eating our own DogFood, we are coming across problems as you had
> mentioned. (see below)
Yep, and my solution to this still stands.
1. Note with each Wiki page if the page contains elements that cannot
displayed in Wiki syntax. Call that flag "page needs HTML".
If set, the page can only be edited by people having "edit html
2. Even if the page does not contain HTML only elements, there
are still diverging syntaxes for writing for example
bold text: The Wiki syntax and the HTML tag syntax. Do store all
pages in a canonical syntax, for example using an XML tag
syntax that is largely compatible with XHTML.
If a page is being edited, see if the user has "edit html pages"
permission. If yes, present him the page in XHTML/XML syntax. If
not, present the page to him in Wiki syntax. That behaviour may
be overwritten by a user preference. If the user prefers Wiki
syntax, present all XML/XHTML elements for which there is a Wiki
syntax in Wiki shorthand. Everything else is shown as XML/XHTML.
On submit you must parse the page according to user preferences
into canonical format (XML/XHTML format) and store only
Do not try to be smart and do not parse Wiki syntax when the
user has selected "I prefer XML/XHTML syntax". You will get all
kinds of ambigous syntax problems if you try to be smart.
This is a major change to a fundamental part of your code base,
but implementing 1. and 2. it is the only way to steer clear of
that particular problem once and for all.
Related explanation from Kristian Koehntopp on WysiwygDev