Extension:MeanEditor

Mean Editor is a lean-and-mean WYSIWYM (notice the M) editor based on WYMeditor. It is meant to complement traditional editing, instead of implementing the full Mediawiki language. Two versions are available: see below for details.

It provides non-technical and inexperienced users a way to contribute to a wiki while being:
 * easy to use
 * history-friendly
 * fair to existing hand-written code and edits
 * semantically correct, encouraging correct use of markup

Rationale
Advanced users and administrators do not need a visual editor. They just need it not to interfere with the code they already know and love. Moreover, expressing the full wikitext syntax in a visual editor is probably impossible.

We focused on the "easy", non technical, parts of a wiki. We estimate that a lot of Wikipedia content consists of simple paragraphs of text with links, references, images and a little formatting. This is where inexperienced editors can provide valuable contributions with little effort.

Usage cases
We designed MeanEditor with existing wikis (above all, Wikipedia) in mind. We hope the existing communities will find MeanEditor a good tool they can trust, rather than find annoying.

If no advanced features are needed, MeanEditor is a good choice even for a single-editor wiki.

Available versions

 * MeanEditor 0.5.3 : based on the current WYMeditor 0.5 beta. Supports all modern browsers (Internet Explorer support has many issues, all IE versions should be considered unsupported at the moment). Tested on MediaWiki 1.16.
 * MeanEditor 0.3.7 : based on an old stable release of WYMeditor. Browser support is limited to IE7 and Firefox. Integrates with MediaWiki 1.14 only.
 * Versions for MediaWiki 1.15 and 1.14 can also be downloaded : They are older versions of the 0.5 codebase.

The new 0.5.* version should work much better than the previous one, although it is based on beta code. The old version has a bit more eye-candy, though.

Installation using a downloaded file

 * 1) Install the recommended version of MediaWiki
 * 2) Unpack http://allievi.sssup.it/jacopo/MeanEditor/MeanEditor.tgz in the MediaWiki install directory. This will create extensions/MeanEditor directory.
 * 3) For image support: Disable $wgHashedUploadDirectory following the steps suggested in LocalSettings.php
 * 4) Add the following to LocalSettings.php:

Installation using github (recommended)
Cloning from our code repository will make it easier to upgrade to later versions.


 * 1) Install the recommended version of MediaWiki
 * 2) Go into the extensions directory of your MediaWiki installation.
 * 3) See http://github.com/jacopo/meaneditor and clone from it. The directory must be called "MeanEditor" See below for details.
 * 4) For image support: Disable $wgHashedUploadDirectory following the steps suggested in LocalSettings.php
 * 5) Add the following to LocalSettings.php:

The master branch has the most recent code. If the master code doesn't work for you, try looking for a mwNN branch (i.e. mw14 for MediaWiki 1.14.*, mw15 for 1.15 and so on).

Example commands: cd /directory/where/you/installed/mediawiki cd extensions/ git clone git://github.com/Jacopo/meaneditor.git MeanEditor

Details
MeanEditor is best described as "A quick and dirty hack with a couple of interesting properties". It supports only a very limited subset of the wiki language, but does its job right. (Well, it tries)

It is an adaptation of WYMeditor, a semantic editor for strict XHTML. This encourages users to think in terms of what they mean, instead of trying to change what they see.

MeanEditor refuses to modify markup it does not understand and strives to preserve the original page intact. Ideally, edits made with MeanEditor should be indistinguishable from manual edits. If anything, a visual editor for Wikipedia should not create additional work for administrators.

In the current version, redundant whitespace is sometimes removed and some characters are replaced with numerical entities. Other than that, MeanEditor leaves a very clean diff.

Supported markup
This list should certainly grow, but not indiscriminately. We feel wiki community should decide what should be implemented in the visual editor and what should be left out.

Right now we support

 * Headlines (== and ===)
 * Division in paragraphs
 * Page- and text-style wikilinks
 * [url] and [url text]-style external links
 * Images (with easy selection of recently uploaded images) with default positioning
 * Simple lists (no nesting)
 * Bold and italic
 * References (write support is very limited)
 * Superscripts and subscripts

To be implemented

 * Better reference support
 * Categories
 * Recognition of significant whitespace (i.e. code sections)
 * A way to specify image position and size
 * Preserving original code whitespace to leave a very clean diff (but some changes may be desirable, check what current bots automatically correct)
 * Make "Magic" links like http://www.example.com clickable?
 * Standard bibliography
 * Make magic text (_autonumber_, references_here, TOC, ...) visually stand out
 * LaTeX formula editing (TODO: just edit the LaTeX code? Or MathML for visual editing?)

To be implemented only for display

 * Templates

Known Bugs

 * Squeezes multiple newlines in one, does not preserve redundant whitespace (again, this may be a good thing)
 * Requires $wgHashedUploadDirectory to be off (should be easy to solve)
 * Context dialog doesn't work if you change selection (should it?)
 * Unsupported feature detection is simply draconic
 * Unnecessarily escapes characters like tilde in URLs and converts HTML entities (WYMeditor or browser problem?)
 * On IE6, wikilink detection can fail
 * Unicode handling is untested
 * Preview passes HTML to the editor. We try to convert it to wikicode as soon as possible, but some hooks or preview functions may be confused. If you are in the middle of a visual editing and something strange happens, we revert to traditional editing. There might be cases in which you get HTML instead of wikicode and have to start over. This should be a very rare case, but existing extensions need reviewing.
 * We got rid of most hardcoded paths, but we still require installation in extensions/MeanEditor. Also, short paths are untested (they should work, though).

Security
Saved text passes through usual Mediawiki checks.

However, it might be possible to create a malicious page in wikitext and have MeanEditor create dangerous HTML. Our regular expressions are simple, but they should be carefully reviewed before deploying.

Future?
Right now MeanEditor does not use the Mediawiki parser. This is what ensures MeanEditor doesn't do silly things with markup it does not understand.

We recognize our simple regular expressions will ultimately become too limited. A good solution would be to integrate an "editor mode" in the parser. The "editor mode" should generate semantic XHTML targeted to a WYSIWYM editor.

The code
MeanEditor used to require a patch to EditPage.php. To re-use an HTML editor, we need to add XHTML input support to MediaWiki. The current CustomEditor hook requires one to duplicate some functionality of EditPage.php, although the situation has improved a lot with the MediaWiki 1.16 release. Due to user feedback, we currently mantain the patch internally and ship ready-to-use code, we still plan to propose the patch to the Mediawiki developers someday. For now, we keep an eye on the Usability Survey.

MeanEditor is now hosted on GitHub, contributions are welcome.