• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7700 for generic doc work for TWiki-6.0.2. Use View topic Item7703 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item4945: making "Edit" button smart

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension TinyMCEPlugin Enhancement Closed Anyone interested in a raw/wysiwyg switch n/a  

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


Let me propose a way to make TinyMCEPlugin more flexible. The goals are:
  1. Doing without "Raw edit" link. In another word, the "Edit" button should be smarter.
    • When you create a new page, you cannot explicitly specify "Raw edit". This is also the case when you edit a part of a page using MultiEditPlugin.
  2. One can switch between WYSIWYG and raw text edit by one click.
    • There are cases where you want to switch from raw text to WYSIWYG and vice versa in the middle of editing
  3. The last edit mode is rememberd and followed next time.
  4. Make graceful transition from raw text edit to WYSIWYG edit possible.
    • If there is a large user base, changing "Edit" button's default behavior all of a sudden is not desirable and often not acceptable. There needs to be a way to keep the default behavior, but users can switch to WYSIWYG editor easily.
    • At the same time, it's better to provide a brand-new web with the option of WYSIWYG-edit-by-default.
  5. To accomodate the following user preference: wanting to use raw text edit most of the time and use WYSIWYG edit only occasionally. After WYSIWYG editing, the "Edit" button is to lead to raw text editing.

To these ends, I'd propose to introduce the following things:

  • wysiwyg URL parameter

These are use by the following patch. This is to enhance _notAvailable()

--- lib/TWiki/Plugins/TinyMCEPlugin.pm  2007-10-21 19:53:08.000000000 +0900
+++ lib/TWiki/Plugins/TinyMCEPlugin.pm.patched  2007-11-02 15:05:03.000000000 +0900
@@ -73,6 +73,22 @@
     return 'Unsupported browser: '.$query->user_agent()
       if $ua && $query->user_agent() && $query->user_agent() =~ /$ua/;
+    return 0 if $query->param('wysiwyg');
+    my $avoidVar = TWiki::Func::getPreferencesValue('TINYMCEPLUGIN_AVOID')
+       || 'off';
+    return " " if lc $avoidVar ne 'off';
+    my $disableCookie = $query->cookie('TINYMCEPLUGIN_DISABLE') || '';
+    if ( $disableCookie ne '' ) {
+       $disableCookie ||= 'off';
+       return lc $disableCookie ne 'off' ?
+           "Disabled by TINYMCEPLUGIN_DISABLE cookie" : 0;
+    }
+    my $defaultVar = TWiki::Func::getPreferencesValue('TINYMCEPLUGIN_DEFAULT')
+       || 'off';
+    return "Disabled by TINYMCEPLUGIN_DEFAULT variable"
+       if lc $defaultVar eq 'off';
     return 0;
The logic behind the code is as follows.

  • The last edit mode is remembered in the TINYMCEPLUGIN_DISABLE cookie. The cookie works in the similar manner as the TINYMCEPLUGIN_DISABLE variable. The edit template needs to be enhanced so that the cookie's value is set appropriately.
  • The wysiwyg URL parameter makes sure WYSIWYG edit happens as long as possible. Given the additional variables and a cookie, this URL parameter is handy.
  • The TINYMCEPLUGIN_AVOID variable is for the goal 5. Such a user would set TINYMCEPLUGIN_AVOID 'on' on their personal page.
  • The TINYMCEPLUGIN_DISABLE cookie is examined after the TINYMCEPLUGIN_AVOID variable is examined.
  • The TINYMCEPLUGIN_DEFAULT variable is for the goal 4. A TWiki site owner aiming for graceful transition would set the variable 'off' on Main.TWikiPreferences or TWiki.TWikiPreferences.
Given the patch, "Edit" button would meet a user's need and taste much more often than otherwise. And in most cases, you can do without Raw edit link.

-- TWiki:Main/HideyoImazu - 09 Nov 2007

Hmmm, interesting. I think understand your goals, but I'm concerned that the patch makes the behaviour of the editor very unpredictable and very difficult to set up, espcially when we already have controls like WYSIWYG_EXCLUDE. You would have to have a go at writing the user documentation before I could consider merging it. Some questions:

  • Why is TINYMCEPLUGIN_AVOID different to the existing TINYMCEPLUGIN_DISABLE?
  • Why is TINYMCEPLUGIN_DEFAULT any different to just appending/deleting ?nowysiwyg=1 in the templates?
  • Personally I'd get really annoyed at the "sticky" edit mode....


