WYSIWYG editor: Difference between revisions

For the more technically inclined, Wiki markup is a simple way of formatting a wiki page; it works. However, many would-be users of MediaWiki are put off by what looks to them -- rightly -- to be code of any sort. These users are adjusted to publishing and editing in a more visually straightforward WYSIWYG (What You See Is What You Get) environment.

Building WYSIWYG into MediaWiki could be greatly beneficial for current users and potential future users. The current editing technique, using HTML TEXTAREAs, can be either the fallback for those with older/text-based browsers or the default for users that prefer the fine level of control of wiki markup. The question of technical feasibility to adding a WYSIWYG option could be a blockade to coding it, and here is an introductory look at the technical side of things --

Modern GUI browsers, including Internet Explorer and Mozilla, have built-in functionality to use WYSIWYG editing features; however, the means of implementing that functionality varies per browser. Surmounting this obstacle might be greatly aided by any of several impressive open source, cross-browser WYSIWYG editors.

Technical feasability aside, letting users edit in a WYSIWYG input system has a number of advantages:

• The many would-be MediaWiki users who get scared off by complicated Wiki markup -- not to mention hairy HTML markup -- will have a familiar, word-processor-style interface to work with instead.
• You can see what an article will look like without previewing it. This will save round-trips to the server.
• We can use existing spell checkers (although there's a promising native wiki src spell checker (test wiki) with wiktionary- integration in development by archivist)
  • There are two other options for server side spell-checking
    • linuxquestions.org has released their spell checker
    • Another free one is available at spell checker
• Offline editing (possibly with something similar to Zope External Editor) is much easier
• It allows easy import for other open source texts and (potentially, with an appropriate script) images with copy&paste.

Conceptual

As noted above, HTML TEXTAREAS could be a fallback for older browsers or those that prefer this for fine control. The WYSIWYG editor could also be limited to reflect only existing wiki markup, with its democratically decided simplicities and compromises for complexities -- adding nothing to the wiki markup, only providing a more visually straightforward means of changing the markup....

Implementation

There are a few options for making a WYSIWYG editor that works in the browser.

1. Pure DHTML/Javascript. Capture mouse input, buttons, keystrokes, etc., and actually edit the HTML of the current document. It's not trivial, but possible. Epoz 1.0 is an example for this approach. Epoz and HTMLArea, the most prominent ones, are cross-browser - they iron out the subtle differences in the editing API between IE/Moz. This leaves all browsers not based on MSIE or Gecko (most notably Opera and KHTML (backend used by Konqueror and Apple's Safari browser)) as non-supported.
2. Create a custom browser plug-in, Java applet, ActiveX control. This would probably be workable, but would take quite a bit of hackery, and may or may not work. Requiring users to install any sort of plugin is very undesirable.
3. Both Mozilla and Internet Explorer include a way to make sections of a page editable. IE has the MSHTML Editing Platform, and Mozilla has its Rich Text Editing API. Both technologies allow Web developers to make parts of a page editable -- in slightly different ways, of course.

Most current in-browser WYSIWYG editors use the third option.

Proof of concept: Two WYSIWYG Editors

FCKEditor

An experimental implementation of FCKeditor into MediaWiki 1.5.3 is described here and can be downloaded from here.

TinyMCE

You can also download the following patch: http://www.logicsupply.com/pub/wysiwyg.patch.zip. This patch integrates TinyMCE into MediaWiki version 1.5.2. The TinyMCE source is included in the patch. I've added an option to the user preferences to enable or disable the editor on a per user basis. All HTML is converted to appropriate wiki markup before previewing/saving.

Limitations include:

• Links and images must still be specified using wiki markup
• Preformatted text (lines starting with whitespace) doesn't survive the trip to and from HTML
• Some features, like underline and strikethrough, have no effect.

If someone wants to hack TinyMCE to make these features work, they're more than welcome.

This implementation makes use of html2wiki, a trivial utility written in perl. Download the script, and put it in the $PATH somewhere (probably /usr/local/bin):

$ wget http://www.logicsupply.com/pub/html2wiki
$ sudo mv html2wiki /usr/local/bin

To use html2wiki, you will need the perl module HTML::WikiConverter. If you have CPAN installed, you can type:

