create new tag
, view all tags

TinyMCEPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on TinyMCEPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the TinyMCEPlugin bug database.

Feedback on TinyMCEPlugin

Note: See TinyMCEFrequentlyAskedQuestions for answers to common questions.

Older feedback deleted - see history

Suggestions from TW:

  1. When TinyMCEPlugin is active, it should deactivate the Wysiwyg context There should not be a Wysiwyg Button on the top tool bar if TinyMCEPlugin is active, as we do not want the user to have to be dealing with two such editors.
  2. Provide a template specification that adds a "edit raw" button to the tool bar. As it is done on the Bugs web.
  3. Allow TinyMCEPlugin to be invoked just like kupu i.e., by setting the COMPOSER flag. (applicable to pre 4.2 only)

I was wondering how I can make it non ASCII character friendly. If you edit a page with a Unicode character, the character shows up as %uDDDD on Tiny MCE editor. And the %uDDDD stays after finish editing. I found out that applying the following patch to TWiki 4.1.2 solves this problem.

--- lib/TWiki.pm        2007-03-03 23:45:57.000000000 +0900
+++ lib/TWiki.pm.patched        2007-10-23 15:46:56.000000000 +0900
@@ -2157,6 +2202,9 @@
     my $text = shift;

     $text =~ s/%([\da-f]{2})/chr(hex($1))/gei;
+    use encoding "utf8";         
+    $text =~ s/%u([\da-f]{4})/chr(hex($1))/gei;
+    no encoding;

     return $text;

-- HideyoImazu - 23 Oct 2007

UTF8 support needs to be handled as part of a broader effort to support international character sets in TWiki. Unfortunately no-one who uses international character sets has bothered to pick this up. I suspect your patch might attract some negative comments with respect to performance.

-- CrawfordCurrie - 28 Oct 2007

I'm rather new to the TWiki development community. Where should I raise/discuss this issue? Incidentally, the code above won't affect performance a lot because it's in urlDecode(), which doesn't seem to be used frequently.

-- HideyoImazu - 29 Oct 2007

How about introducing the following to make TinyMCEPlugin more flexible?


This suggestion was moved to Bugs:TinyMCEPlugin as per Franz' suggestion below.

-- HideyoImazu - 31 Oct 2007

Hideyo, I think it would be better to move your proposal to Bugs:TinyMCEPlugin cause it's not only bugs that are tracked there but enhancements too. Very good idea by the way to turn on/off the editor on web level, although I'm not sure if it not already is.

-- FranzJosefGigler - 31 Oct 2007

Thank you for your suggestion Franz. I moved the above proposal to the suggested place. And I leave only a trace of the suggestion above.

-- HideyoImazu - 09 Nov 2007

I installed TinyMCE Plugin now on my Machine and it works. But why it is not possible to insert any file its only possible to insert a picture?? Or is it possible ? This is problem for me... Regards Georg

-- GeorgSauseng - 23 Nov 2007

Please ask support questions in the Support web.

-- CrawfordCurrie - 24 Nov 2007