I agree with Crawford here.

Yes it is annoying that we cannot create a page and instantly be in Raw Edit (typically when you want to create a copy of another advanced topic).

But having a feature "The last edit mode is remembered and followed next time" is going to be more confusing than being helpful.

It has to be predictable what mode you end up in. The Wysiwyg editing is not for the geeks but for the "normal" people. This is also why the Edit is now per default Wysiwyg.

A guy that submits a patch here with with some Perl code is a geek. Meant in a positive spirit. You are among geeks here smile

But the normal users do not understand any of this. They need a UI which is predictable.

From 4.2 editing means editing for normal people. And Edit Raw is for the advanced that needs to make a TWiki application. This is very generalized and in practical we are all a little normal and a little geek.

I think it is better to address the original issue. How do you create a new topic and start in Edit Raw mode - when you desire to? And without confusing the less geeky users.

And the other wish is "how to change from Wysiwyg editing to Raw Editing in ONE CLICK". And again without confusing the less geeky users.

And maybe especially the latter is not easy to do without causing confusion and then we geeks can live with having to do two clicks: "Save and Edit Raw".

We have spent significant time doing the new Wysiwyg editor a good experience for our normal users (99% of our users). We have to take care not to make a feature for the 1% users that screw up the user friendliness for the 99%.

-- TWiki:Main.KennethLavrsen - 10 Nov 2007

Crawford and Kenneth, thank you for your comments. I'm thinking about it more and I need a few more days to finish my thinking. Could you please wait a little while?

But there is one thing I'd like mention now. This patch doesn't prevent the current develop.twiki.org behavior. If none of the variables, URL param, cookie mentioned above are set, then the patched TinyMCEPlugin behaves in the same manner as unpatched.

A desirable configuration depends on users. I have literally hundreds of long term TWiki users who are all used to raw text editing. I'm pursuing a way to meet their needs keeping develop.twiki.org behavior intact.

-- TWiki:Main.HideyoImazu - 12 Nov 2007

After thinking about it more, I'd propose to introduce the following variables and cookie.

  • the wysiwyg URL parameter

They are made use of by the following patch.

--- lib/TWiki/Plugins/TinyMCEPlugin.pm  2007-11-09 03:36:37.000000000 +0900
+++ lib/TWiki/Plugins/TinyMCEPlugin.pm.patched  2007-11-12 18:09:46.000000000 +0900
@@ -73,6 +73,25 @@
     return 'Unsupported browser: '.$query->user_agent()
       if $ua && $query->user_agent() && $query->user_agent() =~ /$ua/;

+    return 0 if $query->param('wysiwyg');
+    my $preferredVar =
+       TWiki::Func::getPreferencesValue('TINYMCEPLUGIN_PREFERRED') || '';
+    if ( $preferredVar ne '' ) {
+       $preferredVar ||= 'off';
+       return lc $preferredVar ne 'off' ?
+           0 : "Disabled by TINYMCEPLUGIN_PREFERRED variable";
+    }
+    my $preferredCookie = $query->cookie('TINYMCEPLUGIN_PREFERRED') || '';
+    if ( $preferredCookie ne '' ) {
+       $preferredCookie ||= 'off';
+       return lc $preferredCookie ne 'off' ?
+           0 : "Disabled by TINYMCEPLUGIN_PREFERRED cookie";
+    }
+    my $defaultVar = TWiki::Func::getPreferencesValue('TINYMCEPLUGIN_DEFAULT')
+       || 'off';
+    return "Disabled by TINYMCEPLUGIN_DEFAULT variable"
+       if lc $defaultVar eq 'off';
     return 0;
If those variables and cookie are not set, TinyMCEPlugin behaves in the same manner as unpatched. If you like the way develop.twiki.org behaves, you can implement it even with this patch applied. You don't have to change any configuration for that.

Here's how TinyMCEPlugin documentation would look if this patch was integrated.

Control WYSIWYG vs raw text editing

