Specifically, pages that may cause a big problem to the editor. These may include:

1. Pages with embedded HTML
2. Pages with embedded %VARIABLES

CN

---

There will always be pages that the plugin cannot accurately parse, due to the "macro" nature of TML, and the sheer complexity of HTML. Pages containing complex searches are expecially vulnerable.

The proposal is to support a switch, say WYSIWYGEXCLUDE. This can be set as, for example:

• Set WYSIWYGEXCLUDE = html,variables,calls

to disable wysiwyg editing on pages containing any HTML, %VARIABES% or %VARIABLES{}% in the source, or

• Set WYSIWYGEXCLUDE = calls

to allow embedded HTML and %SIMPLE% variables, or

• Set WYSIWYGEXCLUDE =

(the default) to allow editing of any page. This would be a Plugin variable that can be overridden on a per-user basis, so a user can

• Set WYSIWYGPLUGIN_WYSIWYGEXCLUDE =

if they want to take the risk.

• Set COMPOSER =

can still be used in pattern skin to disable wysiwyg totally on individual pages

CC

Implemented in SVN 8466

CC