# cpan
cpan> install HTML::WikiConverter
cpan> install HTML::WikiConverter::MediaWiki

Otherwise, you will need to download this module (as well as any dependencies) from the CPAN website. Please note that if you get no output on when previewing or saving you may need to specify the MediaWiki dialect. Find file includes/EditPage.php and edit the process description at the begining to be:

$html2wiki = 'html2wiki --dialect MediaWiki';

If you are using HTML::Converter v.0.52, you will need to pass an encoding type to html2wiki. Find file includes/EditPage.php and edit the process description at the begining to be:

$html2wiki = 'html2wiki --dialect MediaWiki --encoding=utf-8';

To use the patch, type at a command prompt:

$ wget http://www.logicsupply.com/pub/wysiwyg.patch.zip
$ unzip wysiwyg.patch.zip
$  mv wysiwyg.patch [WIKIROOT]
$ cd [WIKIROOT]
$ patch --backup -p0 < wysiwyg.patch

Watch the output of the patch command carefully, and make sure everything went smoothly.

Test the preview and save features as well as basic editing commands. If everything looks good, you may want to remove the backup files created by patch.

After patching you will need to install the images used for toolbar buttons from the latest TinyMCE editor download (download here). From the archive's jscripts subdirectory, copy the contents of the tiny_mce/themes/advanced/images and tiny_mce/plugins/table/images directories into the javascript subdirectory of your MediaWiki install. (Nothing else from the TinyMCE download is needed, so the rest can be discarded).

This patch is courtesy of Logic Supply. Please direct all emails regarding the patch to Forest Bond <forest@logicsupply.com>. Patch last modified 12/6/2005.

Please note, this patch is certainly not perfect. I suggest you use the option "Use wiki-style links in WYSIWYG." Please note, to create internal links using the TinyMCE interface, you should just set the URL to the page title you are trying to link to. This will only work, however, if the link text matches the link URL.

Note: This patch requires PHP 4.3.0 or later. You can make it work with 4.2.2 by changing the html2wiki function in EditPage.php to something like this:

function html2wiki($html)
{
  $html = "<html>\n<body>\n" . wysiwyg_preproc($html) . "</body>\n</html>\n";
  $tempfname = tempnam( '/tmp', 'mce' );
  $tempfile = fopen( $tempfname, 'w' );
  fwrite( $tempfile, $html );
  fclose( $tempfile );
  $pipe = popen( "html2wiki --dialect MediaWiki $tempfname", 'r' );
  while( ! feof( $pipe ) ) {
    $output .= fgets($pipe);
  }
  pclose( $pipe );
  unlink( $tempfname );
  return wysiwyg_postproc($output);
}

Using MediaWiki 1.5.3 on Linux I had to remove an empty line at the end of EditPage.php because I got error messages in the html user interface. Edit does work but after saving an empty page is stored.

Internal Links and Images

http://www.aulinx.de/hilfe/plone/bilder/bildeinfuegen.png

Epoz 0.74 features a great tool box to insert internal links and images. It's based on a search box, images are displayed with thumbnails and can be inserted with a single click. Inserting different image sizes is easy to do by customizing the tool box template. More documentation and screenshots (in german)

HTML to Wiki markup

Leveraging the power of existing html editing/spell checking tools makes it necessary to convert the produced html/xhtml to wiki markup.

If we manage to create a python or php script that converts simplified tidy output (xhtml) to wiki-code, this would be easy to do with epoz. Epoz 0.74 feeds the html through tidy on the server via xml-rpc when switching to source view and on save. This works great, it's Plone's standard editor- I used it to write the Squid document for example. Our conversion script can hook in after tidy, the source visible in 'source view' and submitted to the server would be wiki markup. All without reloading the surrounding page. Creating the conversion script is a challenge, but operating on tidy-cleaned xhtml should simplify matters. Epoz only allows structural markup (no font tags etc), so this is mainly a str_replace(). With the appropriate configuration tidy will strip the complex things first.

This setup combines the advantages of both worlds by providing two views switchable back and forth without reloading the page:

• WYSIWYG view: uses the default css and html editing
• SOURCE view: WIKI source