There are several TWiki variables, URL parameters, and cookie you can set to control the Edit button's behavior in terms of picking WYSIWYG or raw text editing. The same logic is employed to pick an editor when a new page is created. Below is how the plugin decides which way to go.

Even if WYSIWYG editing is selected by the logic described below, still there is a possibility for WYSIWYG not to be used. After examining those factors, whether or not WYSIWYG is applicable against the topic content is determined. The logic described in this section is independent from the content and still not the final decision.

In the description below, "true" means any string other than "", "off", or "0". "false" means "off" or "0".


There are two variables determining edit mode.

If it's true, then raw text editing is used regardless of other factors. This variable may be referred to by an edit page to determine whether or not to put "WYSIWYG edit" button.
This is to be set at the site level, the web level, the user level, or the page level. For example:
  • If you have a JavaScript code on a page, you need to set this variable to true at least on the page. Because the WYSIWYG editor breaks JavaScript code in most cases.
  • If you want avoid WYSIWYG editing completely, you would set it true on your personal page.
If it's set, edit mode is determined by this variable. If it's not set, other factors are considered. If it's true, WYSIWYG editing is used. Otherwise, raw text editing is used.
This is primarily for personal preference setting.
If you prefer raw text editing but sometimes you use WYSIWYG editing, then you would set this variable to false. Unlike TINYMCEPLUGIN_DISABLE, it doesn't suppress a "switch to WYSWIYG" button which may be put on an edit page.
If you prefer WYSIWYG editing, then you would set this variable to true. This is useful if your edit page employs the edit mode stickiness feature mentioned below.

Gradual introduction of WYSIWYG editing

Let's assume you have a lot of users who are used to raw text editing. If WYSIWYG editing is introduced as the default of the Edit button, a lot of them may complain. One way to introduce WYSIWYG editing to such an environment is:

  • Keep raw text editing as the default of the Edit button
  • Have a "WYSIWYG edit" button on the raw text edit page so that it can be switched to WYSIWYG by one click.
  • Have a "raw text edit" button on the WYSIWYG edit page which works similarly to "WYSIWYG edit" button.
    How to implement those buttons is described below.

This way, existing users can keep using raw text editing as before, and they have easy access to WYSIWYG editing.

For the edit mode switching to work, the "nowysiwyg" and "wysiwyg" URL parameters are referred to determine edit mode. This happens before referring to the TINYMCEPLUGIN_PREFERRED variable.

  • The WYSIWYG edit button on the raw text edit page would put wysiwyg=1 as a parameter.
  • The raw text edit button would put nowysiwyg=1 as a parameter.

Some users would find WYSIWYG editing preferable. For them, switching to WYSIWYG every time they edit is cumbersome. They can set the TINYMCEPLUGIN_PREFERRED variable (mentioned above) on their personal page, but some of them may not know how to do it or don't bother to do it.

It may be nice to record the last edit mode in a cookie. The TINYMCEPLUGIN_PREFERRED cookie is used for that. The WYSIWYG edit button on the raw text edit page would set the TINYMCEPLUGIN_PREFERRED cookie to true. And the raw text edit button on the WYSIWYG edit page would set the cookie to false.

The TINYMCEPLUGIN_PREFERRED cookie is referred to if both of the "nowysiwyg" and "wysiwyg" URL parameters are false and the TINYMCEPLUGIN_PREFERRED variable is not set. If the cookie is set, edit mode is determined by the value in the same manner as the TINYMCEPLUGIN_PREFERRED variable.

If the cookie is not set, the TINYMCEPLUGIN_DEFAULT variable is referred to. If it's set to false, raw text editing is used.

Otherwise, WYSIWYG editing is used.

The TINYMCEPLUGIN_DEFAULT variable is meant to be set to false as the site wide setting if WYSIWYG editing is introduced gradually as described so far. Even on such a TWiki site, a web can set the variable to true to make its default edit mode WYSIWYG leaving users choices to use either edit mode.

If the TINYMCEPLUGIN_PREFERRED variable is set at the web level, then the edit mode stickiness by cookie is not observed on the web because the cookie is referred to only if the variable is not set.

Providing edit mode stickiness or not is up to a TWiki site owner. If you think it does more harm than good making editing behavior less predictable, then you wouldn't have the cookie setting feature associated with the the "WYSIWYG edit" and "raw text edit" buttons on the edit pages.