FYI: I am not sure where to put that, but i saw somebody workin on merging FCK and TinyMCE Editor somehow, did u ever see that, looks interesting doesnt it? It was on PHP 4 Applications (http://p4a.crealabsfoundation.org/tinyfck).

-- GeorgSauseng - 27 Nov 2007

I have a line to be right-aligned. In raw text editing, I can do it by: <div style="text-align: right">...</div>. When a page containing it is edited by Tiny MCE, the div tag is kept. But when it's saved, it's removed.

I wonder if there is a way to have a right-aligned line in a TinyMCEPlugin safe manner.

-- HideyoImazu - 06 Dec 2007

Probably best to file a bug report.

-- PeterThoeny - 06 Dec 2007

When used in combination with natedit, it would be nice if the natedit buttons could be enabled when switching to plain-text edit.

-- MarkVanHeeswijk - 18 Dec 2007

Can you confirm that this plugin works with IE <7? We are getting errors with clients on IE6.. IE7 fixes it but this is a showstopper here I'm afraid

-- PadraigLennon - 19 Dec 2007

I have got problems with TinyMCE in IE too, but only when used in combination with natskin. Pattern skin works fine though, so i guess it must be a natedit issue.

-- MarkVanHeeswijk - 20 Dec 2007

We have several people working on IE6 and it works, but is seems it is much slower to retrieve it's information.

-- FrederikBeun - 20 Dec 2007

The actions save&continue and preview don't seem to conserve the nowysiwyg url variable.

-- MarkVanHeeswijk - 21 Dec 2007

Please file a bug report at TWikibug:TinyMCEPlugin to track this.

-- PeterThoeny - 01 Jan 2008

tinymce.png I'm experimenting with TWiki 4.2 RC2 right now. In my setup, I use mod_ntlm for authentication. I'm not quite sure, but it looks like I have a conflict with TinyMCEPlugin in this setup. When I edit a page, I get the "Please wait.... retreiving from server" message, and an authentication dialog pops up. No matter what I enter, authentication fails, and I get the dialog again. And again. And again... 8-(

Editing works fine after disabling TinyMCEPlugin. Has anybody seen this kind of behavior? For reference, I'm using Apache 2.2.3.

In the Apache logfile, I see "PDC connection already closed" error messages. These are the same kind of messages which you get if you use mod_ntlm without setting Apache's KeepAlive option, so maybe this is a hint.

PS: I've switched to mod_auth_ntlm_winbind in the meantime, but still have the same problem.

-- ClausBrod - 04 Jan 2008

What about including a copy & paste feature for Images is that possible in the new 4.2. release of Twiki?

-- SvenHeupel - 24 Jan 2008

Broken Chinese problem.

You can input Chinese and save it successfully. (left picture) But if you re-edit again (middle), this words will turn into some other codes ... (right picture)


-- ThYang - 31 Jan 2008

ThYang - Please file a bug report at TWikibug:TinyMCEPlugin to track this. I know wide-byte characters are broken; they are broken in core TWiki, but we have been unable to find anyone who uses them who is prepared to help debug :-(.

ClausBrod, good idea about the KeepAlive. What may be happening is that the request for the translation is sent to the server down a new socket (I thought it reused the existing one, but maybe not) and the authentication has to be repeated. No idea why it fails, though. Might be worth researching similar problems with XmlHttpRequest and mod_ntlm. There should be other occurences of this, as it's fundamental to AJAX.

-- CrawfordCurrie - 01 Feb 2008

I've filed Bugs:Item5314 and found Bugs:Item4946 dealing the same issue.

-- ThYang - 02 Feb 2008

Completely fails in IE7 ... Using a fresh install of TWiki 4.2.0. Works in FF.

The exact issue is the "SAVE" and "CANCEL" buttons do NOT appear in IE, and the browser warns of a Javascript Error. Therefore, the issue has more to do with the 4.2.0 edit page, but I'm not sure where to best report it.

The exact error message follows...

Line: 41 Char: 3 Error: Can't move focus to the control because it is invisible, not enabled, or of a type that does not accept the focus.

This one should be a fairly quick fix... Please report this to the right dev topic since I'm not sure if TinyMCEPluginDev is appropriate.

-- KevinFirko - 04 Feb 2008

FYI: I did try upgrading in configure both Wysiwyg and TinyMCE plugins before reporting this...

-- KevinFirko - 04 Feb 2008

Anyone else notice BTW that TinyMCEPlugin adds extra spaces after variables?? Sometimes I edit a preferences topic, save, and then realize my skin settings have been completely messed.

Even though I was editing a totally different section of the doc, TinyMCEPlugin helpfully goes and mangles what it thinks are bullets (the * SET ... actions) and puts spaces after them.

Some plugins like NatSkinPlugin aren't tolerant of this, and don't recognize a custom setting if there are a few spaces after it, and hence fall back to defaults. This even happens if I go to edit, then click the "Edit TWiki Markup" button on the toolbar, make my changes, and save from there...

As a workaround, if I notice TinyMCE has mangled my settings by adding spaces, I have to edit the topic again, delete all the extra spaces, and then cross my fingers that TinyMCEPlugin saves it as I wrote it, with no spaces (which it usually, but not always does...). Kind of annoying, and responsible for inadvertently killing both skin settings and auth settings when editing a topic.

Anyhow it could always be Wysiwyg's fault too... I'm suprised WysiwygPlugin is the backend "translator" for this. That plugin messes up big tables coded originally in Wikitext by trying and failing to make them HTML tables (why can't it just leave the wiki ones?). Now its part of 4.2.0!

-- KevinFirko - 04 Feb 2008

Just started to test tinymce in twiki 4.2. I think it is the right way and it helps getting more users in writing wiki contents on their own - and it speeds up editing on large texts as its easier to permanently see what the text will really look like.

But - like Kevin wrote before - I really don't like how tinyMCE handles tables. I normally only use twiki standard tables via Edittableplugin or editrowplugin and when I simply touch the table with the mouse it is automatically altered into a html table and I have to recover from a previous version. I would appreciate a possibility to easily undo such a change.

-- HaraldLipke - 05 Feb 2008

You are right, we removed some icons (cell property,...) in the editor. In this way we have less conversions to html.

-- FrederikBeun - 06 Feb 2008

Hi. I would like to file an bug-report, but I need to have a registered account on the twiki page with bug reports. For the past 2 weeks, every time I try to register it tells me: 'Registration temporarily disabled'. So, maybe somebody who already has an account could turn this into a bug report for me?

This bug is similar/the same to the current: Item5216. None of the pop-up windows in TinyMCE (to insert a link, picture, etc.) work correctly with Firefox I am using TWiki 4.1.2. Latest version of BehaviorContrib and TinyMCE. What happens is that a pop-up window will appear, but instead of containing anything useful, the source code of what is supposed to be there appears in the window. This is very important to us, as all of our users use Firefox.

The complete source code for the insert image pop-up is below. It looks like template variables are not being substituted correctly or something like that.

[snipped lots of nasty html code]

-- DaveThompsonAnother - 08 Feb 2008

Dave, here is the solution for your FF problem (assuming you're using Apache): TWiki:Support/TinyMCEPluginPopUpsProblem

Btw, pasting html code into a topic can lead to unexpected results... wink

-- MartinKaufmann - 08 Feb 2008

All right so I was going to setup a Twiki site to relay some information about my upcoming nuptials and I'm totally annoyed that Twiki breaks my Korean and Chinese characters.

I'm triply annoyed because:

1) I'm a perl developer and know UTF8 support in perl sucks ass.

2) Nobody has fixed this yet. And I need a WIKI up NOW!

3) some of the core developers thing asian characters are not important.

Someone tell me how I can help. I can type in Chinese, Korean, and Japanese.

I do know TinyMCE breaks character encoding as soon as you hit the RawWikiMarkup button in the plugin. I've just installed 4.2.



-- TimothyChen - 14 Feb 2008


If you really want to use TWiki, then use version 4.1.2 as I'm using this one for my production server. Use UTF-8 for Chinese. I think it will work fine with both Korean and Japanese.

-- ThYang - 15 Feb 2008

No - version 4.2.0 works fine for CJK (Chinese, Japanese, Korean) as long as you stay in the WYSIWYG editor. I'm using standard traditional Chinese.

As soon as you hit the Edit TWiki Markup in the WYSIWYG editor, the wide byte UTF-8 encoding is lost, and it's converted to single bytes. This is of concern because this "conversion" is irreversible.

Heavy CJK users should ForceNewRevisions on and save often to avoid catastrophe as a workaround.

I haven't had a chance to look deeply into the source code, but I suspect a bad stream of raw text is being utilized in the call stack somewhere underneath that "EditRawText" button.

I believe item5314 is tracking this in the bug database, and a tiny reference made to it here:


-- TimothyChen - 15 Feb 2008

some of the core developers thing asian characters are not important I'm sorry this impression has come across. It's not that we don't think it's important, it's just that without coding support from UTF-8 experts, we've found it all but impossible to fix (and believe me, I've tried). So far the only fix contributed for this problem has created a perl crash (I mean segfault type crash).

The conversion works by sending a REST request to the server to get the topic content converted from WYSIWYG to plain text. This request is supposed to be executed in an identical way to the translation on save at the end of a WYSIWYG edit, but something is snafu. Sometimes it looks like HTTP is screwing up the character stream; sometimes it looks like it's perl. Always it is really difficult to pin down, especially when you are trying to debug on an English-only computer. So as soon as you do get a chance to look at the source code, give me a shout and I'll help all I can.

-- CrawfordCurrie - 20 Feb 2008

Just install East-Asian fonts if you are using a Windows computer to debug. It's probably already on your computer. smile

OK from brief inspection I see: POST /twiki/bin/rest/WysiwygPlugin/html2tml

As the culprit triggered when I hit EditTwikiMarkup,

Which then triggers lib/Twiki/Plugins/WysiwygPlugin.pm presumbably, Which hits _restHTML2TML.

I suspect your change to Item5138 is screwing with it. Based on your comments in sub convert I see:

# Item5138: Convert 8-bit entities back into characters $text =~ s/&($safe_entities_re);/chr($safe_entities{$1})/ego;

There are two more Regex that follow. I'm not sure this is safe for UTF-8. I just tried commenting it out, but that didn't work then again I might not have cleared my cache...

But I could be wrong. smile

Cheers -


-- TimothyChen - 25 Feb 2008

I lied. It's not convert. By the time the code path hits convert, the string is already corrupted... investigating further.

-- TimothyChen - 26 Feb 2008

Ok Crawford - I need some guidance. I'm trying to fight my way up the call stack from _restHTML2TML to figure out where the html string begins its corruption.

My next suspect is

Twiki::Func::getCgiQuery()->param('test') || '';

To test "utf-8ness" I just wrote a small logger to log everything to a text file, and have it output before and after text is manipulated. Then I keep testing the various functions over and over again by hitting the evil Ax button to see if it's corrupted before or after.


timlog { my ($string) = @_; open (FILE, ">>blah.txt"); print FILE $string; close (FILE)

} (No, I'm not out to win coding awards with this Perl snippet)

I embed timlog before and after

WysiwygPlugin.pm &timlog("WysiwygPlugin.pm: Log BEGIN\n\n\n"); &timlog("Before Decode" . $html);

$html = TWiki::urlDecode($html); &timlog("After Decode:" . $html);

and so on and so forth. I need to move up the call stack - care to give me some points upward or likely suspects?

-- TimothyChen - 26 Feb 2008

Do these appear in Chinese to you or ASCII garbate? 好—? (How are you in Chinese.)

Do these appear in Korean to you or ASCII garbage? ë„ (rain)

-- TimothyChen - 26 Feb 2008

That's worrying. That 'param' function is part of the CGI module (from CPAN). If the string is corrupt coming from there, then it is probably corrupt before it ever leaves the browser. One thing that I found hard to handle was that sticking use utf8 in the code would often change the goalposts, as it would make perl do different things to the strings. However I think I was recommended not to do that by RichardDonkin (our only UTF-8 expert)

I think you need to check the string that is being stuffed into the request in Javascript. Sounds like it may be being munged there.

-- CrawfordCurrie - 26 Feb 2008

use utf8;

Is not the way to fix it.

From what I can tell with other perl applications (such as Mozilla's Bugzilla) that seem to solve the problem elegantly is:

use Encode; use Encode::Guess;

If TWiki indeed uses the CGI module from CPAN, then my test must be wrong somewhere, I'll have to dig deeper. Because I know that works on the particular system I'm using in NOT munging utf8 related data.


Thanks Crawford.

-- TimothyChen - 26 Feb 2008

The patch in Bugs.Item4946 solved the broken Chinese problem.

-- ThYang - 04 Mar 2008

I would like to share the solution I have found for activating Firefox 2's spell check feature in TWiki version 4.2 with the default TinyMCEPlugin. According to the solution I found on the TinyMCE website, you must pass the init option "gecko_spellcheck : true" to TinyMCE. To do this in TWiki 4.2, go to your TwikiPreferences page and include the following line:

Set TINYMCEPLUGIN_INIT_GECKO = gecko_spellcheck : true

After a substantial amount of searching through the TWiki documentation I was unable to find this solution, I hope it will be of help to fellow Firefox users.

-- BernMoorehead - 13 Mar 2008

Thanks Bern for digging this out! Is tracked in TWikibug:Item5434.

-- PeterThoeny - 13 Mar 2008

I have same problem same to ThYang. Create a new topic with TinyMCE and input English, Thai and Japanese has no problem. But when edit again with TinyMCE, Thai and Japanese message show as a serial of codes. It's no problem when edit by Raw edit.

My configuration:

UseLocale = Yes

SiteLocale = th_TH.utf8

SiteLocaleRegexes = Yes

SiteCharSet = utf-8

-- WootichaiJ - 22 Mar 2008


AFAIK this plugin uses TinyMCE v2.11, which is fairly outdated. Any chance this gets updated to v3.x in the near future? I tried to do it myself but just dropping the js-files into the folder didn't work and I don't know where I'd have to tweak the TWiki-wrap-around to make it work. Any hints?

-- JoachimBlum - 28 Mar 2008

Recently uploaded an updated version that should improve most utf-8 issues. There is an even more recent version in Subversion, but I can't upload it (TWiki.org won't let me). If anyone feels the urge they can get the new version from subversion. If you know how to build and upload to TWiki.org, please feel free to update TinyMCEPlugin and WysiwygPlugin.

-- CrawfordCurrie - 31 Mar 2008

What would it take to get "proper" spellchecking into this plugin? Ie (no pun intended...) in IE or non-Firefox browsers. Or FF for that matter - the gecko_spellcheck option isn't great - it doesn't seem to spot spelling errors in existing words (ie in topic text already when you click Edit) until you change a word - each word.

-- MarcusLeonard - 01 Apr 2008

Hi, is it possible for the plugin to disable itself only on WebPreferences pages and TWikiPreferences pages without affecting the whole web or site ? I think it could be great if the plugin could offer this option since all the "very sensitive" stuff should be in those pages only. I know it is not a "normal" plugin behavior but it does somebody know a way to achieve this ? Thank you

-- MathieuLeFrancois - 03 Apr 2008

an easy way to achieve this is using a plugin which is not in the list of wysiwyg. Even an unexistant plugin helps. eg. put on the page you want to edit in raw mode %NOWYSIWYG{This is to prevent errors on editing}%

-- FrederikBeun - 04 Apr 2008

Is the strike (cross-out) feature turned off at the TWiki Plugin level? It can be useful for casual To do lists.

-- MartinCleaver - 05 May 2008

I have just updated this plugin to the latest version (6 May) (also the WysiwygPlugin) and am no longer getting the WYSIWYG editor at all, just the raw editor. Possibly to do with our set up / templates, but it was working fine before the upgrade. Any thoughts?

-- TamsinTweddell - 09 May 2008

Check your installation through TWiki/InstalledPlugins and look for errors. Otherwise you might check you templates, best way to check this is, switching to a standard template &skin=class. If there are the same errors, it might be something deeper.

-- MayerEugen - 13 May 2008

Frederik: do you mean simply typing this variable on a topic? If so, it certainly has no effect on our 4.2 installation. The "edit" button still opens the WYSIWYG editor and garbles the pre-existing variables on the page.

-- DavidWolfe - 13 May 2008

I've found a way that works for 4.2. Set * Set DISABLEDPLUGINS = TinyMCEPlugin on the topic or web you want to disable it for. Then clicking the Edit button will take you to the plain text editor.

-- DavidWolfe - 13 May 2008

DavidWolfe that method only works for topics other than TWikiPreferences or any WebPreferences. I would like to disable it for these only for now.

-- JamesGMoore - 30 Jun 2008

What I meant was that I want to disable TinyMCEPlugin when editing the TWikiPreferences topic only (since with my installation it breaks the entire site but most other topics are edited by TinyMCE ok).

-- JamesGMoore - 30 Jun 2008

TinyMCE is up to version 3.1.0 as of 2008-06-17. Has it been tested with TWiki 4.2? Would it be easy to update? Thanks.

-- BobBagwill - 30 Jun 2008

Maybe you could instead try this: on either TWikiPreferences or any WebPreferences, = * Set WYSIWYG_EXCLUDE = html,variables,calls,pre,comments=. This causes the WYSIWYG editor to work on all topics except those containing HTML or TWiki Variables. Since Preferences have Variables, they will not open in TinyMCE. Of course, other topics containing variables or HTML also will open in the raw editor, but in most cases that's probably what you want. The WYSIWYG editor often ruins these elements.

-- DavidWolfe - 30 Jun 2008

Maybe you could instead try this: on either TWikiPreferences or any WebPreferences,

   * Set WYSIWYG_EXCLUDE = html,variables,calls,pre,comments
. This causes the WYSIWYG editor to work on all topics except those containing HTML or TWiki Variables. Since Preferences have Variables, they will not open in TinyMCE. Of course, other topics containing variables or HTML also will open in the raw editor, but in most cases that's probably what you want. The WYSIWYG editor often ruins these elements.

-- DavidWolfe - 30 Jun 2008

David yes that works but I dont find that the WYSIWYG breaks topics containing variables. In my experience it only breaks the Sandbox and TWikiPreferences topics. It may also break other WebHomes. Perhaps there is something in common with these.

I have just done a compare on Sandbox\WebHome.txt before and after the WYSIWYG has saved it. You can see in the attachment afterwysiwygsave.jpg that the WYSIWYG has ruined the Recently Change Topics dynamic bullet list.

Here is the diff (with differences in tabs, spaces and letter-case ignored):

Compare: (<)C:\websites\Copy of twiki\data\Sandbox\WebHome.txt (2386 bytes)
   with: (>)C:\websites\twiki\data\Sandbox\WebHome.txt (2161 bytes)

< %META:TOPICINFO{author="TWikiContributor" date="1181951854" format="1.1" version="13"}%
> %META:TOPICINFO{author="moorej" date="1214906958" format="1.1" version="1.14"}%
< %ICON{"newtopic"}% %MAKETEXT{"Create a new document by name:"}% %MAKETEXT{"(Use a topic name in TWiki.WikiNotation)"}% <br /> 
< <input class="twikiInputField" type="text" name="topic" size="32" />&nbsp;<input type="submit" class="twikiSubmit" value='%MAKETEXT{"Create by Name"}%' />
< <input type="hidden" name="onlywikiname" value="on" />
< <input type="hidden" name="onlynewtopic" value="on" />
< </form>
< <form action='%SCRIPTURLPATH{"edit"}%/%BASEWEB%/TestTopicAUTOINC0' name="createNewTestTopic">
< %ICON{"newtopic"}% %MAKETEXT{"Create a new auto-numbered test topic:"}%
< <input type="hidden" name="t" value="%SERVERTIME{$hou$min$sec}%" />
< <input type="submit" class="twikiSubmit" value='%MAKETEXT{"Create <nop>TestTopic###"}%' />
< </form>
< ---++ %MAKETEXT{"Recently changed topics"}%
< <dl>
< %SEARCH{ ".*" regex="on" nosearch="on" nototal="on" order="modified" reverse="on" limit="7" format="<dt>[[$topic]]</dt><dd>$summary<br /><span class='twikiGrayText'>$date - $wikiusername</span></dd>"}%
< </dl>
> %ICON{"newtopic"}% %MAKETEXT{"Create a new document by name:"}% %MAKETEXT{"(Use a topic name in TWiki.WikiNotation)"}% <br /><input class="twikiInputField" type="text" name="topic" size="32" /> <input type="submit" class="twikiSubmit" value='%MAKETEXT{"Create by Name"}%' /> <input type="hidden" name="onlywikiname" value="on" /> <input type="hidden" name="onlynewtopic" value="on" /> </form>
> <form action='%SCRIPTURLPATH{"edit"}%/%BASEWEB%/TestTopicAUTOINC0' name="createNewTestTopic"> 
> %ICON{"newtopic"}% %MAKETEXT{"Create a new auto-numbered test topic:"}% <input type="hidden" name="t" value="%SERVERTIME{$hou$min$sec}%" /> <input type="submit" class="twikiSubmit" value='%MAKETEXT{"Create <nop>TestTopic###"}%' /> </form>
> ---++ %MAKETEXT{"Recently changed topics"}%
<    * <input class="twikiInputField" type="text" name="search" size="22" />&nbsp;<input type="submit" class="twikiSubmit" value="Search" /> - [[WebSearchAdvanced][advanced search]]
>    * <input class="twikiInputField" type="text" name="search" size="22" /> <input type="submit" class="twikiSubmit" value="Search" /> - [[WebSearchAdvanced][advanced search]] 

-- JamesGMoore - 01 Jul 2008

I would like to some additional styles to be make use of ExplicitNumberingPlugin. Presently there are six heading styles: "Heading 1", "Heading 2", which translate to ---+, ---++, etc. I would like to add "1. Heading 1" and "1.1 Heading 2" which translate to ---+ ##. and ---+ ##.. respectively. How difficult would this be to do?

-- ChrisPurves - 04 Jul 2008

In case anyone's looking:

I've ran into the same problem as ClausBrod above (this time, on IIS/ActivePerl 5.8 but also with NTLM).

The problem has something to do with AJAX, POST and the 3 steps required for NTLM. Usually, just changing POST to GET works; in my case, it didn't, but the removing the following line from twiki_tiny.js did:

TWikiTiny.request.req.setRequestHeader("Connection", "close");

Haven't seen any side effects with neither IE6 nor FF2 so far.

-- SergeiKlink - 10 Jul 2008

The method for short URL described on page http://twiki.org/cgi-bin/view/TWiki/ShorterUrlCookbook#Changes_to_LocalSite_cfg causes an error in TinyMCE. The SRCs of the images are strangely addressed. Instead of 'twiki/pub', inserts 'twiki.pub '.

Example after saving a topic in WYSIWIG:

<img width="220" src="twiki.pub.Sandbox.TopicTest.1067657.jpg" height="147" />

The error does not occur after the cut line

$TWiki::cfg{ScriptUrlPaths}{view} = '';
in LocalSite.cfg

-- CarlinhosCecconi - 27 Jul 2008

The ShurterUrl issue was fixed in a current version of TinyMCEPlugin - you should only need to update this package (and WysiwygPlugin) using the Extensions section of configure.

-- SvenDowideit - 28 Jul 2008

I am using the latest versions:

TinyMCEPlugin (TWiki-4, $Rev: 16767 (06 May 2008) $)
WysiwygPlugin (TWiki-4.2, $Rev: 16898 (17 Jun 2008) $)

But even so ShurterUrl not working. Only disabling the line $TWiki::cfg{ScriptUrlPaths}{view} = ''; in the LocalSite.cfg

For a complete list of Plugins installed, see http://www.htcwiki.com.br/twiki/bin/view/TWiki/InstalledPlugins.


-- CarlinhosCecconi - 28 Jul 2008

Note that this plugin breaks SectionalEditPlugin as it removes linebreak characters from the text in some strange way. I do not quite understand what is going on, but once you edit a text relying on the SectionalEditPlugin with this plugin, all text is treated as one giant long string when parsed through TML.

-- ThomasWeigert - 28 Jul 2008

With regards to using TinyMCE plugin with NTLM authentication I've added bug 5859. It seems the fix is simple but someone who understands the JavaScript code of the plugin should verify it.

-- LarsHaarber - 01 Aug 2008

Just a gentle reminder that if you want something changed (or want to change something) then I will respond to bug reports (such as the one Lars submitted) much faster than I will respond to posts here.

JamesGMoore: damaging topics should be regarded as a bug. Please try and reproduce the damage in as small a topic as possible and report it as a bug.

ChrisPurves: there is no HTML construct corresponding to '---+ ##' but you could define a menu item that insert that string. IIRC I tried doing this once before and got into all sorts of a mess, so I suspect a fully-fledged TinyMCE plugin would be the only way (perhaps there already is one? Check the tinymce site)

-- CrawfordCurrie - 01 Aug 2008

Just a note, but the tinymce bundled with this plugin does not work well in Safari.

However by simply replacing the "tinymce" directory within the installed plugin (please backup the original first) with the current 3.x tinymce, Safari works great. Firefox also seemed a bit less quirky.

-- BobbySmither - 03 Aug 2008

Once I have installed 4.2.2, if i edit the TWiki/TinyMCEPlugin page in the wisiwig then click the pitchfork to swap to raw - i only get half the content of the page in the editor

-- TerryRankine - 22 Aug 2008

Bobby, yes, I know. I tried to upgrade to 3.x, but found it requires rewriting all the plugins so it's a non-trivial step.

Terry, pitchfork? I know I'm no artist, but pitchfork? wink

Chances are there is some useful information in your apache logs on this one. Please check.

-- CrawfordCurrie - 25 Aug 2008

I'd agree with CC that the upgrade is non-trivial but I'm going to posit that the enhancements both in terms of browser compatibility and output cleanup would be worth it long-term. Not to mention the fact that the moxiecode wiki is now missing all the old 2.x config docs so there is no reference for people looking to tweak their tinymce config on twiki. Are the plugins all related to in-editor buttons or are there parts that help with the translation between tml and tiny? If it's the shortcut buttons I'd feel comfortable taking a stab at them. If it's post edit cleanup I'm still too much of a js newb to be of any use.

-- DrewStevenson - 25 Aug 2008

Yes, all related to in-editor buttons, and the complex bit is the buttons that handle image attachment, because they generate dialogs. Since I wrote these plugins based on the plugins that moxicode published, it shouldn't be that hard to repeat the process. I just don't have time right now.

-- CrawfordCurrie - 25 Aug 2008

Hi Crawford the icepick - whatever you want to call the edit raw button.

Looked in the apache error logs - nothing mentioned. I get the full topic when clicking 'raw edit' from the normal page. but once inside the wysiwg editor - clicking the swap to raw, only renders part of the page with no errors in logs.

I am running 4.2.2 with the latest modperl config from the apacheconfiggenerator page

-- TerryRankine - 26 Aug 2008

As soon as i add this line to any page

%IF{"defined 'SYSTEMWEB'" else="<div class='twikiAlert'>%X% WARNING: SYSTEMWEB is not defined in this TWiki. Please add these definitions to your %MAINWEB%.TWikiPreferences, if they are not already there:<br><pre>   * <nop>Set SYSTEMWEB = %<nop>TWIKIWEB%<br>   * <nop>Set USERSWEB = %<nop>MAINWEB%</pre></div>"}%

I can reproduce the problem.

Any ideas?

-- TerryRankine - 26 Aug 2008

I can confirm the error TerryRankine reported! I use the TWiki 4.2.2 on Centos 5.2 with Perl 5.8.8. I can see error like Cannot decode string with wide characters at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Encode.pm line 166. at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Encode.pm line 166 Encode::decode('utf8', '

%IF{"defined \'...') called at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Encode.pm line 206.

-- AllenChen - 26 Aug 2008

Terry, none I'm afraid. I'll try and reproduce the problem when i get a chance. In the interim, any further info you can provide would be most helpful.

Allen, I'm guessing from your name that you are trying to use Chinese characters. The error you report is due to some issue with UTF8 and non-western characters; probably a result of you editing a topic that was created by an older, broken, WysiwygPlugin.

-- CrawfordCurrie - 29 Aug 2008

What would be needed to get paste of pictures work (let the image upload automatically)?

-- ArthurClemens - 15 Sep 2008

Probably not much. Though it wouldn't be worth doing it before TMCE has been upgraded to the latest release.

-- CrawfordCurrie - 17 Sep 2008

I imagine that TWiki would at least need to support multiple file upload...

-- ArthurClemens - 17 Sep 2008

Hi All, Does anyone know of a global way to get TinyMCEPlugin to ingnore the MediaWiki Table format? I'm converting an existing MediaWiki Site over to Twiki, the MediaWikiTablePlugin, enables Twiki to interpret the Media Wiki Table format, specifically tables starting with "{|" and ending with "|}".

An Example:

{| border="1"
|- class="tableTitle"
|Environment || Folder Location
|- class="tableRowOdd"
|Env || somewhere

When TinyMCE opens a topic with this style of table, it removes the table format. I've been able to use the <sticky> tags on one page, but I've got an entire site of these tables.

-- EdwardMoscardini - 30 Dec 2008

I was going to suggest the <sticky> tag, but I see that this is not practical if you have hundreds of existing tables. You could temporarily install the GlobalReplacePlugin and apply a regular expression search & replace to prefix and append the sticky tag to the tables.

-- PeterThoeny - 02 Jan 2009

I got similar error message as AllenChen's with TWiki-4.2.4, Sat, 06 Dec 2008, build 17773, Plugin API version 1.2. When I type in traditional Chinese, it works correctly in raw mode. However, it can only display correctly in TinyMCE, but it shows "Cannot decode string with wide characters at /usr/lib/perl/5.8/Encode.pm line 166." in the log after clicking "Save".

After some trials, I found a possible solution. Edit twiki/lib/TWiki/Plugins/WysiwygPlugin/HTML2TML.pm:

<         $text = Encode::decode_utf8($text);
> #       $text = Encode::decode_utf8($text);
>         if (utf8::valid($text)) {
>             utf8::decode($text);
>     }

Now I can edit it in TinyMCE correctly, but it still fails when editing some topics such as the TWikiAdminGroup topic (It cannot display content correctly, though there is no Chinese.).

-- ChiaHaoLo - 07 Jan 2009

Chia: Thank you for posting the bug report with fix. I enclosed the diff in verbatim tags so that it renders properly.

-- PeterThoeny - 07 Jan 2009

Hi there. I think TWiki is falling behind Foswiki with regards to this plugin. The problems with using TinyMCE on a server that uses some form of SPNEGO authentication (e.g. NTLM, Kerberos) are still unresolved and this means that TWiki is not usable on many corporate intranets. See this Foswiki bug for more information. I've tested both with TWiki 5.0 and with Foswiki 1.0.10 and only the latter works.

I suspect this is what makes the difference (quote from Foswiki bug 5859 ) :

"In the 3.2.2 upgrade I changed all the XHR calls to use the TMCE API which doesn't do a close, so should be good for NTLM"

From reading the Foswiki bug report this is what seems to have solved the problem. Therefore I propose the same for TWiki.

-- LarsHaarber - 2010-09-27

Thanks Lars for the feedback and for pointing out a possible fix. TWiki is open source, I invite you to get involved. If you start contributing you can help shape the product and you get help from the community.

-- PeterThoeny - 2010-09-28

Edit Topic Preference Settings

May be I'm wrong, but to change the preferences, I have to move "More topic actions" to make some changes. Will it be poosible, to add this functionality into the editor - onto a special button?

-- NorbertKress - 2012-11-01

Preferences can be set in two ways on a topic:

  1. As topic preferences settings, accessible from the "More topic actions" screen
  2. As preferences settings in the topic text, such as:

  • Set SOMETHING = Some value

You could add a button or link to "More topic actions" or directly to the topic preferences setting screen in the edit screen. I do not recommend that because users are enticed to browse away without saving the changes.

-- PeterThoeny - 2012-11-01

is it possible that so clean before save option to disable? (Code clearing)

-- Michael Berger - 2013-05-28

Michael, sorry I do not understand. Can you rephrase?

-- Peter Thoeny - 2013-05-30


I think the WYSWYG editor is a good thing for users who edit seldom. Anyhow I would like to have "Raw Edit" as the default when clicking on a not-yet-linked Wiki word. In other words I would like the parameter "nowysiwyg=1". I couldn't find the location where to define that. Any help?

-- Detlef Marxsen - 2014-01-28

Detlef, did you see the preferences setting in the user profile pages?

Also, the link format for red-links is defined by the NEWLINKFORMAT preferences setting.

-- Peter Thoeny - 2014-01-28

Good Morning! The paste buttons don't appear in my twiki installation. I did not make any special configurations, just using the defaults.

Versions are:

TinyMCEPlugin (2013-09-18, $Rev: 26397 (2013-10-14) $): Integration of the Tiny MCE WYSIWYG Editor

Twiki 6.0


-- Karsten Priegnitz - 2015-01-17

Please add bug reports to the bugs web at TWikibug:TinyMCEPlugin (or TWikibug:WysiwygPlugin if it is related to HTML to TML conversion). Please ask support questions in the Support web.
Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg TinyMCE-Thai.jpg r1 manage 56.7 K 2008-03-22 - 09:34 WootichaiJ  
JPEGjpg afterwysiwygsave.jpg r1 manage 150.4 K 2008-07-01 - 10:26 JamesGMoore WYSIWYG breaks the Recently Changed Topics. There should be lots of topics listed here.
JPEGjpg chinese-utf8.jpg r1 manage 31.5 K 2008-01-31 - 17:14 ThYang Chinese UTF-8 problem
PNGpng tinymce.png r1 manage 31.8 K 2008-01-31 - 20:39 ClausBrod  
Edit | Attach | Watch | Print version | History: r135 < r134 < r133 < r132 < r131 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r135 - 2015-01-17 - KarstenPriegnitz
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.