The foswiki svn repository will become read-only on Friday 8/8. Developers should register for a account for commit access to foswiki.

Item1438: textareabuttons are not displayed when NOWYSIWYG is 1

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Normal Closed Extension PatternSkin, TinyMCEPlugin Main.PaulHarvey, Main.ArthurClemens, Main.GilmarSantosJr
I disabled TinyMCEPlugin through TINYMCEPLUGIN_DISABLE setting and it works, but textareabuttons (those to change the size of textarea and switch between monospace and normal fonts) are not displayed, unless I click raw edit.

edit.pattern.tmpl has:
%IF{"not context TinyMCEPluginEnabled or $nowysiwyg='1'" then='%TMPL:P{"textareabuttons"}%'}%

and it seems the context is set, even if the plugin is disabled. Here the test:

  • Set NOWYSIWYG = 1

TinyMCEPlugin is enabled

-- GilmarSantosJr - 10 Apr 2009

I ran into this page after updating from 1.0.4 to 1.0.7 with the new editor enabled - I lost those textareabuttons completely, new editor or raw edit alike. Had me quite puzzled for a while. I was able to track down the above snippet and hack out the IF, now I have my buttons back, yay! On both normal editor and raw editor, to boot, although they do not work for the normal editor, which is probably because of it being a hack.

Of course that's a hack and I'd rather understand what's going on and fix it properly than edit the template. Will be happy to hear a clarification on how to get the buttons back the right way. I haven't done anything unusual in my Foswiki other than install and enable a few plugins.

-- RasmusPraestholm - 26 Oct 2009

I'm unable to replicate this problem on trunk or release branch, or on my production 1.0.7 wiki (I get the textarea buttons in all cases).

But I'm not sure that this is a bug anyway; if it is, I'm not sure of the best way to fix it.

The problem is that you're setting TINYMCEPLUGIN_DISABLE = 1, but PatternSkin (and others) are only checking the the NOWYSIWYG variable.

I suspect the context TinyMCEPluginEnabled relates only to its "enabled" state in configure.

I think a proper solution would be that skins shouldn't check for specific WYSIWYG editors. NOWYSIWYG=1 should be implied if there is no WYSIWYG editor available. Then the IF statement would just have to check the NOWYSIWYG variable.

RasmusPraestholm, GilmarSantosJr - are you able to revert your work-arounds, confirm again this behaviour with TINYMCEPLUGIN_DISABLED=1 and then try NOWYSIWYG=1 instead?

-- PaulHarvey - 05 Nov 2009

Just test with this topic. In my first comment I adjusted TINYMCEPLUGIN_DISABLE to this topic. Edit it and search the buttons. I don't find them. Raw edit it and there they are...

-- GilmarSantosJr - 05 Nov 2009

This is truly strange... I did the same thing, but have the buttons. May I ask what browser you use? And or

-- PaulHarvey - 05 Nov 2009

Yes it is. At the time of the report I was using Firefox 3.0 and now 3.5.4. This is what I get (Raw Edit and Edit respectively):

-- GilmarSantosJr - 06 Nov 2009

Right, I must be going crazy. I am now getting the same error you described.

I have updated the bug to describe NOWYSIWYG variable instead of TINYMCEPLUGIN_DISABLE, because I am not sure that PatternSkin (or others) should have too much specific coding for a particular WYSIWYG editor (one day we might get FCKEDITOR as an alternative, for example).

Besides, NOWYSIWYG is just as easy to use.

But probably, we should make it easy for skins to detect whether there is a WYSIWYG editor available, instead of going through to test that they are specifically *dis*abled in one of many ways.

ArthurClemens, I added you in case you have any input to offer.

-- PaulHarvey - 06 Nov 2009

I still get this error on, so I'm reopening the task.

Just a hint: don't close tasks related to core or default extensions, instead leave them as Waiting for Release, so Kenneth can get the issues in the release notes. And at the time of release, he'll close the tasks. wink

-- GilmarSantosJr - 19 Nov 2009

Yikes, you're right. You'd think I'dve learnt by now to use WaitingForRelease properly.

My local trunk and release branch installations seems to work fine. GilmarSantosJr, are you able to test on a trunk installation other than

Are we running a custom PatternSkin on the Tasks web of

-- PaulHarvey - 19 Nov 2009

Raw Edit works fine on the current topic.

-- ArthurClemens - 24 Dec 2009

This fix shipped with 1.0.8, but was not closed in time to make release notes. So I've set this for ReleasedIn 1.0.9, and we can leave it to Kenneth to decide whether it makes the release notes or not.

It seems the bug persists here on because it's not up to date with svn (System.WebHome reports build 5392, whereas I've got 5820 on my running copy of trunk).

-- PaulHarvey - 24 Dec 2009

Thanks for noting. I added to release note in the 1.0.8 section and closing

-- KennethLavrsen - 25 Dec 2009

ItemTemplate edit

Summary textareabuttons are not displayed when NOWYSIWYG is 1
ReportedBy GilmarSantosJr
Codebase 1.0.7, trunk
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Extension
Component PatternSkin, TinyMCEPlugin
Priority Normal
CurrentState Closed
WaitingFor PaulHarvey, ArthurClemens, GilmarSantosJr
Checkins Foswikirev:5438 Foswikirev:5439 Foswikirev:5858 Foswikirev:5859
TargetRelease patch
ReleasedIn 1.0.8
Topic attachments
I Attachment Action Size Date Who Comment
With_Buttons.pngpng With_Buttons.png manage 101.5 K 06 Nov 2009 - 00:51 GilmarSantosJr SS of "Raw Edit"
Without_Buttons.pngpng Without_Buttons.png manage 111.4 K 06 Nov 2009 - 00:53 GilmarSantosJr SS of "Edit"
Topic revision: r21 - 25 Dec 2009, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License