• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 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.

Item5721: TinyMCE not honouring Template Topic in special cases.

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension TinyMCEPlugin Normal Closed   patch 4.2.1

Edit Form Data

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


-- TWiki:Main/ChrisHogan - 20 Jun 2008

I have just upgraded to 4.2 & have had a number of problems with this plugin. Given the wretched nature of TinyMCE - it litters the TWiki markup with bits of HTML, it adds no breaking spaces and will NOT let the user remove them - I did not want it as the default. I followed the the instructions at TWikiRawEditDefault04x02 amd restored the raw editor.

I've been forced to us TinyMCE with Joomla - and have often resorted to holding the HTML I want to create in a local editor & pasting it into the html view (which due to space removal is otherwise utterly useless).

It's fine, i suppose, for novices editing text. It is unsuitable if the user is setting preference variables, searches (again, adding or deleting spaces and returns when it thinks suitable, or leaving html embedded in the search parameters).

I have applied this fix and it seems to work, however...

Add a form to a topic & the raw edit is replaced by TinyMCE which then proceeds to append my anchors onto the end of the preceding lines

Irritating, but once I save it & edit again, raw edit is restored, so it's only immediately after adding a form to a topic.

But there is one more important bug - if a new topic is being created & action=form is specified then the templatetopic & thus the form settings are not honoured & a blank topic with no form is created instead. Fiddling with something (I thought it was disabling the plugin with SET DISABLEDPLUGINS = WysiwygPlugin but now I'm not sure) restored the behaviour to that of TWiki 4.1.2 as far as the form goes, but the text of the template still isn't included.

By the way is paste meant to be disabled in the TinyMCE editor? I cannot paste from another non-browser window into this form.

Even with the damn plugin disabled in configure it STILL activates on a new topic. My TWiki installation is heavily dependent on templates. All I can do is save the first time & then correct the formatting errors in the raw editor on a second save. Hardly conducive to showing how wonderful TWiki is to my users.

-- TWiki:Main.ChrisHogan - 20 Jun 2008

Chris. Please only ONE bug per bug item. The problem with pasting is that TMCE is a Javascript and depending on your browser and the security "zone" in e.g. IE pasting via script may be disabled. Just disable this security setting in the browser. In a normal Intranet situation your intranet would be a safe internet zone and then the default is that pasting is enabled. But trying here on bugs web it may be disabled. I personally raised a bug item on this until I learned it was an IE security setting.

So this bug item is now only about TMCE not honouring Template Topic.

-- TWiki:Main.KennethLavrsen - 20 Jun 2008

The problem with adding or changing a form in raw and then ending up in Wysiwyg will be solved in 4.2.1. See Item5724

-- TWiki:Main.KennethLavrsen - 22 Jun 2008

My apologies for mixing more than one bug report. I was performing a bit of a "brain dump" to get the results of several hours of experimenting down in one place.

I've looked at Item5724 & if it's fixed great, very quick turnaround.

Is the loss of Template Topic when using TinyMCE text fixed too? I know I will be using the raw editor, so it'll work for me with 4.2.1, but I'm still thinking about people using our wiki who might wish to start using TinyMCE as their default editor

-- TWiki:Main.ChrisHogan - 23 Jun 2008

I have not yet reproduced the template topic bug. It requires setting up a whole little application that uses a template topic and has forms.

You can help us by attaching a little set of topics that makes a good test case in a zip file to this bug item.

-- TWiki:Main.KennethLavrsen - 23 Jun 2008

I will have to get you a sety of topics.

This is far more serious than I thought - I use TopicCreatePlugin to generate sets of records for customers are part of a major ISO 9000 compliance system. Again I'm using action=form as the TopicCreatePlugin will make changes to the template topic text & will consist of points to the generate sub-topics: except using the TinyMCE plugin as the default here bypasses the whole TopicCreatePlugin process and I create a base topic with no sub-topics being generated.

I'll try to detatch some simple examples for you to use. The whole thing is quite elaborate & I don't think you'll want to have to install dozens of topics just to get an example working

-- TWiki:Main.ChrisHogan - 25 Jun 2008

Just a point of information to help your understanding (I hope). The TinyMCEPlugin works by "camping" on top of the standard edit template using Javascript. The same content (with only minor differences) is sent to the browser for raw and WYSIWYG edits. If Javascript is disabled in your browser, and you start a TinyMCE edit, then you should see a standard raw edit. Only when the raw edit page is loaded does Tiny MCE grab your text-to-be-edited, and throw it at the server to get an HTML version of that text bounced back. So, because it uses the same process during startup as the standard raw edit, and only converts to HTML after the editor is loaded, it should behave in exactly the same way as a raw edit. This is quite different to the Kupu integration, which did the conversion to HTML on the server before the content was sent to the client.

Of course you might have configured your templates differently to the standard Pattern skin. If you can create your testcase using Pattern skin that would help eliminate at least one of the variables. There are some preprocessing steps that TinyMCE goes through that might interact unfavourably with TopicCreatePlugin, so I'm not pooh-poohing your report, just trying to clarify how it works.

-- CrawfordCurrie - 27 Jun 2008

Sorry to take a while, very busy & my topics are a little complex, but the following illurstrates the problem: A creator topic

<form name="newreview" action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/">

<select name="contact" value="" onblur="this.form.topic.value=this.value+'TrainingRecordAUTOINC0000'" > 

<input type="hidden" name="topic" value="DefaultTrainingRecordAUTOINC0000"/>
<input type="hidden" name="onlywikiname" value="on" />
<input type="hidden" name="templatetopic" value="TrainingRecordTemplate" />
<input type="hidden" name="topicparent" value="%TOPIC%" />
<input type="hidden" name="action" value="form" />

<input type="submit" value="New Record"/></form>

and a simple template:

%EDITTABLE{editbutton="Record Training" header="|*-------Type-----------* | *Staff Has Existing*| *Required For post*| *training needs*  | *--Is-Training--* |*-------Date------* | *Venue* | *Details* |" format="|radio,1,Attributes,Experience,Qualifications | textarea,3x14 | textarea,3x14 | text,arwa3x14 | checkbox,1,Essential? | date,12, | text,20 | textarea,3x14 | "}%

*Reviewer:* Main.ChrisHogan - *Review Date:* 04 Jul 2008

Incidently, I got around most of the problem by simply adding

<input type="hidden" name="nowysiwyg" value="1" />

to my creator topics. Not 100% but better. I think if TinyMCE creates the topic it has fewer problems than with older topic which have a mixture of html & twiki shorthand

-- TWiki:Main.ChrisHogan - 04 Jul 2008

For some reason my PRE tags aren't working properly & I'm relucant to edit this topic directly, so (sorry), you'll have to raw view it to see my comments properly.

-- TWiki:Main.ChrisHogan - 04 Jul 2008

Changed to verbatim

-- TWiki:Main.KennethLavrsen - 04 Jul 2008

OK I created a creator topic and a template topic exactly like above.

But that it not the complete picture. You name="action" value="form" to work which should mean that you only edit the form of the topic.

But your example is a template without a form. So you get an empty editor with no form.

Please attach the example topics to the bug item. It takes so much time trying to understand and reproduce the problem this way.

Please put the template file, the creator file and the form file in a zip and attach it.

-- KennethLavrsen - 04 Jul 2008

OK I see the bug. I added a form to the template. Any form.

You are supposed to create a new topic with only the form visible in edit mode. But you see nothing. No topic, and no form.

I have attached the zip with creator topic, template and form. To reproduce put the 3 files in a web of a TWiki 4.2.0 with Wysiwyg enabled. View the creator topic. Create a topic. Note that the resulting topic has no form visible and no topic visibel. All you can do is save the topic.

If you put

<input type="hidden" name="nowysiwyg" value="1" />

in the creator topic then all works fine. Clearly the Wysiwyg editor should not goof up the action=form mode. It should just keep the editor invisible and show a normal form in edit mode.

-- TWiki:Main.KennethLavrsen - 04 Jul 2008

It is actually not that simple.

If I open the creator topic and hit the "New Record" button then I get no form.

If I select a name I see the form.

At least that is the pattern I seem to see.

Maybe it is the onblur thing that goofs it up.

When you have not selected a name the new topic is called Item5721RecordAUTOINC0000. If I have selected a name it becomes KennethLavrsenItem5721AUTOINC0000

It seems to work when the name has been altered.

I tried to make a simplified example where the new topic name is just fixed Itemxxxxxx. And then it works each time. It is the onblur thing that goofs it up.

This is a special case and I lower it to Normal priority.

-- TWiki:Main.KennethLavrsen - 04 Jul 2008

Kenneth, sorry for missing of the form - what a twit I am! And switching systems from something that did use PRE gave me a "mental block" on the use of verbatim.

The naming is unfortunately too complex in this case - and I was trying to find a simple example! I use a CALC to general the default name, but that extracted data from $GET style variables which search another topic, so I was trying to reduce the possibilities of interference from other processes.

I thought that I had some topics with a simple Itemxxxx style name, but I use a single creator topic for a lot of different classes of Quality Records, so the topic name is generated by


Not an onblur, but still a dynamic name - I wonder if that's still causing the same effect as the onblur?

anyway, for the time being the nowysiwyg=1 has resolved the problem for me.

Once more, sorry for not giving clearer examples.

-- TWiki:Main.ChrisHogan - 05 Jul 2008

The bug is more mysterious than I thought. It is not the onblur in itself.

If I change the creator topic in my example so the default name is a little different then it also works. All I have to do is change one digit in the

<input type="hidden" name="topic" value="Item5721RecordAUTOINC0000"/> 

so it becomes

<input type="hidden" name="topic" value="Item5722RecordAUTOINC0000"/> 

I wonder if some regex fails if the first characters of the topic name equals the name of the template

Ie Item5722RecordAUTOINC0000 as topic name and Item5721Template as template topic.

Is there something in javascript that only looks at the first 8 characters of a variable name or something silly like that that haunt us?

-- TWiki:Main.KennethLavrsen - 05 Jul 2008

I am adding to the story as I discover more. I may refactor later

If I have a creator topic like my attached example (which fails) and I change the template topic name from Item5721Template to Item5721bTemplate and rename the template topic to match then it does not fail either.

So the failure is triggered by the string Item5721 in templatetopic matching same in another place. Seeme next step is to change onblur="this.form.topic.value=this.value+'Item5721AUTOINC0000'"

It could be that the string prefixing Template matching the string before AUTOINC trigger is the bug. Will try now.

-- TWiki:Main.KennethLavrsen - 05 Jul 2008

That was not the case either.

I then continued with the line

<input type="hidden" name="topic" value="Item5721RecordAUTOINC0000"/>

and started changing that. And no matter what I change it cures the problem.


<input type="hidden" name="topic" value="Item5721RecortAUTOINC0000"/>

cures the problem.

I need to rest my mind a while to allow the deep inside of my brain to figure out what this strange pattern is. This is the strangest bug I have seen for a long time.

-- TWiki:Main.KennethLavrsen - 05 Jul 2008

Any Progress on this - exposing the template text, as opposed to just the form, is still a pain for our system

-- TWiki:Main.ChrisHogan - 30 Jul 2008

I have not looked at this one. I will give it maybe 30 minutes.

Have you tried some of the things I did that "cures" it. It may be a simple work around for your case to change the name of the template topic.

-- TWiki:Main.KennethLavrsen - 30 Jul 2008

I may have good news.

I believe the problem is fixed in 4.2.1.

There has been many code changes and I recently did some changes related to action=form.

I cannot say how it is cured but the exact same example topic always shows the form now.

-- TWiki:Main.KennethLavrsen - 30 Jul 2008

I have tested with IE6, IE7, FF2 and FF3. And I have used the exact same test topic.

There are two theories.

Either we fixed it with the many code fixes done the last 4 weeks. Or it is a CPAN update on my test server that cured it.

I have run the code on two different servers and I cannot see the problem on any of them.

I dare setting this as waiting for release

-- TWiki:Main.KennethLavrsen - 30 Jul 2008

Summary TinyMCE not honouring Template Topic in special cases.
ReportedBy TWiki:Main.ChrisHogan
Codebase 4.2.0
SVN Range TWiki-5.0.0, Sun, 01 Jun 2008, build 16865
AppliesTo Extension
Component TinyMCEPlugin
Priority Normal
CurrentState Closed

Checkins Fixed by other bug fixed. Exactly which is unknown
TargetRelease patch
ReleasedIn 4.2.1
Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip item5721exampletopic.zip r1 manage 1.6 K 2008-07-04 - 21:14 UnknownUser Creator topic, template topic and form
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r15 - 2008-10-17 - ChrisHogan
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback