Wysiwyg Plugin

Features

• Supports the input of malformed HTML
• Full round-trip (TML -> XHTML -> TWiki syntax)
• Framework is editor-agnostic

Details

What's in the package

• TML (TWiki syntax) to HTML translator
• HTML to TML translator (with stand-alone script)
• Generic TWiki plugin for automating the translation during editing

How it works

The default rendering that TWiki uses to generate HTML for display in browsers is 'lossy' - information in the TWiki syntax is lost in the HTML output, and a round-trip (recovering the original TWiki syntax from the HTML) is impossible. To solve this problem the plugin instead uses its own translation of TWiki syntax to XHTML. The generated XHTML is annotated with CSS classes that support the accurate recovery of the original TWiki syntax.

Before you ask the obvious question, yes, the translator could be used to replace the TWiki rendering pipeline for generating HTML pages. In fact, the translator is taken almost directly from the implementation of the rendering pipeline for the TWiki-4 release

Translation of the HTML back to TWiki syntax uses the CPAN:HTML::Parser. This parser is used in preference to a more modern XML parser, because the WYSIWYG editor may not generate fully compliant XHTML. A strict parser would risk losing content. CPAN:HTML::Parser is better at handling malformed HTML.

There is also the advantage that the translator can be used to import HTML from other sources - for example, existing web pages. Due to the simple nature of TWiki syntax and the potential complexity of web pages, this translation is often lossy - i.e there will be HTML features that can be entered by editors that will be lost in this translation step. This is especially noticeable with HTML tables.

Using the translators from Perl scripts

Both translators can be used directly from Perl scripts, for example to build your own stand-alone translators.

Integrating a HTML Editor

1. The HTML for the content-to-be-edited can be generated directly in the standard edit template.

1. A URL can be used to fetch the content-to-be-edited from the server, for use in an IFRAME.
2. REST handlers can be called from Javascript to convert content.

1. User hits "edit".
2. Editor-specific plugin beforeEditHandler converts topic content to HTML by calling TWiki::Plugins::WysiwygPlugin::TranslateTML2HTML.
3. User edits and saves
4. Editor-specific plugin afterEditHandler converts HTML back to TML by calling TWiki::Plugins::WysiwygPlugin::TranslateHTML2TML.

• WysiwygPlugin should not be enabled in configure.
• WYSIWYGPLUGIN_WYSIWYGSKIN should not be set.
• Your plugin should set the textareas_hijacked context id, to signal to skins to suppress their textarea manipulation functions.

The flow of control is as follows:

1. User hits "edit" with the skin (or cover) set the same as WYSIWYGPLUGIN_WYSIWYGSKIN.
2. The WysiwygPlugin beforeEditHandler determines if the topic is WYSIWYG editable, and vetos the edit if not by redirecting to the standard edit skin. the edit
3. The edit template containing the JS editor is instantiated.
4. The following variables are available for expansion in the template:
   • %WYSIWYG_TEXT% expands to the HTML of the content-to-be-edited. This is suitable for use in a textarea.
   • %JAVASCRIPT_TEXT% expands to the HTML of the content-to-be-edited in a javascript constant.
5. User edits and saves
6. The afterEditHandler in the WyswiygPlugin sees that wysiwyg_edit is set, which triggers the conversion back to TML.

• The HTML form in the edit template must include an <input called wysiwyg_edit and set it to 1, to trigger the conversion from HTML back to TML.
• WYSIWYGPLUGIN_WYSIWYGSKIN must be set to the name of the skin used for WYSIWYG editing. This is usually the name of the editor e.g. kupu.

Fetching content from a URL

The flow of control is as follows:

1. When the document loads in the browser, the JS editor invokes a content URL (using an IFRAME or a XmlHttpRequest) to obtain the HTML document to be edited
   • The content URL is just a TWiki view URL with the wysiwyg_edit parameter set.
   • The WysiwygPlugin recognises the wysiwyg_edit parameter and uses the TML2HTML translator to prepare the text, which is then returned as text/plain to the browser.
   • Two TWiki variables, %OWEB% and %OTOPIC%=, can be used in the content URL in the edit template to refer to the source topic for the content.
2. After edit handling is as for Generating content directly in a specialised edit template

Other techniques

Asynchronous saves

Once the save script has completed it responds with a redirect, either to an Oops page if the save failed, or to the appropriate post-save URL (usually a view). The editor must be ready to handle this redirect.

Handling Attachments

• If the uploads are done in an IFRAME or via XmlHttpRequest, then the 302 redirect at the end of the upload can simply be ignored.
• You can pass noredirect to the upload script to suppress the redirect. In this case you will get a text/plain response of OK followed by a message if everything went well, or an error message if it did not.

REST handlers

The plugin defines the following REST handlers:

.../rest/WysiwygPlugin/html2tml?topic=Web.Topic;text=htmltexttotranslate

Converts the HTML text to TML. topic must be specified.

.../rest/WysiwygPlugin/tml2html?topic=Web.Topic;text=tmltexttotranslate

Converts the TML text to HTML. topic must be specified. The response is a text/plain page of converted content.

Plugin Installation Instructions

Like many other TWiki extensions, this module is shipped with a fully automatic installer script written using the BuildContrib.

• If you have TWiki 4.2 or later, you can install from the configure interface (Go to Plugins->Find More Extensions)
  • See the installation supplement on TWiki.org for more information.
• If you have any problems, then you can still install manually from the command-line:
  1. Download one of the .zip or .tgz archives
  2. Unpack the archive in the root directory of your TWiki installation.
  3. Run the installer script ( perl <module>_installer )
  4. Run configure and enable the module, if it is a plugin.
  5. Repeat for any missing dependencies.
• If you are still having problems, then instead of running the installer script:
  1. Make sure that the file permissions allow the webserver user to access all files.
  2. Check in any installed files that have existing ,v files in your existing install (take care not to lock the files when you check in)
  3. Manually edit LocalSite.cfg to set any configuration variables.

Plugin Configuration Settings

Translator control

• html - HTML tags (e.g. <div>, not including <br>), or
• variables - simple variables (e.g. %VAR%) or
• calls - TWiki variables with parameters e.g. %VARIABLE{...}%
• pre blocks (<pre>)
• HTML comments (<!-- ... -->)

If you excluded calls in WYSIWYG_EXCLUDE, you can still define a subset of TWiki variables that do not block edits. this is done in the global TWiki variable WYSIWYG_EDITABLE_CALLS, which should be a list of TWiki variable names separated by vertical bars, with no spaces, e.g: * Set WYSIWYG_EDITABLE_CALLS = COMMENT|CALENDAR|INCLUDE

You should set WYSIWYG_EXCLUDE and WYSIWYG_EDITABLE_CALLS in TWikiPreferences, or in WebPreferences for each web.

You can define the global variable WYSIWYGPLUGIN_STICKYBITS to stop the plugin from ever trying to convert specific HTML tags into HTML when certain specific attributes are present on the tag. This is most useful when you have styling or alignment information in tags that must be preserved.

This variable is used to tell the translator which attributes, when present on a tag, make it "stick" i.e. block conversion. For example, setting it to table=background,lang;tr=valign will stop the translator from trying to handle any table tag that has background or lang attributes, and any tr tag that has a valign attribute.

You can use perl regular expressions to match tag and attribute names, so .*=id,on.* will ensure that any tag with an on* event handler is kept as HTML.

The default setting for this variable is:

    .*=id,lang,title,dir,on.*;
    A=accesskey,coords,shape,target;
    BDO=dir;
    BR=clear;
    COL=char,charoff,span,valign,width;
    COLGROUP=align,char,charoff,span,valign,width;
    DIR=compact;
    DIV=align;
    DL=compact;
    FONT=size,face;
    H\d=align;
    HR=align,noshade,size,width;
    LEGEND=accesskey,align;
    LI=type,value;
    OL=compact,start,type;
    P=align;
    PARAM=name,type,value,valuetype;
    PRE=width;
    Q=cite;
    TABLE=align,bgcolor,border,cellpadding,cellspacing,frame,rules,summary,width;
    TBODY=align,char,charoff,valign;
    TD=abbr,align,axis,bgcolor,char,charoff,colspan,headers,height,nowrap,rowspan,scope,valign,width;
    TFOOT=align,char,charoff,valign;
    TH=abbr,align,axis,bgcolor,char,charoff,colspan,height,nowrap,rowspan,scope,valign,width,headers;
    THEAD=align,char,charoff,valign;
    TR=bgcolor,char,charoff,valign;
    UL=compact,type

If you edit using the plain-text editor, you can use the <sticky>..</sticky> tags to delimit HTML (or TML) that you do not want to be WYSIWYG edited.

Implementors note if you are using your own before/after edit handlers, you can call TWiki::Plugins::WysiwygPlugin::isWysiwygEditable() to check these controls.

Known issues

Incompatible with "non-standard" syntax

Overlapping styles

*bold _bold-italic* italic_

<strong>bold <em>bold-italic</em></strong> <em>italic</em>

*bold _bold-italic_* _italic_

Plugin Info

• ILOG
• Carrier Corporation