Possible problems

Things which need to be worked around include:

1. Displaying differences between italics and emphasis, bold and strong emphasis. Italics and bold are only used for articles on typesetting. (Technically mathematical formulae should use <var> but probably people are using <i> as it is shorter.)
2. Displaying formulae and potentially also music, maps, timelines, chess... allow editing?

   Perhaps MathML supporting browsers will be able to edit formulae

3. Displaying templates and allowing editing and inclusion of templates

   What about protected templates in a non-protected page? (Other similar combinations...)

   I have an idea. It would show up as a square box with the template name inside, and upon double-clicking a new tab would open (between the text box and formatting buttons) and allow editing of that template. This is a bit like handling of OLE objects in Microsoft Office.

4. Allow easy input other tags such as strikethrough, often used off the article namespace?
5. Displaying category links, interlanguage links?

• You can find a Wikipedia-WYSIWYG-extension for Emacs here: Wikipedia:Text_editor_support#Emacs

Other text-editors are covered in Wikipedia:Text_editor_support, too.

• List of all WYSIWYG editors. Table info about almost all WYSIWYG editors on the net.
• widgEditor. New! Small (32Kb) WYSIWYG editor where HTML can be swapped for wiki markup. Promising.
• A WYSIWYG editor at an existing wiki, opened to a test page.
• another WYSIWYG editor at a commercial "wiki farm" (www.seedwiki.com), opened to an existing page. Uses unmodified FCKeditor - may be converting back to wikitext.
• Epoz 0.74 is a cross-browser WYSIWYG editor for Zope, with xhtml cleanup (tidy via xml-rpc), source view, works with IE5.5+ and Mozilla, falls back to textarea otherwise. Uses Rich Text Editing API on moz. Demo- switch to source view with the checkbox in the bottom left corner
• Epoz NG (1.0), (now called Kupu) - next generation based on a different concept, currently under heavy development. Features native xhtml, async saving, propably xslt...
• FCKeditor
• HTMLArea 3 - works with IE5.5+ and Mozilla, falls back to textarea otherwise.
• Alternate site) is a BSD-licensed, cross-browser WYSIWYG editor. There's a good demo. Also features a spell checker plugin potentially useful for Epoz (Demo).
• Wiki:WysiwygWiki has some more links and discussion.
• WysiwygEdit on WikiFeatures (one working htmlarea demo, no wiki src editing)
• Rich Text Editing API is Mozilla's built-in WYSIWYG editor, the equivalent of IE5.5+'s 'Rich Text Editor'. There's a demo. Most Editors are based on these two mostly compatible editing APIs.
• Richtext Editor. Has lot of tools like "Insert Special Characters". IE only. Demo. License: LGPL ← DEADLINK
• Mozile -- New-generation in-browser editor for Mozilla
• HTML Parser for PHP -- a good candidate for inclusion in MediaWiki for parsing WYSIWYG editor output back to Wiki markup
• HTML->MediaWiki converter -- demo of the HTML::WikiConverter perl module
• HtmlDiff solutions
• Diderot - Demo for integrated Wikipedia editor - Win only
• WackoWiki [ru] -- Wiki engine with built-in WYSIWYG editor
• OSCOM Kupu -- Open Source Content Management: Kupu WYSIWYG XHTML Editor, easy to integrate and extend, uses CSS, BSD source code license
• KOIVI TTW HTML Editor - cross browser, cross platform - some Safari/412 support!
• MoinMoin (written in Python) just implemented an EXCELLENT WYSIWYG wiki editor. It's in their 1.5 beta now.
• WIKIWIG --A lite WYSIWYG Wiki based on HtmlArea3. GPL, developped in PHP, so lite and easy to set up.
• JotSpot wiki has an implementation of HTMLArea and is working to integrate the Dojo rich text editor
• Dojo Rich Text Editor The Dojo rich text editor supports inline editing as well as WYSIWYG
• AjaxWrite XUL based WYSIWIG editor, supports several file formats (RDF, PDF, MS-Word, etc); perhaps could be made to support WikiText

The HtmlArea 3.0 spell checker plugin: http://wp.aulinx.de/pics/htmlarea3_spellchecker.png