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

Item5828: TinyMCEPlugin Breaks SectionalEditPlugin

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension EditContrib Normal Being Worked On TWiki:Main.ThomasWeigert n/a  

Edit Form Data

Summary:
Reported By:
Codebase:
Applies To:
Component:
Priority:
Current State:
Waiting For:
Target Release:
Released In:
 

Detail

CC, this plugin somehow completely destroys pages that are setup to be used with the SectionalEditPlugin. If a user inadvertently edits such a topic, after the edit, all text is one giant string with all the newline characters removed.

This is bad, as it destroys the topic in an irrecoverable way.

Can you please explain what this plugin does to the text, so that I can protect against this behavior...

Thanks...

-- TWiki:Main/ThomasWeigert - 28 Jul 2008

I'm guessing, but it sounds like you may be using a plugin handler that conflicts with the WysiwygPlugin afterEditHandler. This handler is responsible for converting the edited text (which is at this stage HTML) into TML before saving into the topic. If you have another handler doing other stuff (probably before it) then it may invalidate the HTML. Just a guess.

There are various ways to turn off WYSIWYG that you may be able to use on pages with sectional edit. These are documented in WysiwygPlugin and TinyMCEPlugin.

-- CrawfordCurrie - 29 Jul 2008

CC, the point is not to turn of this plugin. The point is that this plugin should not be destroying a topic. I think that is a no-no in TWiki land.

I think that there should not be a handler that takes correct TML and generates incorrect TML when combined with other handlers.

This interaction may just be one symptom of a larger problem that could occur with other plugins as well. I think we need to determine exactly what is going on so that this can be avoided.

I'd gladly help searching for the problem, if you can give me some guidance as to where to look...

-- ThomasWeigert - 29 Jul 2008

Here is how the edit sequence happens:

  1. SectionalEditPlugin provides an edit script which generates a special edit topic. Some topic text is passed in URL parameters, only the editable section is in the text area.
  2. WysiwygPlugin takes over the text area and turns it into HTML.
  3. On "save" the text passed in the URL parameters (pre and post text) and the text from the text area are concatenated and passed to the save script.
  4. WysiwygPlugin in the afterEditHandler translates that string to TML, but part of the string is in TML which apparently does not work well.

I think that Wysiwyg plugin must not mess with the text area and then not clean up before other plugin aspects could come into play. We must somehow assure that it only deals with the portion of the edited text that it actually manipulated, but not with the whole text, as this could be from many sources.

I'd suggest that you mark the beginning and end of the text touched by WysiwygPlugin and only translate that text in HTML2TML.

-- ThomasWeigert - 29 Jul 2008

The save script is somehow concatenating together the pre, text and post parameters to create the new topic, right? So if the afterEditHandler in the WysiwygPlugin is only called on the text that was actually edited, and not on the pre and the post, there should be no problem, right?

  • Yes, that would be correct.

Further, I assume it is your handler that is doing the concatenation (I don't recall and handling of pre and post in the save script). If I'm correct you just have to make sure the WysiwygPlugin is called before the SectionalEditPlugin (e.g. using PluginsOrder).

  • No that is not sufficient. For one, the concatenation has to be done in the save script, not in a handler, as otherwise one cannot pass the data. So there is no way to cause the WysiwygPlugin to do its thing before SectionalEditPlugin.

Note that the afterEditHandler in the WysiwygPlugin will only convert text if it sees the secret id in a comment in the text or the wysiwyg_edit URL parameter is set.

-- TWiki:Main.CrawfordCurrie - 30 Jul 2008

CC, I think you need to make the following change to WysiwygPlugin to not risk the kind of problems it causes right now with SectionalEditPlugin:

  • insert a begin and end marker around the text that had been changed by WysiwygPlugin when going into edit mode
  • in afterEditHandler convert only the text between the begin/end markers back into TML.

The secret id is not sufficient, as it applies to the whole text.

-- ThomasWeigert - 31 Jul 2008

OK, I looked through the code of the SectionalEditPlugin and the EditContrib to understand where this concatenation was coming from.

IMHO the WysiwygPlugin isn't doing anything wrong. It has been asked by the parameters to convert some text from edited HTML to TML, and that's what it's doing. The fact that you have crammed together some pre-existing TML with that HTML is a problem in the EditContrib, not in the WysiwygPlugin.

The afterEditHandler is designed to post-process the text that was edited; that's why it's called where it is in the save process. However because you are using a custom save script, the EditContrib has already concatenated the un-edited portions of the topic back onto the text before the handler gets a chance to be called. IMHO the savesection script= in the EditContrib is architecturally wrong. The concatenation of the unedited sections of the topic should be happening in an afterEditHandler, and if it were, then you would not need bin/savesection and it would work with WyswiygPlugin ({PluginsOrder} permitting). Note also that even if it isn't fixed now, savesection is going to have to be rewritten for TWiki Stand Alone.

Of course there is an issue here with merging. The WysiwygPlugin is careful to provide a beforeMergeHandler to ensure that content conversion is done as early as possible. I think the EditContrib should be following the same pattern.

I revised the allocation to the EditContrib, which is where the fundamental problem lies, and confirmed the bug.

-- CrawfordCurrie - 31 Jul 2008

You probably are right about the assertions regarding architecture that you are making, but I think you are wrong about claiming that WysiwygPlugin is innocent. WyswyigPlugin should only operate on text that comes from the textarea. In this case, it works on text outside of the textarea. You can easily avoid doing that.

-- ThomasWeigert - 31 Jul 2008

moved further discussion regarding WysiwygPlugin to Item5858... --TW

I have rewritten the EditContrib to use afterHandler instead of special save script. There are still problems caused by WysiwygPlugin in that it leaves HTML in the topic that messes up sectional editing. This is discussed also in Item5858.

-- ThomasWeigert - 01 Aug 2008

ItemTemplate
Summary TinyMCEPlugin Breaks SectionalEditPlugin
ReportedBy TWiki:Main.ThomasWeigert
Codebase 4.2.0
SVN Range TWiki-5.0.0, Sun, 27 Jul 2008, build 17148
AppliesTo Extension
Component EditContrib
Priority Normal
CurrentState Being Worked On
WaitingFor TWiki:Main.ThomasWeigert
TargetRelease n/a
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2008-08-01 - ThomasWeigert
 
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