Archive of WysiwygPluginDev

Note: WysiwygPlugin feedback is archived because it mostly applies to Kupu.

---

I tried installing on my TWiki test installation (XP:Cygwin:Apache following WindowsInstallCookbook) and encountered the following problems. Any help would be appreciated. Thanks for the work toward a WYSIWYG editor!

When I run WysiwygPlugin_installer.pl it throws a bunch of messages like:

I can't automatically update the revision history for
_kupu.xxxx:xxxx
Please upload the file in TWiki to update the history.

...then it quits with:

### WysiwygPlugin installed ###
Running Kupu installer...
/usr/bin/env: xsltproc: No such file or directory
make: *** [kupu.html] Error 127

When I attempt to view the page, I get the following errors appearing within the edit window (the edit toolbar seems to load):

Software error:

Can't locate Error.pm in @INC (@INC contains: c:/twiki/lib . /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int 
/usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/cygwin-thread-multi-64int /usr/lib/perl5/site_perl/5.8.5 
/usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/cygwin-thread-multi-64int 
/usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl) at c:/twiki/lib/TWiki/Plugins/WysiwygPlugin/TML2HTML.pm line 27.

BEGIN failed--compilation aborted at c:/twiki/lib/TWiki/Plugins/WysiwygPlugin/TML2HTML.pm line 27.

For help, please send mail to the webmaster (*removed*), giving this error message and the time and date of the error.

Content-type: text/html

Software error:

[Mon May 16 16:52:19 2005] c:\twiki\bin\view: Can't locate Error.pm in @INC (@INC contains: c:/twiki/lib 
. /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/cygwin-thread-multi-64int 
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/cygwin-thread-multi-64int
 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl) at c:/twiki/lib/TWiki/Plugins/WysiwygPlugin/TML2HTML.pm line 27.

[Mon May 16 16:52:19 2005] c:\twiki\bin\view: BEGIN failed--compilation aborted at 
c:/twiki/lib/TWiki/Plugins/WysiwygPlugin/TML2HTML.pm line 27.
Compilation failed in require at c:/twiki/lib/TWiki/Plugins/WysiwygPlugin.pm line 88.

For help, please send mail to the webmaster (*removed*), giving this error message and the time and date of the error. 

-- RolandJones - 16 May 2005

• Bug: Put's a lot whitespace in the topic.
• Usability: (Cannot reproduce) Buttons and access keys take focus out of text area.
• Usability: (Cannot reproduce) Cannot unembolded (italic/fixed) some text.
• Bug: (Possably me being confused) It alters what was in previous revisioins.

Don't take my word on those last three. I'll look at all four tomorrow and see if I can't get more concrete examples of how to reproduce them. I mention them only in case anyone else has noticed them and can confirm them.

-- SamHasler - 16 May 2005

Thank you Crawford and sponsor for contributing this to the TWikiCommunity. Especially non-geeks will benefit from this, e.g. we can broaden the appeal of TWiki

-- PeterThoeny - 17 May 2005

Always teething troubles.

Roland, the first point; as described in the install documentation, you require xsltproc or equivalent to install Kupu.

Second point: darn - that dependency is actually totally unneccesary (I was using it during debug) - I'll remove it. You can manually delete the use Error line from HTML2TML? .pm.

Sam, I see the whitespace. Grrr. That is clearly my fault.

I have also seen the unembolden effect, I thought it was just something I had done but it seems to be a Kupu - or even a Mozilla - bug. Kupu uses execCommand('bold') to toggle bold mode, so it may well be the browser that is screwing up.

On previous revisions; it has to be you getting confused. There is absolutely no way for it to modify old revs.

Thank you both for the valuable feedback! Keep it coming!

-- CrawfordCurrie - 17 May 2005

Did some further testing of v0.05: Compare the sources of http://kupu.skyloom.com/cgi-bin/twiki/view.cgi/Sandbox/TestTopic7 (created with plain edit and using TML) and http://kupu.skyloom.com/cgi-bin/twiki/view.cgi/Sandbox/TestTopic8 (emerged after an immediate save with Kupu).

Didn't do any table testing yet, cause there are enough problems with markup like that used in the test-topic(s) above.

-- FranzJosefSilli - 19 May 2005

Did update above TestTopic8 with output of v0.06 and added some (hopefully) clarifying comments (and screenshots) to above TestTopic7.

-- FranzJosefSilli - 23 May 2005

warnings/errors in apache's error.log (v0.10)

[Thu May 26 00:12:24 2005] [error] [client 200.79.141.16] File does not exist: /home/twikizen/kupu.skyloom.com/htdocs/twiki/TWiki/SmiliesPlugin/scull.gif

scull has to do with boats, not smilies

-- WillNorris - 26 May 2005

Awesome work, Crawford!

Just two things -

Firstly, as discussed on TWikiIRC, things break when RelativeURLs are forced by changing %PUBURLPATH% to be a relative URI, since then the <base href> becomes relative which is illegal according to the spec. Also as you note, TWiki::Plugins::WysiwygPlugin::getViewUrl() and ::parseWikiUrl() need to be tweaked.

Secondly, it would be good to make it clearer that it is necessary to unpack kupu.zip for things to work - my first impression from the installer script was that it was optional.

I suspect I'll have more feedback soon ... Cheers!

-- AdamSpiers - 01 Jun 2005

The CONVERT_SKIN setting doesn't seem to be used anywhere. Shouldn't it at least be used as the value of the skin CGI parameter in the kupu-editor <iframe> ?

-- AdamSpiers - 01 Jun 2005

I just tried out this plugin -- pretty cool. I did notice a problem with description list editing. The body of a description list item is rendered incorrectly unless each EOL has an escaped CR.

-- CarlRoth - 02 Jun 2005

I also uploaded an [[http://twiki.org/p/pub/Main/CarlRoth/]twiki-plugin-WysiwygPlugin-0.10-0.urs.1.nosrc.rpm[RPM source file]] for Fedora Core Linux.

-- CarlRoth - 02 Jun 2005

Rather, that should be a Fedora Core SRPM file.

-- CarlRoth - 02 Jun 2005

Adam, I meant to remove CONVERT_SKIN. My initial idea was to use it to control the plugin, by ended up using other means instead. The iframe is populated using ?skin=kupu;wysiwyg_edit=1 with a view URL.

Carl, do you mean it is rendered incorrectly after the topic is saved? Or rendered incorrectly during editing?

-- CrawfordCurrie - 05 Jun 2005

Any more feedback? Please?

-- CrawfordCurrie - 07 Jun 2005

wow, I'm really encouraged to get forward with twiki since the editor greatly improved since the former kupu-plugin. one bug? I have on my twiki is that as soon I put a %COMMENT% in my post, the other page content gets multiplied while editing with kupu.

-- CedricWeber - 07 Jun 2005

ok, more feedback :-), existing attachments are not displayed in the attachment dialog (Insert reference to attachment:), except if uploaded directly before inserting them.

-- CedricWeber - 07 Jun 2005

Crawford, I hate to see you pleading for feedback, please see http://yukongis.ca/bin/view/Sandbox/RichText. Some of the problems have been noted there since may 24th, the latest public version of whizzy. I pinged you about it then in #twiki but maybe you missed it. In any case I cleaned up my descriptions so that it might be easier to understand what's what (I hope!).

btw, this whole exercise has made it really clear why a 'summarise this edit' field would be a really useful addition to twiki. For this trial, I would use it to indicate whether any given save was being triggered by kupu or normal twiki, thereby making the Diffs easier to interpret.

-- MattWilkie - 07 Jun 2005

OK, I just upload V0.11 that addresses most of the issues raised so far. Please download and finagle.

Note that a lot of issues reported apply to Kupu and the browser, rather than the WysiwygPlugin, which works to be editor agnostic. Having said that I have put a lot of work into the editor to try and address some of the more glaring issues.

-- CrawfordCurrie - 16 Jun 2005

Many thanks for your work on this Crawford, WYSIWYG saved as TML is cruical to my continued use and support of TWiki; its just too hard to convince people without it.

I could not see the demo linked to on skyloom - can that link please point to somewhere where we can quickly evaluate?

-- MartinCleaver - 16 Jun 2005

Martin - why can't you see the demo link? I just checked it and it's working OK (although newest version isn't up yet).

-- LynnwoodBrown - 16 Jun 2005

updated to v0.11

-- WillNorris - 16 Jun 2005

What's up with the perl installer script in v0.11? It looks like the file was generated incorrectly:

+ perl WysiwygPlugin_installer.pl -a install Undefined subroutine &main::check_perl_module called at WysiwygPlugin_installer.pl line 36.

The code is trying to reference 'check_perl_module' before it's defined.

-- CarlRoth - 17 Jun 2005

I appreciate that not all the bugs we're seeing belong to the plugin proper -- they're not all a reflection on your great work Crawford! However for the end user there is no way of knowing where a bug's proper home is, and they don't care. It will be useful to know which goes where though so feedback can be directed accordingly.

Todays crop at http://yukongis.ca/bin/view/Sandbox/RichTextDot11

-- MattWilkie - 17 Jun 2005

On WYSIWYG, be warned that a lot of strange problems like contents duplication may be due to mod_perl, so it is recommended to turn it off

-- ColasNahaboo - 20 Jun 2005

I recommend the demo to skyloom goes to a testing page or web on skyloom rather than to the plugin page. After all, people need to edit to test and you don't want people editing the plugin page.

-- MartinCleaver - 20 Jun 2005

Done. See http://kupu.skyloom.com/cgi-bin/twiki/view.cgi/Sandbox/WysiwygPluginDemo .

-- LynnwoodBrown - 20 Jun 2005

First of all thank you for all the effort you put in Kupu.

• Has anybody checked the installer.pl "bug" mentioned by carl?
• I've tired to update WYSIWYG. It seems that the modules CPAN and LWP are required now?
• The installer also can't find TWiki::Merge in my case. Can anybody confirm that?
• Do I have to run the installer.pl for an update, or is it enough to unzip the files?

Im running Cairo realase btw.

-- CedricWeber - 21 Jun 2005

It ought to work OK without CPAN or LWP.

You can just unzip the files. Dependencies can always be resolved manually, if necessary.

There is a new pre-release - 0.12 - with a range of bugfixes that I'm just about to upload.

-- CrawfordCurrie - 22 Jun 2005

OK, it's uploaded. Sorry about the installer glitches, they should all be cured now as well.

-- CrawfordCurrie - 22 Jun 2005

The installer spews lots of errors when it can't write to the twiki warning log file (e.g. only apache has write access). This probably a good thing else they wouldn't be seen at all.

-- MattWilkie - 23 Jun 2005

Thanx for the update. Works quite fine on Firefox and I have been testing quite a while now. The only thing that worries me is that on IE6 some things don't seem to work, e.g.

• Inserting Links to Images and Attachments
• Inserting Wiki Tags (Variables)
• Insert a Link to a Wiki-Topic

As Matt mentioned earlier, I have no idea whether these things are Kupu, IE oder WYSIWYG connected. The problem is, that (as far as I know) users in most large corporate intranets are bound to Internet Explorer, so in my case I'm quite stuck :-).
Anybody testing with IE out there? Some hints or workarounds?

-- CedricWeber - 24 Jun 2005

If you can be more specific, I will gladly investigate. There are a lot of people testing on IE in ILOG (who are the client for this work) and they haven't reported any of these problems with 0.12 yet. The best would be if you can demonstrate these problems on a public site that is running the plugin, like skyloom.

-- CrawfordCurrie - 26 Jun 2005

On the demo URL, I clicked the Create Topic button with the default name, TestKupuVer0Dot11YourName? .

• It showed me the 'page does not exist' in Edit mode, which cannot be right
• At the bottom, I inserted the variables TWIKIVERSION and DATE through the pull-down menu, then clicked the SAVE button. Result: variables are not expanded but the text WIKIVERSION and DATE is inserted instead.
• the graphical interface for inserting links to other TWiki topics doesn't work (clicking OK doesn't close the window, IE shows "object does not exist" error (line 491 char 7)

I'm using IE6 with the Google toolbar on Win2K? .

(BTW: great work so far, this is looking to be a real killer app)

-- JosMaccabiani - 26 Jun 2005

Ok, here's the URL with the test: http://kupu.skyloom.com/cgi-bin/twiki/view.cgi/Sandbox/TestKupuVer0Dot11CedricWeber

• IE shows some javascrips errors in my case as well.
• Attachments do not work right now. I'll try again later.
• Kupu breaks Hyperlinks, e.g. %ATTACHURL%/file turns to http://.../.../%ATTACHURL%/file

-- CedricWeber - 28 Jun 2005

http://kupu.skyloom.com/cgi-bin/twiki/view.cgi/Sandbox/TestKupuVer0Dot11CedricWeber2 , this is what I get with Firefox.

-- CedricWeber - 28 Jun 2005

Is ist possible to parallel run two versions of wysiwyg on a twiki? so that I can follow up what actually changed and whats better or maybe worse than with the earlier version.

-- CedricWeber - 04 Jul 2005

Not without a lot of mucking about. However it would be easy to set up a second copy of TWiki and then use soft-links to link the data directories.

-- CrawfordCurrie - 04 Jul 2005

Just a small bug ( or me not using tables right ) all blank (single space) cells are turned into multispan (Strips the space) after saving.

I am using a space, not a nbsp as most of the table is generated from the edittable plugin with a pulldown field for these cells.

Great plugin, makes some of the more anxious of our users feel a bit more at home with a wiki.

-- BrianGreen - 06 Jul 2005

-- ChumpholKrootkaew - 07 Jul 2005

-- PaulFaulstich - 28 Jul 2005

A couple of notes:

1. I tried editing WebTopicViewTemplate to give users the option of using the WYSIWYG editor when creating a new page. However, the editor gets populated with the WebTopicViewTemplate content rather than the default content for a new page. Here is what I inserted:

   * Continue to <a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%?skin=kupu"><b>Create the new page with WYSIWYG editor</b></a>
   * Continue to <a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%"><b>Create the new page</b></a>

the first line is mine, the second line was there (and works fine).

1. It took me (a complete twiki newbie) hours to figure out how to have my standard header and footer contain links to this editor. For other newbies out there, the template that contains this is view._yourskin_.tmpl. Your skin is defined in Twiki.TwikiPreferences.
   • Note quite... your skin is defined in the SKIN preference setting (which may be defined in TWiki.TWikiPreferences, Main.TWikiPreferences, WebPreferences, user topic, or topic) -- TW

-- PaulFaulstich - 28 Jul 2005

There's a new upload, 0.13 - still a beta, but hopefully a few more of the problems have been worked out.

Paul, sorry, that mode of operation simply isn't supported, due to the way the edit script works.

-- CrawfordCurrie - 01 Aug 2005

Hey, great update. I've installed 0.13 and notice some things on IE6, Win2K? :

• resizing images in Kupu (with the handles) now seems to work fine, even though the plugin page says otherwise! Yay!

• on editing an existing topic that contains images (attached images files), sometimes the images do NOT work in Kupu (red cross appears). The behaviour doesn't seem to be consistent. One example is for the following link:

<img src="%ATTACHURLPATH%/fig1.png" alt="of river bed morphology in constricted river reach; uncertainty taken into account: future"  width="302" height="241"  />

• would it be possible to get a confirmation after upload of an attachment? (or even progress indicator?)

• would it be possible to access attachments from Kupu?

• why do some icons from TWikiDocGraphics work and others not?

• would it be possible to remove the Debug Log and change the size of the edit screen?

• the plugin doesn't play well with the SectionalEditPlugin: the small 'edit' links are treated as content, so after some edit cycles their number increases and there are div tags all over the place. To be exact, this ends up in the raw text:

<div align="right"> [[http://twiki/bin/editsection/Sandbox/TestTopic2?t=1123004891&sec=0#SECEDITBOX][<small>Edit</small>]] </div></div><div align="right"> [[http://twiki/bin/editsection/Sandbox/TestTopic2?t=1123005352&sec=0#SECEDITBOX][<small>Edit</small>]] </div>

• Currently, there is no way to insert the first TWiki variable in the pull down menu without first inserting an other one (since it works on an onChange event).

• If you change the text color or formatting in a heading and then change the heading level, the formatting is lost

• on right-clicking an image in Kupu, there is a 'create link' option. However, choosing this produces an error: "Attention. The "Sandbox/kupupopups/link" web does not exist"

That's it for now. Thanks again for the plugin.

-- JosMaccabiani - 02 Aug 2005

On my system using WysiwygPlugin (from DEVELOP svn) it looses all TWikiVariables? (expanding them to their result) - is this the case in the released zip?

-- SvenDowideit - 03 Aug 2005

not in my install from the .zip, variables are preserved properly.

-- JosMaccabiani - 03 Aug 2005

excellent! maybe its something broken locally!

-- SvenDowideit - 03 Aug 2005

Crawford Currie, I really like this kupu port you have developed, I am using it live at my work's installation of TWiki.

Wondering, have you seen this inline wyiswyg editor called wikiwyg?

http://demo.wikiwyg.net/wikiwyg/demo/standalone/

I think it's pretty neat, hope someone out there takes it upon themselves to port this to TWiki (would that my javascript is up to snuff).

-- IanFitzpatrick - 22 Aug 2005

Thanks Jefferson, I imported your reports to the bug tracking database.

Ian, the amount of javascript required to integrate an editor is minimal. The skills required are more to do with HTML. The challenge is to integrate the editor into a TWiki edit template. I hadn't seen wikiwyg, it looks like a derivative of htmlarea. The requirement for a Mozilla browser is a killer, though.

-- CrawfordCurrie - 22 Aug 2005

I see, so most of the work is converting between html and twiki markup? Yea, that's a mighty trickier.

Anyway, they say IE support soon, not sure how soon 'soon' is however. Just thought I would pass on the link on anyway though.

-- IanFitzpatrick - 22 Aug 2005

I added the missing SHORTDESCRIPTION and some standard rows in the Plugin Info table. I assume GPL, change this if needed. How about measuring and documenting the PluginBenchmarks?

Feel free to take the changes back into the next release.

-- PeterThoeny - 23 Aug 2005

Small feedback on the terminology "tag". It is important to use a consistent terminology. TWikiVariables should only be called "variables", not sometimes "tags" sometimes "variables". HTML tags are "tags", TWikiVariables are variables. They are called variables because they provide variable text. See docs at TWikiVariables.

One could argue that "tags" is an understood term with HTML authors. However, this is a different case here. IMO, it is better to use consistent terminology in order to avoid confusion.

-- PeterThoeny - 23 Aug 2005

A new kid in town: WikiWyg

-- PeterThoeny - 23 Aug 2005

Wow! I am so excited about this editor! I'll have to install it at work tomorrow morning.

As the TWiki is implemented further into our processes, the resistance to using TML is growing. My boss is getting frustrated by some in the department that simply refuse to use it without WYSIWYG. And I am geting tired of entering their text for them! Praise to Crawford and ILOG!

One final practical comment. The sample pages on skyloom are down or gone at the moment. Don't know if that is a temporary issue or not, just thought someone should know that the links are broken.

-- AlanDayley - 23 Aug 2005

I attempted to run the installer this morning, as promised above. I got some warnings so I aborted the installer. I don't have a sandbox installation of TWiki anywhere so I want to understand what I am doing as I install to a live TWiki. Upon running WysiwygPlugin_installer.pl I got:

# perl WysiwygPlugin_installer.pl
Warning: TWiki::Merge is not available, some installer functions have been disabled
Warning: LWP is not available, some installer functions have been disabled

I want to understand what these warnings mean and if I need to be concerned before I proceed. I am attempting to install on TWiki version 01 Sep 2004 $Rev: 1742 $, Plugin API version 1.025.

Any tips for me?

-- AlanDayley - 23 Aug 2005

Ignore them. They relate to the automatic dependency resolution mechanism. All they mean is that you will have to resolve missing dependencies manually, instead of the script doing it for you.

There is a new version, 0.15, just uploaded. This version has new icons, and a number of bugfixes (mostly for IE support).

-- CrawfordCurrie - 24 Aug 2005

is it possible to upgrade from v.1.2.1 to 1.3 rc2 without problems? how?

-- MichaelPauli - 24 Aug 2005

Thanks, Crawford. I have the editor installed. Myself and a couple of others are using it now before we tell everyone else it is there, though they may discover it.

We have found some small issues so far but are overall very impressed. I'll make appropriate WysiwygPluginProblemReports when we have them better defined.

-- AlanDayley - 24 Aug 2005

Michael, do you mean 1.3rc2 of Kupu? If so, well, I worked very hard to make sure that the Kupu release shipped with the plugin is exactly as packaged by the Kupu team, so in theory you should be able to install 1.3rc2 by simply unzipping it over the pub/_kupu directory.

Having said that, I haven't tried it, so I have no idea if any of the APIs that the TWiki customisation uses have changed. All I can suggest is that you try it, and let the rest of us know if it works!

-- CrawfordCurrie - 25 Aug 2005

Thanks for that great plug-in (both you and original authors).

A) The Kupu links on the page point to osqom when it is in fact oscom. I'm not fixing it myself, as you may have a script that automatically updates the page.

B) I tried 1.3rc2. Dropping it in as _kupu and rerunning perl WysiwygPlugin_installer.pl could NOT have it working. (don't forget to close your browser and clear your caches). Buttons show empty

C) The image resizing is implemented through a style:

<img style="width: 280px; height: 209px;" alt="t...

instead of tags:

<img width="280" height="209" alt="t...

I noticed that once my resize looks good, I could switch to the source mode, correct the code, and have it saved with the resizing parameters. Maybe this is something that you could fix on-the-fly while converting from TML to HTML ?

D) I would love to have also access to the standard html formatting codes in addition to the TWiki ones.

Change font type and size strike, underline,
all accessible through more buttons:

like that other textarea editor.

Thank you Crawford for all your efforts & support.

-- GillesEricDescamps - 27 Aug 2005

The newest version of kupu (at least svn #17078) does not work with WysiwygPlugin. Talking to CDot and guido_w (kupu developer) I found out, the kupu team added some i18n functionality to the editor. In order to make it working again, you have to either

• load the 'common/kupunoi18n.js' script in the templates, to turn off i18n support
• or download/install the following js lib: http://debris.demon.nl/javascripts/i18n.js

-- OliverKrueger - 30 Aug 2005

Hi Crawford

Could you please point me to the procedure that I've to follow so that my edits become part of that Plugin ?

Thanks -- GillesEricDescamps - 30 Aug 2005

Thanks Oliver! I'll upgrade to 1.3 when it is finally released; I don't really want to upgrade to anything before that.

Gilles, the easiest way to do what you want is to add another edit skin. That way you can develop a local version, or even experiment with many different versions.

1. Copy templates/edit.kupu.tmpl to templates/edit.gilles.tmpl
2. Use ?skin=gilles on the edit URL to invoke that skin instead of ?skin=kupu.

It should still use the kupu skin on the view request (to get the HTML of the topic being edited), but if that doesn't seem to be working you may have to:

• Copy templates/view.kupu.tmpl to templates/view.gilles.tmpl

You can either contribute that back as an alternative skin for the plugin, or persuade me that it should be the default! It would be really neat to have a range of skins, from "fully featured" through to "minimalist".

Happy hacking!

-- CrawfordCurrie - 31 Aug 2005

this maybe nothing but i would like to point out.

the example script from section "Using the translators from Perl scripts"

unshift(@INC,'/home/twiki/cairo/lib'); ^^^^ this line should be included within BEGIN block. otherwise, the 'use' will fail.

-- QiangLi - 01 Sep 2005

I guess what would be really great (but probably a lot of work) is, to be able to switch between Wysiwyg and TWikiML using the current Wysiwyg/html switch button in Kupu.

This would even be useful in the current state (where not all TWikiML? features are left intact after Kupu edit/save cycle).

-- JosMaccabiani - 04 Sep 2005

I had a little difficulty with the last step of the installation instructions to enable the editor.

What worked for me was to edit templates/view.tmpl (or in my case view.blueskin.tmpl) and change the line:

%EDITTOPIC%

to

%TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%?skin=kupu">Edit</a>

When the edit window appears, it's of course not in the blueskin template. It would be neat if the editor appeared within my template, replacing the text box.

-- MichaelGrant - 05 Sep 2005

The WysiwygPlugin currently changes the number of spaces within a TWikiVariables, leaving some of these non-functional (e.g., %TOPICLIST{" * $web.$name"}% ) after saving.

Note that the rendering of TWikiVariables in clear text is not really Wysiwyg... that aside, may I suggest

• TWikiVariables should not be changed in the edit cycle (in other words, they should be saved exactly as typed in, without spaces being collapsed; after the save, the TWikiVariables should be operational).
• Display TWikiVariables different from normal text (e.g., in a grey box) so that it is clear that these variables will not appear in this manner in the final document. Maybe TWikiVariables should be inserted and edited using a wizzard (such as tables or links).

-- ThomasWeigert - 05 Sep 2005

In WysiwygPluginProblemReports some people are reporting the use of version 0.16, but WysiwygPlugin has 0.15 attached.

Where can I find 0.16? Does it exist or is it just a legend?

-- JosMaccabiani - 08 Sep 2005

A legend? Nay, a fable perhaps! It's in Subversion, but isn't released yet. No-one is reporting against it, you are just seeing me saying when bugs will be fixed. Should be available today.

-- CrawfordCurrie - 09 Sep 2005

Kupu breaks Hyperlinks, e.g. %ATTACHURL%/file turns to http://.../.../%ATTACHURL%/file Where Problem?

-- VaidotasBarzdenas - 09 Sep 2005

As it says below, PLEASE ADD BUG REPORTS TO WysiwygPluginProblemReports - and give as much information as you can, the above report does not have enough information for me to be able to comment.

0.16 is released. It fixes most of the problems reported in WysiwygPluginProblemReports. It is still Kupu 1.2.1. I have also added better support for importing HTML using the framework.

Note to downloaders: I have moved the pub/_kupu directory under pub/TWiki/WysiwygPlugin, to fit with TWiki standards. Please delete the old pub/_kupu directory.

-- CrawfordCurrie - 09 Sep 2005

Thanx for the great updates! The Plugin works quite stable for now.

• Can anybody tell me how to hide the Debug Log? I tried display:none in some css files without effect. Any advice?
• What files need to be edited to remove or replace some smilies?

-- CedricWeber - 14 Sep 2005

I was asked to look into the use of wikis for a company intranet. I liked TWiki right away and have been playing with it for about a week, but I had a hard time envisioning how I was going to demo it for people with no html background (let alone TWikiML) until I ran into this great plugin. I haven't tested it extensively yet but wanted to put a thank you note to Crawford right away.

-- AntenehTesfaye - 25 Sep 2005

I'm having trouble getting this baby lifted :-). When I edit i.e. Main.WebHome and save it back with no changes, I go from:

---+!! Welcome to the <nop>%MAINWEB% web 
Congratulations, you have finished the TWiki installation. If you want to learn ..

to:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
  <style>
   @import url("http://server-name/twiki/pub/TWiki/PatternSkin/layout.css");..

.. so I guess I'm doing something wrong. Only problem is, I cannot figure out what it is. I'm running a clean developbranch (rev 6680) and the WysiwygPlugin_installer.pl runs fine. HTML::Parser and HTML::Entities are in place, and the editor loads and seemingly works fine.

If I edit in IE (6.0.2) the output are compressed (no linefeeds in topic text), if I edit in Firefox (1.0.1) linefeeds are doubled.

I won't report this as a bug, because I'm sure I'm just missing the obvious here. Anyone?

-- SteffenPoulsen - 29 Sep 2005

When the edited topic is shoved back to the server, the furniture you show above is supposed to be stripped off in the plugins afterEditHandler (which also convertes the HTML back to TML). Can you show me the whole saved topic, and not just the fragment above?

-- CrawfordCurrie - 30 Sep 2005

I have attached some debug / out here: WysiWygPlugin-HTML2TML-debug_SteffenPoulsen.txt (made against beta 2). Let me know if you have any ideas.

BTW: The plugin never shows up in InstalledPlugins, I have a feeling it should?

• *blush* I knew it was on me. Running configure and manually enabling the plugin helped things out. Now I can get on with the real bug reports -- SteffenPoulsen - 11 Oct 2005

-- SteffenPoulsen - 03 Oct 2005

The Problem with SectionalEditPlugin reported earlier on this page can be resolved by simply adding the kupu skin to the list of skins that shall not contain sectional edit links.
This may look like:

   * A comma separated list of skins *NOT* to section (you'll probably want the print skin here):
      * Set SKIPSKIN = print, plain, kupu

-- DanielSiegenthaler - 13 Oct 2005

Install Instructions need clarification: "To enable the editor in one of your skins, add the following link to the skin alongside or in place of the existing 'edit' link: Kupu

Where would this "skin" be located? I'm using the default patternskin, and can spot a bunch of files with "pattern" in the name. Does this string go into the template file, the CSS file or what?

Good technical instructions are explicit, telling the reader what to do, and where to do it. They don't assume that the reader is intimately familiar with the product.

-- TsuDhoNimh - 18 Oct 2005

The Kupu demo, at their site, allows creating table headings, selecting a grid style, etc.

|The TWiki plugin only allows me to choose number of columns and rows. Did I screw up the install, or is this the way it's supposed to work?

-- TsuDhoNimh - 18 Oct 2005

Another GPL Wysiwyg editor that is reportedly wiki-friendly: Xinha from http://xinha.python-hosting.com/

Again ... they are quite vague on the install process. Non-gurus like me need more guidance than "download and install this script".

-- TsuDhoNimh - 18 Oct 2005

Does anyone know how to make the edit window take up more of the browser window? When I go into edit mode, the bottom half of my browser window is wasted.

Great work on this plugin. It is much improved over the previous work. This is helpful to those on my team resistant to using the native TWikiML.

-- RickMach - 18 Oct 2005

Rick - Look on the various "preference" pages and try changing the window size there.

Does anyone know how to revert to an earlier revision of a page? I can view the revs, and print the revs, but I can't replace the current page with an earlier rev ... as one would need to do if the page is badly edited.

-- TsuDhoNimh - 18 Oct 2005

If you are using Dakar, there is a hack you can use to ensure new topics created by following non-existing links are created using kupu:

See Bugs:Item568

-- MartinCleaver - 02 Nov 2005

Is there any update on a version of the WysiwygPlugin that uses kupu 1.3?

-- JeffersonCowart - 10 Nov 2005

Just installed (according to instructions) and I'm facing a weird problem that seems to be related to SpeedyCgi?

If I edit and this save is appended to any prev save I've done with Kupu, even on other topics. If I touch bin/* to refresh SpeedyCgi? things work nicely once. Could not find any SpeedyCgi? references here so I'm wondering if there is something in my setup or am I the only one using it with this plugin

BTW, Cairo, Wysiwyg 0.16, Apache 1.3.33, RH3

-- OleCMeldahl - 11 Nov 2005

Jefferson; no. I never bothered, because 1.3 is just internationalisation. Ole; there are known problems with accelerators (mod_perl and speedycgi) that I think I have eliminated in the latest code (SVN 7460)

-- CrawfordCurrie - 15 Nov 2005

I'd like to be able to select the web when using the WikiWord link option so that topics from other webs can be linked. Thankyou.

-- ChrisDevine - 23 Nov 2005

Hi Crawford, any plans to publish a new version for us folks without SVN access?

-- CedricWeber - 28 Nov 2005

(Hopefully) closing in on a release date for DEVELOP, we would like to offer the WysiwygPlugin at our TWiki installation at the same time that we upgrade the installation to Dakar (and we have a need to educate the users anyway).

But I have one major headache - the WysiwygPlugin is also WhatYouGetIsNotWhatOriginallyWere (WygiNotWOW?). Editing a page like Main.WebHome (with just a few lines of somewhat advanced TML) using the WysiwygPlugin, ruins the functionality of the page.

But I had a thought: I think the way the editor handles verbatim is excellent; it seems to work without any side effects (that I can find, anyway :-)). So! Using the good old cut-n-paste concept, would it be possible to have a new tag in the editor, giving the same effect as verbatim when editing a page, but having no effect when "running" the page normally?

I.e.: A tag called something like <nowysiwygeditingherepleasethankyou> or just <TML> and </TML> (I claim no copyright, and I won't even be jealous if you think of something better, that won't clash with XHTML/TML and so on).

In the new setting, people odd enough to press the old-fashioned "Edit"-button will have no problems fencing (protecting) their TML-investment by the little tag, and the people "Composing" can happily go on without worrying what kind of functionality they might be breaking on their way. What they will see will be areas of clearly marked "Here be Tigris", and they can - while perhaps giving the areas a glance and wondering what in the world that code-style-like block actually does - easily avoid making havoc of them.

I am not sure whether this a good™ idea or not, but it would offer users like me some peace of mind on a way to (somewhat) seperate these two ways of editing - for the existing pages, most of the searches can be marked up using GlobalReplacePlugin (or else we can probably think up some jedi perl tricks for this kind of stuff :-)).

- I realize that using Set DISABLEDPLUGINS is another way of protecting the TML, but by implementing a tag like descriped I think we would be closer to achieving a best-of-both-worlds solution.

-- SteffenPoulsen - 01 Dec 2005

Steffen, nice idea. I was thinking ofg the opposite: have kupu add on save a tag <!--WYSIWYG_OK--> and have kupu only be able to edit these pages. (so you could only edit pages created by kupu or explicitely tagged so. But your idea to be able to delimit parts to be edited verbatim is really interesting.

• I think the scenario you mention can already be achieved using disabledplugins (globally disabled, locally enabled). Well, I'm really just concerned for the users; I know that I myself would be pretty confused if my prefered editor would only work on certain pages etc. There are other ways you could think of to try to go forward, protecting the content, one would be exclusing blocks containing i.e. a %SEARCH% or a <form> from editing (or perhaps just make this exclude-blocks-with-tags-list a configurable setting for the plugin), etc. All I'm trying to go for, is, that the users preferring the WysiwygPlugin can't and won't hurt themself (or any twiki content), unintentionally. If they get the feeling that it's not to be relied upon, I'm afraid they won't touch it. -- SteffenPoulsen - 16 Dec 2005

-- ColasNahaboo - 05 Dec 2005

To allow users to select the first Twiki Variable without needing to select a different variable first I have added:

<option value="Insert Twiki Variable">Insert Twiki Variable

At this section in the edit.kupu.tmpl file:

      <select id="twiki-var-select">
   <option value="Insert Twiki Variable">Insert Twiki Variable
       %WYSIWYGPLUGIN_TAGS%
      </select>

And to make it so %% does not get added if someone selects "Insert Twiki Variable" I have added:

   if(name == "Insert Twiki Variable"){   
      elem = doc.createTextNode("");
   }

under elem = doc.createTextNode('%'+name+'%'); in the TWikiVarTool? function inside the twiki\pub\TWiki\WysiwygPlugin\twikitools.js file.

I would rather make the highlighted selection jump back to "Select Twiki Variable" after the selected variable is inserted into the page but I am not sure what needs to be set to make that happen.

-- ChrisBentley - 07 Dec 2005

One thought: maybe the next generation of WYSIWYG editor should be more restrictive in what it allows to be entered where to simplify reuse of the (thus) structured content. Compare e.g. this Arbortext Contributor Demo (hint: press the fast forward button to jump over the lengthy (useless) intro).

-- FranzJosefSilli - 15 Dec 2005

I surprised myself by expressing the following paragraphs in a bug report yesterday - I don't know where it should have gone, really, in essence it's just paraphrasing the comment from above. I think I'll go for adding some bug reports for now, trying to avoid these outbursts :-/

There are lots of issues like this with wysiwyg still (for instance it removes <nop>, &nbsp; and other tags everywhere, has problems with nested TML inside HTML tags, eliminates/adds whitespace ad libitum etc) - I'm concerned how to avoid intimidating wysiwyg users by side-effects of the plugin. In http://twiki.org/cgi-bin/view/Plugins/WysiwygPluginDev I suggested a tag for "fencing" delicate content, and I still feel feel there's a need for "something in that direction". Not only to avoid non-TML'ers to wrec havoc in the topics - but even more so to avoid them being intimidated by it. They'll hate wysiwyg (.. and therefore TWiki) in no time, if it's unreliable.

I don't mind marking up some searches and other specially crafted (H)TML if I know it'll keep the wysiwyggers out of trouble - but knowing that there's "accidents waiting to happen" shattered all around the wiki, just waiting for a wysiwygger to stop by, I'd have a hard time living with.

I know this is not the place to start a discussion, but I just don't have a general feeling on which way things are headed on these kind of issues - and it bothers me. I see a two track road starting at the moment, TML'ers being even more smart, and (ldap'ed) wysiwyg'ers coming on board with a totally different expectation to how things (should) work, but now finally being able to do their stuff with little effort.

I'll move this comment to WysiwygPluginDev asap - I guess I just needed a bit of attention for a moment.

-- SteffenPoulsen - 04 Jan 2006

I've got the plugin installed, but it seems not to be functional. The editor layout is all screwed up. There is the main editing bar followed by several

OK

and

Cancel

buttons down the center. The editor window seems to be only 200x100 and on the bottom left of the page.

I did get two errors during install:

Warning: TWiki::Merge is not available, some installer functions have been disabled

Warning: LWP is not available, some installer functions have been disabled

I also saw:

WARNING: I cannot automatically update the local revision history for:
        data/TWiki/WysiwygPlugin.txt
        pub/TWiki/WysiwygPlugin/cancel.png
        pub/TWiki/WysiwygPlugin/bold.png
        pub/TWiki/WysiwygPlugin/new-image.png
        pub/TWiki/WysiwygPlugin/table.png
        pub/TWiki/WysiwygPlugin/code.png
        pub/TWiki/WysiwygPlugin/definition-list.png
        pub/TWiki/WysiwygPlugin/nop.png
        pub/TWiki/WysiwygPlugin/inthyperlink.png
        pub/TWiki/WysiwygPlugin/twikitools.js
        pub/TWiki/WysiwygPlugin/outdent.png
        pub/TWiki/WysiwygPlugin/exthyperlink.png
        pub/TWiki/WysiwygPlugin/italic.png
        pub/TWiki/WysiwygPlugin/remove.png
        pub/TWiki/WysiwygPlugin/separator.png
        pub/TWiki/WysiwygPlugin/screenshot.jpg
        pub/TWiki/WysiwygPlugin/kupustart.js
        pub/TWiki/WysiwygPlugin/ordered-list.png
        pub/TWiki/WysiwygPlugin/smiley.png
        pub/TWiki/WysiwygPlugin/help.png
        pub/TWiki/WysiwygPlugin/vars.png
        pub/TWiki/WysiwygPlugin/undo.png
        pub/TWiki/WysiwygPlugin/new-attachment.png
        pub/TWiki/WysiwygPlugin/indent.png
        pub/TWiki/WysiwygPlugin/kuputwiki.css
        pub/TWiki/WysiwygPlugin/save.png
        pub/TWiki/WysiwygPlugin/redo.png
        pub/TWiki/WysiwygPlugin/unordered-list.png
        pub/TWiki/WysiwygPlugin/verbatim-watermark.png
        pub/TWiki/WysiwygPlugin/verbatim.png
        pub/TWiki/WysiwygPlugin/view-source.png
        pub/TWiki/WysiwygPlugin/text-color.png
        pub/TWiki/WysiwygPlugin/kupuinit.js

Any thoughts...

-- MikeSeibert - 10 Jan 2006

Never mind I re-ran the install script and it seems to be working at a basic level. The one question I still have is making kupu the defualt editor. I have EDIT_SKIN = kupu set in TWikiPreferences? since I want it to be global, but it still takes me to the defualt editor when I click the edit link.

-- MikeSeibert - 10 Jan 2006

Note; please don't report problems here; report them in Bugs web. I only read this topic once a month or so, but I read Bugs web every day.

-- CrawfordCurrie - 13 Jan 2006

I've got a similar problem as Mike has. I already installed the Plugin but it is not functional und looks heavily damaged. I made two screens, here they are:

Does anyone know what to do?

-- PeterShawn - 17 Jan 2006

Check the owner and rights of all twiki files. After correcting this disappeared on my installation

-- RainerStengele - 19 Jan 2006

I cannot get the table insert to work. Any ideas? It just doesn't do anything!

-- RainerStengele - 19 Jan 2006

Rainer, that looks very much like JavaScript? gave up halfway through loading. Try running with a javascript debugger installed. I can't tell what version of the plugin you are running to say more.

-- CrawfordCurrie - 25 Jan 2006

Hi! What version is the download in WysiswygPlugin? ? It seems that with that version there comments are still stripped... this is very bad for me as we are keeping important data in comments... Unfortunately I cannot download from svn here (firewall)... so would anybody be so kind to provide me with a working plugin package?

-- PeterLohmann - 25 Jan 2006

Hello. I'm a technical writer with an English degree; I have no programming experience so please excuse my lack of knowledge.

I just installed TWiki this past Monday, the 23rd, as a test system. My flavor of TWiki consists of Apache 1.3.34, Cygwin 1.5.18, and TWiki20040904 running on a WinXP Pro machine with IE6. I downloaded the WYSIWYG plugin on January 24, 2006 at approximately 04:25pm EST. I'm not sure what version that is, but hopefully this information helps. Today (the 25th), I installed the plugin. To do this, I launched Cygwin and successfully unzipped the WysiwygPlugin.zip file. I attempted to run WysiwygPlugin_installer, but couldn't figure out how so I just launched CPAN from Cygwin and did a "cpan> install HTML::Parser" and then "cpan> install HTML::Entities". I then verified that they were installed and up to date. Next, I opened view.pattern.tmpl (Set SKIN = pattern is what's configured in my TWiki.TWikiPreferences) and inserted a:

<a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%?skin=kupu">WYSIWYG</a>

line directly below the:

Edit

line and directly above the:

<a href="%SCRIPTURLPATH%/attach%SCRIPTSUFFIX%/%WEB%/%TOPIC%">Attach</a>

line.

I saved the changes to the file and closed it. I refreshed IE and my "WYSIWYG" link appeared at the top of TWiki, sandwiched between the standard "Edit" and "Attach" links, just as I wanted. Now, if I click the "WYSIWYG" link for a given topic, it appears to work just fine. In fact, it even allows me to edit the topic using the Kupu UI without any problem. My issue arises when I click the save (disk) button that is part of Kupu. When I do this, TWiki returns to the "view" state of that topic (as it should), but the entire content of the topic is deleted and replaced with "undefinedundefined".

Any input is greatly appreciated. (Please be specific in your response - I have a non-technical background, but am comfortable editing files if I know exactly which ones to edit and what edits to make.) Thanks!

-- JasonVensel - 25 Jan 2006

As you have probably realised by now, you hit a bug that was fixed many versions ago -- CrawfordCurrie - 28 Feb 2006

Thanks RainerStengele? , now the PlugIn? looks like it should be but it still doesn't work well. I'm able to submit new content, but the format-options (e.g. bold, underlined) were not displayed (as shown in the preview).

Any suggestions?

-- PeterShawn - 27 Jan 2006

At least a couple people including myself have encountered problems using kupu with IE, it saves the page but empties the content completely. I've uploaded a patch to sarissa.js (and the fixed file in case anyone has problems applying the patch) that should fix the problem. I'm not sure if this problem is only in the TWiki integrated kupu or in kupu in general.

-- MikeMoretti - 29 Jan 2006

As you have probably realised by now, you hit a bug that was fixed many versions ago -- CrawfordCurrie - 28 Feb 2006

Is there a reason that kupu's spellcheck is disabled in the plugin? It didn't take too much work to enable... though I re-wrote the "spellcheck.cgi" as a simple wrapper around Text::Aspell soas to not require python. If there's any interest I can post it...

-- KenGoldenberg - 17 Feb 2006 No, except that my client didn't explicitly request it, and I was trying to avoid loading anything not absolutely essential, due to the size of the JS -- CrawfordCurrie - 28 Feb 2006

Jason/Mike - Did you ever find a solution to your problem? I am seeing the same problem and I don't know how to fix it.

-- JeffersonCowart - 23 Feb 2006

As you have probably realised by now, you hit a bug that was fixed many versions ago -- CrawfordCurrie - 28 Feb 2006

I just upgraded to TWiki 4.0.1 and everything is working great. I'd like to make Kupu my default editor for a web and I tried adding 'Set EDIT_SKIN = kupu' to WebPreferences, but it does not seem to be working. Are there any other settings I need to have in place? I am using the default pattern skin.

-- AdamEllis - 28 Feb 2006

Ah - it appears I should read code, and not docs. EDIT_SKIN support seems to have been removed (or more likely never existed except as a doc)

-- CrawfordCurrie - 28 Feb 2006

Suggestions:

• Left & right cell align problem in Info table
• Missing Appraisal row
• Use full URL instead of Interwiki links for home, dev and appraisal links

-- PeterThoeny - 28 Feb 2006

Some advertisment for the MarkupEditorContrib. It is not a Wysiwyg-Editor, but rather enhances the textarea to help with input by offering auto-indent and markup-insertion-buttons.

-- ChristopherOezbek - 02 Mar 2006

The Plugin is really great now. The only thing my users (used to Word etc.) miss is the ability to paste an image from the clipboard. I realize that kupu can do that - but stores the file in a local temporary file. If this function could be used to make an attachmant this would be a great benefit.

-- PeterSchaich - 06 Mar 2006

I also experienced an "undefinedundefined" error while saving a topic by KUPU, even I'm using Twiki 4.0.1 but I installed another instance on my laptop, it works fine, anyone can help?

-- XieXiaopu - 19 Mar 2006

The latest version attached to the topic incorporates several new fixes.

Paste an image from the clipboard? yeah, right. Please feel free to contribute a patch!

The undefinedundefined error was fixed a long time ago. Download and install the latest release.

-- CrawfordCurrie - 04 Apr 2006

I can't get this to work. I just installed the Plugin version of April-4. HTML::Parser (includes Entities) and HTML::Tagset are installed. I ran the Wysiwyg_installer.pl and everything ran ok and the WYSIWYG button now appears as expected on teh bottom of each topic. (The URL has ?cover=kupu appended for this button.)

When I click on the buton I see a page with a line of icons on the top. There are alot of blank lines followed by a 'OK' and 'Cancel' buttons. Again more blank lines and more 'OK' and 'Cancel' buttons. At the very bottom of teh page I see a tiny window containing the contents of the topic. I am unable edit the contents.

Please can you help?

-- PeterJones - 05 Apr 2006

My above problem was linked with file permissions. After the installation of the plugin some of the _kupu files were readonly by the owner and so the apache server complained that it could not read them. I changed the permissions and the editor works. (except for inserting a Twiki icon!)

Can you clarify: The Dakar release notes states that the WYSIWYG is a new feature (http://twiki.org/cgi-bin/view/Codev/DownloadTWiki). The feature does not seem to be available out of the box after the installation of version4. After installation of Dakar one has to install this Plugin.

-- PeterJones - 06 Apr 2006

Peter, it is available out of the box, but you have to enable it in configure

-- JosMaccabiani - 06 Apr 2006

Peter, it sounds like your browser can't load the CSS files it needs. Use "view source" in the browser to look at the source of the page; you will find several places where there are lines saying @import url(...). Check that the resources referenced in these statements can be accessed by the browser (copy whatever is in the brackets and paste it into the URL bar). Also check the javascript console for warnings.

Oh, and make sure Javascript is enabled in the browser!

-- CrawfordCurrie - 10 Apr 2006

All works fine now except the 'Insert TWiki Icon' feature. Clicking on this does nothing but insert a line (or perhaps its a very small box) at the top of the edit page. What should expect to see when clicking on this feature?

-- PeterJones - 11 May 2006

It should generate a pop-up with all the icons you have defined in your settings. Check that your plugin topic includes a definition for the icons (it's described in the topic)

-- CrawfordCurrie - 12 May 2006

Is there a reason that kupu's spellcheck is disabled in the plugin? It didn't take too much work to enable... though I re-wrote the "spellcheck.cgi" as a simple wrapper around Text::Aspell soas to not require python. If there's any interest I can post it...

-- KenGoldenberg - 17 Feb 2006

Ken, please post your hack. I would like to enable spell check in Kupu.

-- AlokNarula - 13 May 2006

It looks like someone was editing the WysiwygPlugin topic with the WYSIWYG editor, some tables, image tags and other HTML tags changed. It would be good to be able to control the WYSIWYG editor links on a per page basis. For example, all extension topics on TWiki.org would have WYSIWYG editing disabled.

-- PeterThoeny - 06 Jun 2006

I don't understand. Why shouldn't someone be able to edit this page or any other with the WysiwygPlugin? (Unless, of course, one is running Safari, in which case it just doesn't load.)

-- MeredithLesly - 06 Jun 2006

The use of WysiwygPlugin does introduce more noise in diffs than we're used to, as different browsers render output differently and so on and so forth.

For disabling wysiwyg editing on a single topic you can use

• Set COMPOSER =

Which disables wysiwyg edit of this page (wysiwyg button is still there, but it triggers a regular textarea edit now). There are other settings that have a broader scope (WYSIWYGEXCLUDE if I remember correctly).

Crawford recently stated that someone else is on its way which might replace this editor, but until then strategy should still be to bug-report reproducible side-effects seen (one report per case).

-- SteffenPoulsen - 06 Jun 2006

What I really meant was, why would one want to disable it on certain pages rather than altogether? If it doesn't work, it should be disabled; if it does work, what's the problem? It doesn't sound very user-friendly to have different topics have different editors, or to have the wysiwyg button come and go as one edits.

-- MeredithLesly - 06 Jun 2006

Wysiwyg is neither "it doesn't work" nor "it does work" imho (but mostly the latter :-)). It's a new tech that is maturing - and twiki.org is indeed an excellent place to have it tested as many follows the diffs here.

At TWikiHistory#TWiki_Release_4_0_0_Dakar_01_Feb release time we discussed some over how to label this / distribute this and we ended up including it with the dist and labelling it "beta". Once wysiwyg leaves this beta phase we can remove these restrictions again. But to get there we need to have the last bugs reported and fixed; luckily there are lots of topics to test it on, even if a few topics are excluded from being wysiwyg'ed temporarily

-- SteffenPoulsen - 06 Jun 2006

That makes sense. I do wish Peter had been clear about why he wanted to disable it, since the comment gave no information.

I still don't understand why TWiki has a beta plugin as part of its standard distribution, but that's another issue altogether.

-- MeredithLesly - 06 Jun 2006

Small point -the WysiwygPlugin_installer.pl should probably start with a #!/usr/bin/perl shebang line

-- PaschalNee - 28 Jun 2006

WysiwygPlugin_installer.pl also seems to assume that the pub directory is in the main twiki directory. Pub can be located elsewhere from the /configure script. Could the WysiwygPlugin_installer.pl read the location from the config?

-- PaschalNee - 28 Jun 2006

Revisiting (SteffenPoulsen? - 01 Dec 2005) re <TML> idea.

As our Twiki is getting more use, I am seeing problems related to embedded clever TML, broken by the trip through the WYSIWYG editor. (Example: standard "Recently change topics" %SEARCH% TML on WebHome pages).

I have implemented an excaping work around using the <TML> tags to safely protect clever TML from WYSIWYG mangling.

I am not sure what is the Current version of this plugin. I would be happy to post the diffs.

-- CraigMeyer - 05 Jul 2006

I found that the wysiwyg editor ignores the templatetopic cgi parameter, which kinda annoyed me so i hacked in support for the parameter in the template and the plugin:

* wysiwyg_templatetopic.patch: Patch for templatetopic support.

-- KoenMartens - 24 Jul 2006

Hi, I'm having a lot of trouble getting the Wysiwyg plugin working despite repeated attempts. Is this the right place to ask for help? thanks!

-- MattBWood - 16 Aug 2006

You can ask a question in the Support, or drop by in TWikiIRC.

-- PeterThoeny - 16 Aug 2006

I'd submit a bug, but my account doesn't seem to be working on http://develop.twiki.org/ just yet. I'll try again tomorrow. In the meantime, the edit.kupu.tmpl shipped in version 11539 has some strange syntax in its kupu-editor iframe's src URL. %OWEB% and %OTOPIC% don't exist, and the URL uses semicolons to separate CGI parameters instead of ampersands. There's also a spurious foo=bar assignment. The plugin works fine for me after I apply the patch I attached below.

-- RobertAu - 27 Sep 2006

The HTTP spec specifies either ; or & to separate parameters. I use ; by preference because it doesn't require HTML encoding.

The OWEB and OTOPIC came from Koen Martens patch for template topic support. It worked fine for me; but I'll check again. Unless .... what TWiki version are you using?

-- CrawfordCurrie - 28 Sep 2006

Sorry about the lack of detail. I'm running TWiki 4.0.4-3 on Apache 2.0.52, and hadn't applied Koen's patch yet. I've applied the patch, and OWEB and OTOPIC work fine now. The semicolons still don't work for me, and I'm not sure why; CGI.pm is up to date and supports splitting on semicolons, for example. I'll keep poking around. At any rate, does the foo=bar assignment from Koen's patch do anything?

-- RobertAu - 29 Sep 2006

I had a problem where Wysiwyg didn't work but instead displayed "Can't locate HTMLpath in @INC" etc. notification. I installed the Perl HTML-parser and the problem was solved, it works now. The problem is that the parser is not distributed automatically along Perl. Didn't see any mentioning anywhere on this so I added this note here.

-- MikkoLaakso - 27 Oct 2006

I would like to revive the idea of pasting images from clipboard. Has anyone found a solution for it? Thanks,

-- MiloValenzuela - 21 Nov 2006

Milo, did you look at the JavaPasteAddOn ?

-- KeithHelfrich - 23 Nov 2006

Yeah, however it remains non-functional and the plugin seems to be looking for an owner. Unfortunately I'm not a java/perl programmer.

-- MiloValenzuela - 27 Nov 2006

Has anyone compared the WYSIWYG with XinhaEditorPlugin ?

-- MiloValenzuela - 27 Nov 2006

You mean "compared Kupu to Xinha". Kupu just happens to be the default editor used by WysiwygPlugin. Some day I will decouple them.

-- CrawfordCurrie - 28 Nov 2006