In summary

Here's the summary of variables concerning edit mode:

precedence name typical places purpose
1 TINYMCEPLUGIN_DISABLE WebPreferences, individual pages forbid WYSIWYG editing
2 TINYMCEPLUGIN_PREFERRED users' personal pages set user's editor preference
3 TINYMCEPLUGIN_DEFAULT TWikiPreferences, WebPreferences set raw text editing the default by setting it to false

If non of these variables are set, WYSIWYG editing is used.

And here's a compact but comprehensive description of how edit mode is determined:

  1. If TINYMCEPLUGIN_DISABLE variable is true, then raw edit editing is used. Otherwise, continue to the next step.
  2. If the nowysiwyg URL parameter is true, then raw edit editing is used. Otherwise, continue to the next step.
  3. If the wysiwyg URL parameter is true, then WISYWIG editing is used. Otherwise, continue to the next step.
  4. If the TINYMCEPLUGIN_PREFERRED variable is set, editor picking ends here. Otherwise, continue to the next step. If it's true, WYSIWYG editing is used. Otherwise, raw text editing is used.
  5. If the TINYMCEPLUGIN_PREFERRED cookie is not null, editor picking ends here. Otherwise, continue to the next step. If it's true, WYSIWYG editing is used. Otherwise, raw text editing is used.
  6. If the TINYMCEPLUGIN_DEFAULT variable is set and not true, then raw text editing is used.
  7. Otherwise, WYSIWYG editing is used.

"WYSIWYG edit" button and "raw text edit" button on the edit pages

This is not part of the plug-in, but you can customize your edit skin as follows for convenience. It's to introduce buttons to switch between WYSIWYG editing and raw text editing by one click. I'm using this enhancement on TWiki 4.1.2's pattern skin.

First, add the following template element to edit.pattern.tmpl

