Difference: WysiwygPlugin (17 vs. 18)
Revision 182011-11-11 - TWikiContributor
Wysiwyg Plugin<-- Contributions to this plugin are appreciated. Please update the plugin page at http://twiki.org/cgi-bin/view/Plugins/WysiwygPlugin
On this page:
IntroductionSupport for the integration of WYSIWYG (What-You-See-Is-What-You-Get) editors. On its own, the only thing this plugin gives you is a stand-alone HTML to TWiki translator script. For WYSIWYG editing in TWiki, you will also need to install a specific editor package such as TWiki:Plugins/KupuEditorContrib or TWiki:Plugins/WikiwygContrib.
This plugin provides a generic framework that supports editing of TWiki topics using any browser-based HTML editor. It works by transforming TML (TWiki Meta Language) into HTML for the editor, and then transforming HTML back into TML on save.
Features
DetailsWhat's in the packageThe package includes the following pieces:
How it worksThe plugin works by translating the topic text into HTML when someone edits a topic. The HTML is then fed to the WYSIWYG editor. On save, the edited HTML is run through the reverse translation before saving to the topic. TWiki syntax is used in preference to HTML in the stored topic wherever possible, though HTML may be used if the translator can't find a suitable TML equivalent.. 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 scriptsBoth translators can be used directly from Perl scripts, for example to build your own stand-alone translators. A stand-alone converter script for HTML to TWiki is included in the installation. It can be found intools/html2tml.pl.
Integrating a HTML EditorThe plugin can be used to integrate an HTML editor in a number of different ways.
Generating content in standard edit templateThis is the technique used by WYSIWYG editors that can sit on top of HTML textareas, such as TinyMCE. The topic content is pre-converted to HTML before inclusion in the standard edit template. These editors use plugins that have abeforeEditHandler and an afterEditHandler. These handlers are responsible for the conversion of topic text to HTML, and post-conversion of HTML back to TML.
Generating content in specialized edit templateThis technique is useful when the editor requires the topic content in a variety of different formats at the same time. In this scenario the editor uses a custom edit template. The WYSIWYG content is made available for instantiation in that template in a number of different formats.WYSIWYGPLUGIN_WYSIWYGSKIN must be set for this to work.
The flow of control is as follows:
Fetching content from a URLIn this scenario, the edit template is generated without the content-to-be-edited. The content is retrieved from the server using a URL e.g. from anIFRAME.
The flow of control is as follows:
Other techniquesAsynchronous savesEditors can useXmlHttpRequest to perform saves, by POSTing to the TWiki save script with the wysiwyg_edit parameter set to 1. This parameter tells the beforeSaveHandler in the WysiwygPlugin to convert the content back to TML. See TWikiScripts for details of the other parameters to the save script.
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 AttachmentsAttachment uploads can be handled by URL requests from the editor template to the TWikiupload script. The upload script normally redirects to the containing topic; a behavior that you usually don't want in an editor! There are two ways to handle this:
REST handlersIf you are confident in Javascript you can use REST handlers withXmlHttpRequest to convert content from TML to HTML and back again.
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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| < < | Note: You do not need to install anything on the browser to use this extension. The following instructions are for the administrator who installs the extension on the TWiki server. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Plugin Configuration SettingsTranslator controlWYSIWYG_EXCLUDE - Prevent WYSIWYG editingThe global preference settingWYSIWYG_EXCLUDE can be set to make the plugin sensitive to what is in a topic, before allowing it to be edited. The comma separated list to fall back to text edit can include:
WYSIWYG_EDITABLE_CALLS - Exceptions to WYSIWYG_EXCLUDEIf you excludedcalls in WYSIWYG_EXCLUDE, you can still define a subset of variables that do not block edits. this is done in the global preference setting WYSIWYG_EDITABLE_CALLS, which should be a list of 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.
WYSIWYGPLUGIN_PROTECT_EXISTING_TAGS - Protect specific tags originally in the topic textTheWYSIWYGPLUGIN_PROTECT_EXISTING_TAGS preference tells the translator that certain HTML tags which were originally in the topic text should remain as HTML tags; the translator will not try to convert them to TML. This protects the tags themselves, and not the contents enclosed between the <tag> and </tag>
The default setting for this preference is defined within the plugin. It corresponds to div, span.
This feature may be disabled by setting the preference to a single comma. This does not guarantee that HTML markup will be removed; the conversion of HTML tags to TML markup remains subject to the other controls provided by the WysiwygPlugin, including the WYSIWYGPLUGIN_STICKYBITS preference, <sticky> blocks, <literal> blocks and the rules applied to tables and lists.
WYSIWYGPLUGIN_PROTECT_TAG_BLOCKS - Protect specific tag blocks originally in the topic textTheWYSIWYGPLUGIN_PROTECT_TAG_BLOCKS preference tells the translator that certain HTML tag blocks which were originally in the topic text should remain as HTML blocks; the translator will not try to convert them to TML.
The default setting for this preference is defined within the plugin. It corresponds to script, style.
As an example, individual html tables can be protected by surrounding them with <sticky> .. </sticky> block. However,if you want to have all =<table> markup preserved as entered into topics by default, rather than subject to WYSIWYG editing, add =table to this list, and =<table> markup will become
automatically sticky.
This feature may be disabled by setting the preference to a single comma.
WYSIWYGPLUGIN_STICKYBITS - Protect tags based upon their argumentsYou can define the global preferenceWYSIWYGPLUGIN_STICKYBITS to stop the plugin from ever trying to convert specific HTML tags into TML 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 preference setting is used to tell the translator which attributes, when present on a tag, make it "stick" i.e. block conversion back to TML. For example, setting it toThis setting is used only after the page has been processed by the editor. If the editor does not support a particular tag or attribute and the editor corrupts the tag, this setting will not be helpful. It is only used to prevent an HTML tag from being converted back to TML. Format of the setting is tag1=attrib,attrib;tag2=attrib. Attributes delimited by comma, and tags delimited by semicolon.
.*=id,on.* will ensure that any tag with an id or on* event handler is kept as HTML.
The default setting for this preference are hard coded in the plugin. If you wish to change the settings, the following list is the default setting coded in the plugin:
* Set WYSIWYGPLUGIN_STICKYBITS =
(?!IMG).*=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,style;
DL=compact;
FONT=size,face;
H[0-9]=align;
HR=align,noshade,size,width;
LEGEND=accesskey,align;
LI=value;
OL=compact,start,type;
P=align;
PARAM=name,type,value,valuetype;
PRE=width;
Q=cite;
TABLE=align,bgcolor,frame,rules,summary,width;
TBODY=align,char,charoff,valign;
TD=abbr,align,axis,bgcolor,char,charoff,headers,height,nowrap,rowspan,scope,valign,width;
TFOOT=align,char,charoff,valign;
TH=abbr,align,axis,bgcolor,char,charoff,height,nowrap,rowspan,scope,valign,width,headers;
THEAD=align,char,charoff,valign;
TR=bgcolor,char,charoff,valign;
UL=compact,type
<-- %JQREQUIRE{"chili"}%
(?!IMG).*=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,style;
DL=compact;
FONT=size,face;
H[0-9]=align;
HR=align,noshade,size,width;
LEGEND=accesskey,align;
LI=value;
OL=compact,start,type;
P=align;
PARAM=name,type,value,valuetype;
PRE=width;
Q=cite;
TABLE=align,bgcolor,frame,rules,summary,width;
TBODY=align,char,charoff,valign;
TD=abbr,align,axis,bgcolor,char,charoff,headers,height,nowrap,rowspan,scope,valign,width;
TFOOT=align,char,charoff,valign;
TH=abbr,align,axis,bgcolor,char,charoff,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 issuesIncompatible with "non-standard" syntaxWysiwygPlugin is incompatible with plugins that expand non-standard syntax e.g. TWiki:Plugins.MathModePlugin (WysiwygPlugin)
Plugins that extend the syntax using TWiki variables, such as %MYVARIABLE%, should work fine.
Overlapping stylesBecause TWiki uses a "best guess" approach to some formatting, it allows overlapping of tags in a way forbidden by HTML, and it is impossible to guarantee 100% that formatting in the original TWiki document will still be there when the same document is loaded and then saved through the WysiwygPlugin. The most obvious case of this is to do with styles. For example, the sentence*bold _bold-italic* italic_is legal in TML, but in HTML is represented by <strong>bold <em>bold-italic</em></strong> <em>italic</em>which gets translated back to TML as *bold _bold-italic_* _italic_which is correct by construction, but does not render correctly in TWiki. This problem is unfortunately unavoidable due to the way TWiki syntax works. Plugin InfoMany thanks to the following sponsors for supporting this work:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| < < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| > > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
View topic | History: r22 < r21 < r20 < r19 | More topic actions...
Copyright © 1999-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback
Note: Please contribute updates to this topic on TWiki.org at TWiki:TWiki.WysiwygPlugin.