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

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 2.0.0.12. 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...

-- 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.

Thanks.

Tim

-- TimothyChen - 14 Feb 2008

Tim,

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:

TinyMCEFrequentlyAskedQuestions

-- 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.

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.

Cheers -

Tim

-- 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.

i.e.:

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.

Argh!

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

Hello!

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