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

I have the following very typical formatted search in quite many topics.

The same search is copy pasted 3 times below.

  • Original (raw view)
  • While in Compose mode
  • After having saved from Compose (again looking at raw view)

This means WYSIWYG is incompatible with one of the most important Twiki application features.

And it seems VERBATIM is broken too. You have to view the bug report in edit mode


%TABLE{columnwidths="55%"}%
| *Headline* | *Submitted By* | *Age* | *Last Change* | *Assigned To* |
%SEARCH{ "[B]ugStatus.*(value\=).*[R]eleased" casesensitive="on" regex="on" nosearch="on" order="modified" reverse="on" excludetopic="BugReports, CreateBugReport, BugReportTemplate, BugReportForm" format="| [[$topic][$formfield(TopicTitle)]]| $formfield(SubmittedBy) | $percntCALC{$ROUND($TIMEDIFF($TIME($createdate), $TODAY(), days)+1,0)}$percnt | $date<br /> $wikiusername | $formfield(AssignedBugTo) |"}%



%TABLE{columnwidths="55%"}% Headline Submitted By Age Last Change Assigned To 
%SEARCH{ "[B]ugStatus.*(value\=).*[R]eleased" casesensitive="on" regex="on" nosearch="on" order="modified" reverse="on" excludetopic="BugReports, CreateBugReport, BugReportTemplate, BugReportForm" format="| $formfield(TopicTitle)| $formfield(SubmittedBy) | $percntCALC{$ROUND($TIMEDIFF($TIME($createdate), $TODAY(), days)+1,0)}$percnt | $date<br />$wikiusername | $formfield(AssignedBugTo) |"}% 


%TABLE{columnwidths="55%"}% 
|*Headline*|*Submitted By*|*Age*|*Last Change*|*Assigned To*|
%SEARCH{ "[B]ugStatus.*(value\=).*[R]eleased" casesensitive="on" regex="on" nosearch="on" order="modified" reverse="on" excludetopic="BugReports, CreateBugReport, BugReportTemplate, BugReportForm " format="| [[http://merlin.lavrsen.dk/dakar/bin/view/Motion/$topic][$formfield(]] TopicTitle)| $formfield(SubmittedBy) | $percntCALC{$ROUND($TIMEDIFF($TIME($createdate), $TODAY(), days)+1,0)}$percnt | $date<br />$wikiusername | $formfield(AssignedBugTo) |"}%


The plugin can operate in two modes; it can either recognise and protect TWiki variables using spans, or it can treat them as plain text. The default is to treat TWiki variables as plain text, which is the appropriate mode for users whose main requirement is to edit topic text without variables. In this mode, TWiki variable parameter content is processed like any other text during saves, so may be damaged by the plugin.

The other mode defends TWiki variables using spans, and blocks conversion of parameter content during the topic save. However in this mode there is no UI support for adding TWiki variables. This would require a control to add these variable spans, and my client for this work asked for this to be removed.

The bottom line is that the Kupu is an HTML editor and not a TML editor.

At some point I will get time to add a control to manage these spans, and you will be able to switch over to the span mode for all users. But this is low priority for my client, and therefore for me.

CC


I am sure your client will change his mind once he finds out that the plugin destroys any page with just a little bit of intelligence.

How do I bring the WYSIWYG plugin into the "other mode"? If you with the "other mode" mean Set MARK_VARIABLES = on then I have just tried that and it still fails to maintain the Twiki code. Compose -> save and your search is destroyed.

this has been fixed recently, though there may still be outstanding issues

No unfortunately is has not. I just SVN updated to 7433 and it still screws up the search

-- KennethLavrsen


Let's ask him, shall we?

Colas? What's your take on this?

CC


I asked some of my users. One that uses TWiki a lot and make many applications said "I never expected to be able to so searches or funny codes in WYSIWYG mode. When I am a nerd I go in nerd mode (edit). But the code that is already there must never be modified by the WYSIWYG mode".

A manager that still does not use TWiki said that he did not want to touch it because of the difficult and strange codes and because it was impossible to navigate around in larger topics. He would start using TWiki if it gets WYSIWYG.

So we are OK that WYSIWYG cannot add or edit Twiki variables. People are OK to do that in edit mode. But when you update a topic all twiki variables must be left intact when you save it. I cannot see that this requirement goes against what Colas has requested. If one of his users edit a topic which contains some TWiki variables I am sure they will not want these codes to be replaced by garbage.

Where WYSIWYG is important is when people are editing large documents like our ISO9000 process documents and simple text only things like meeting minutes etc. Here 99% is plain text with no smart features. And then maybe at the bottom there is a little TWiki variable from a plugin or something which adds a smart little feature or there is a table created from a formatted search and these must just be left intact. It is OK that you have to change to EDIT mode to change these codes.

-- KennethLavrsen

Cool; that was Colas' opinion as well, IIRC. If the PHBs want to play, they can learn TML.

It still might be good to have an "I am going to mangle this content" warning. I need to think about that. Closing.

CC


You did not really read what I wrote. Please read again. I have bolded the text you missed.

It is not acceptable that WYSIWYG destroys any TWIKIVARIABLES.

It is acceptable that you have to use EDIT to change them must WYSIWYG must leave the twikivariable intact. Ie. if "Set MARK_VARIABLES = on" actually worked it would be OK. But it does not work! The formatted search example in this bug is destroyed when you compose and then save. THAT is the problem.

I re-opened the bug and I find this one a showstopper bug. Not a low priority one. We will all have users destroying one topic after the other - just because they altered some text and never had any intentions to touch with the advanced twiki features somewhere else in the topic.

-- KennethLavrsen


There are some compromises that have to be made. To fix this I had to disable square bracket links with variables. There may be parse errors as well if the variable definition contains HTML.

The problem is that TML is a macro language, and as such there is no way to accurately parse a TWiki topic. Variables may be used to generate arbitrary HTML. We just have to wing it, and hope nothing breaks.

SVN 7452

CC


I cannot say that all strange TWIKI variable expressions survives now BUT the formatted search that failed saves intact now so - great work CC.

Kenneth

ItemTemplate
Summary WYSIWYG alters and destroys formatted searches
ReportedBy KennethLavrsen
AppliesTo Extension
Component WysiwygPlugin
Priority Urgent
CurrentState Closed
WaitingFor

Checkins 7452
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r11 - 2005-11-14 - KennethLavrsen
 
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