<script type="text/javascript">
function switchPlainRich(plain) {
    var cookieValue;
    var urlParamName;
    if ( plain ) {
        cookieValue = "off";
        urlParamName = "nowysiwyg";
    else {
        cookieValue = "on";
        urlParamName = "wysiwyg";
    // cookie setting for edit mode stickiness
    var now = new Date();
    var oneYearLater = new Date(now.getTime() + 1000 * 86400 * 365);
    document.cookie = "TINYMCEPLUGIN_PREFERRED=" + cookieValue + ";" +
        "expires=" + oneYearLater.toGMTString();
        // you may add path and domain here e.g.
        //   + ";path=/twiki;domain=something.com";
    var editparams = document.main.editparams.value;
    var anchor = '';
    var result = editparams.match(/^([^#]*)(#.*)$/);
    if ( result != null ) {
        editparams = result[1];
        anchor = result[2];
    document.main.editparams.value = editparams + "&" + urlParamName + "=1" +
    var elem = document.createElement("input");
    elem.setAttribute("type", "hidden");
    elem.setAttribute("name", "action_checkpoint");
    elem.setAttribute("value", "switch");
%IF{"context textareas_hijacked"
then="<input type='button' class='twikiButton' id='plaintextedit' value='Raw text edit' onclick='switchPlainRich(1)' />"
  else="<input type='button' class='twikiButton' id='richtextedit' value='Rich text edit' onclick='switchPlainRich(0)' /> (May not switch to rich text edit depending on the content of the page)"}%"

Then put the element somewhere on the page. I put it next to the force version check box.

And add the following line to the formend template element:

<input type="hidden" name="editparams" value="%IF{"defined EDITPARAMS" then="%EDITPARAMS%"}%" />

By extending the edit template, "WYSIWYG edit" button or "Raw text edit" button is displayed depending on situation. Those buttons work like the checkpoint button, but at the same time switches edit mode.

When you switch edit mode by the buttons, the specified mode is reflected in the TINYMCEPLUGIN_PREFERRED cookie. This is to implement edit mode stickiness mentioned in the previous section. If you don't want the stickiness, you would delete the cookie setting part from the JavaScript code. </verbatim>

-- TWiki:Main.HideyoImazu - 13 Nov 2007

I still find this proposal over-complicated. Normal users will not understand it.

On the TWiki:Codev/NerdoMeter it scores 5 or maybe even 6.

Predictability is my greatest concern here.

It tries to mend the issue that the Wysiwyg is maybe not ready to be the default Edit button.

Then I'd rather seen proposals how to address that. If the bottom of the car is rotten it needs new steel and not more plastic padding.

-- TWiki:Main.KennethLavrsen - 15 Nov 2007

I have to admit that the implication of and the logic behind the patch is complicated. But that's for TWiki site or web administrators. Users aren't affected if a proper document is provided.

This patch doesn't prevent the current develop.twiki.org behavior. By default, the behavior is kept intact. And only if an administrator wants to provide different behavior, he or she can do so by explicitly setting variables introduced by the patch.

Kenneth, do you think this additional flexibility provided by the patch scare TWiki admins off from the plug-in?

My goal of gradual introduction is not unique to me. There must be other people than me running a TWiki site and wanting to introduce TinyMCEPlugin's WYSIWYG editing gradually not requiring any configuration to users.

Would this patch really harm people who are fine with the current situation? I believe by this patch more people would be happier and no body becomes unhappy.

-- TWiki:Main.HideyoImazu - 16 Nov 2007

I personally think this approach is too clumsy. Consider this: when TinyMCE (or any other Javascript editor) starts up, all they do is to hide the existing textarea and create a new DOM element to handle the edit. Obviously it should be possible, from within JS, to hide that new DOM element, and unhide the textarea (i.e. switch off TinyMCE from within the browser. Wouldn't that be a lot simpler?

-- TWiki:Main.CrawfordCurrie - 17 Nov 2007

Later: I just implemented this. If you edit here, and click the pickaxe, you should see what I mean.

-- TWiki:Main.CrawfordCurrie - 17 Nov 2007

There should not be a button that removes all your changes without any warning! There is no way to go back to my edit! If there is to be a switch it should safeguard all changes!

-- TWiki:Main.ArthurClemens - 18 Nov 2007

This button would be really, really useful if it worked like the HTML button beside it i.e. the user could switch between TML and WYSIWYG mode. Even if the switchover was much slower, due to the need to pass through several conversion stages.

-- TWiki:Main.JohnFitzpatrick - 19 Nov 2007

I only did this as a demo (hence the checkin to MAIN only). Yes, there needs to be a way to block data loss, and yes, a mirror-operation would be nice. I was hoping TWiki:Main.HideyoImazu might pick up the ball.

-- TWiki:Main.CrawfordCurrie - 19 Nov 2007

I closed the loop. Changes will not be lost in the switch (though I'm not sure what'll happen if you navigate away from the text edit)


I just tried the new button here.

I cannot see that it works. I end up in some strange looking text and not at all in TML. I cannot see what I can use that for.

-- TWiki:Main.KennethLavrsen - 19 Nov 2007

I've just tried editing the same topic with TinyMCE, then raw TML, the HTML and then all over again. It works!! Very, very nice.

-- TWiki:Main.JohnFitzpatrick - 19 Nov 2007

I'm going to merge. I've tested on FF, IE and Safari, and it works just fine on all of them.

Kenneth, you may need to clear your cache.


There has been sufficient feedback to make me feel I can close this. Please report any issues in separate bug reports (easier for me to track that way)


Confirmed that it was a cache issue. Works great now.

This really resolves the one issue I had when creating a new topic that was to be a clone of another (paste in raw and save). I can now create the new topic and hit the axe. Cool. Agree this can close it. Will test it more naturally but as a feature - great.

-- TWiki:Main.KennethLavrsen - 19 Nov 2007

Summary making "Edit" button smart
ReportedBy TWiki:Main.HideyoImazu
Codebase 4.1.2
SVN Range TWiki-4.3.0, Fri, 12 Oct 2007, build 15261
AppliesTo Extension
Component TinyMCEPlugin
Priority Enhancement
CurrentState Closed
WaitingFor Anyone interested in a raw/wysiwyg switch
Checkins TWikirev:15627 TWikirev:15628 TWikirev:15629 TWikirev:15640 TWikirev:15643 TWikirev:15658
TargetRelease n/a

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng a.png r1 manage 89.4 K 2007-11-26 - 03:48 HideyoImazu  
Edit | Attach | Watch | Print version | History: r33 < r32 < r31 < r30 < r29 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r33 - 2007-11-26 - HideyoImazu
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback