Proposal: Replace Kupu WISIWYG Editor with TinyMCE

Given the way TWiki 4.2 is dragging along, we have already reached the point where TinyMCEPlugin is (IMHO) a higher quality WYSIWYG solution than Kupu, and is more functional and attractive than any of the other editing alternatives.

Thanks to the support of a client, I have been able to eliminate the last of the (reported) bugs in WysiwygPlugin, which leaves all the WYSIWYG editors in much better shape. Functionally, TinyMCE and Kupu are very similar. However TinyMCE has a number of small advantages over Kupu that make me think it should be adopted as the default WYSIWYG editor:

1. It does not require a special template; it works happily within the standard edit template, which makes life a lot easier for skin designers
2. TinyMCE has the absolute minimum of supporting JS, whereas Kupu has hundreds of lines in several code modules
3. I have done the minimal customisation required to make TinyMCE inject the appropriate control styles, which allow you to enter verbatim and noautolink sections, and protect "special text" such as Set statements. This work has not been done on Kupu.
4. Because of the level of customisation it requires, Kupu is a lot more work to maintain.
5. TinyMCE has a reasonably elegant plugin architecture, which makes it a better starting point for growth.

However,

1. Kupu has had a lot more 'Twikification' done on it - for example, to support upload from the editor. However a lot of this work is not used with the updated WyswiygPlugin, and must be removed before 4.2 release.

While Kupu will continue to work, it is definitely inferior. I think we should switch.

-- Contributors: CrawfordCurrie - 24 Aug 2007

Discussion

I support this fully, Kupu has a lot more going for it also imho - and it supports I18N-style links

As you mentioned in Rome, the current effect on textareas in TWikiForms is to show the editor also there / transform their content to HTML, but with this feature handled properly I don't currently see any problems in shifting the two asap.

-- SteffenPoulsen - 24 Aug 2007

Old Kupu based Wysiwyg had the reputation to be a topic killer.

"Edit and Pray"

Noone hardly ever use it anymore like we also heard Colas describe.

If TinyMCE is more safe then I am all for adding it to 4.2.0 instead of Kupu. We should not keep Kupu. We simply replace it.

And I would love if it works by simply being the Wysiwyg button leaving the Edit being good old geek edit.

I will work on the open doc items I have 4.2.0 this weekend. And then I think we are very close to releasing a beta. I would love to have TinyMCE in such a beta.

You could argue that this is breaking the feature freeze. But I see it this way

• It closes an awful lot of bugs in the Wysiwyg feature. I see this more as a major bugfix than a new feature.
• It adds the kick-ass factor that will make people upgrade to 4.2.0 and beta test it.

-- KennethLavrsen - 24 Aug 2007

+1

Besides, we didn't fork off the 4.2.0 RC branch yet, did we?

Just one consideration: how are we on browser compatibility? Kupu won't run on safari, but will run on opera, and tinymce the other way around? If that is the case, we should prefer safari over opera IMHO, a simple question of numbers.

-- KoenMartens - 24 Aug 2007

At the risk of causing confusion, please let me point out that the bulk of the bugs I have fixed have been in the WysiwygPlugin, which both editors use. Any usability improvements that have enabled TinyMCE have therefore also benefited Kupu. I gave the real pros and cons for the decision above.

My testing on Safari has been limited to getting Lynnwood to perform a cursory check, so I can't confirm one way or the other.

I am not, and never have been, in favour of using a separate edit button for the editor. I prefer other control methods - such as the TINYMCEPLUGIN_DISABLE preference - for controlling activation. If we can do it, then shift+click on the edit button to invoke the 'traditional' editor also works for me. This requires a debate. In support of Kenneth's viewpoint, see also AdditionalButtonForTinyMCE.

I have re-enabled TinyMCE as the default editor on develop.twiki.org - please use it to help make your decision!

-- CrawfordCurrie - 25 Aug 2007

TinyMCE is best for editing what is already there - it is not useful for i.e. cut&pasting TML from another topic. I think it should only replace the standard edit button once a consensus is reached that the editor is ready for it.

-- SteffenPoulsen - 25 Aug 2007

There are too many things where the plain text edit is still needed.

And users will not be able to learn shift-click. They can't even learn to not double click links in browsers. Shift-click is too geeky and too hidden. You need to see your options to know you can choose them. E.g. most people do not know you open a link in a new browser window with shift-click in IE.

The best way is to do what we have today - an edit button and a wysiwyg button. Then you choose what you want for the job you are about to do.

-- KennethLavrsen - 25 Aug 2007

TinyMCE is best for editing what is already there - it is not useful for i.e. cut&pasting TML from another topic - all I can say is "have you tried it"? If you have, what went wrong? Because it works for me. The only limitation I am aware of is pasting HTML, which has to be done in the HTML view.

There are too many things where the plain text edit is still needed - name them, please. Unless I know why you think it is still needed, I can't possibly address those requirements.

users will not be able to learn shift-click - bear in mind that only a small minority of users should ever need to use the TML editing mode that would be invoked by shift-click (or a similar accelerator), and these will be power users who are capable of retaining that nugget of knowledge. All the existing escape mechanisms, such as WYSIWYG_EXCLUDE, still work, so the fallback is automatic should you require it.

-- CrawfordCurrie - 26 Aug 2007

Cut&paste works better when pasting between TinyMCE sessions, but not when cut&pasting from a webpage with a description or from raw mode.

For instance try to copy&paste the raw content of this page.

• Numbered lists loses auto-numbering
• Headlines are lost (---+ visible)
• Italics are lost (_ visible)
• Raw view after save is distorted (one long line of text .. basically the cause of the other errors)

This is with Firefox 2/Windows, MAIN/r14623.

But you are right, the editor is mature enough to start reporting these as actual items - will start executing on this.

-- SteffenPoulsen - 26 Aug 2007

There are some additional usability issues with only have TinyMCE as editor.

In my view WYSIWYG_EXCLUDE is a symptom of something wrong. It is a bad feature which is there only because the Wyiswyg concept is still not working safely. And it is dead confusing to end up in a different editor. When I tried to edit topics in my Motion web only few pages could be edited Wysiwyg style. Most ended up in plain edit mode because in most topics there is at least one twiki variable that prevents editing. I had to add a "Set WYSIWYG_EXCLUDE = blank" to Main.TWikiPreferences to get any use of the editor. I can tell you that e.g. in our Quality System web not a single topic can be edited Wysiwyg unless WYSIWYG_EXCLUDE is blank.

When WYSIWYG_EXCLUDE kicks in and the user ends up in some mysterious geek mode. Well to us that is the old plain edit mode. But in a TWiki with no plain Edit mode this strange "random" (to the user) raw edit mode is a strange foreign mode that will be hard to explain - even in a live training session. When you have two edit modes that are visible at least people understand that the WYSIWYG_EXCLUDE triggered mode is a fall back to something they know.

However I will agree that the modern 2007 TWiki should have the TinyMCE as the default edit mode and that you should end in this mode when you hit Edit.

Maybe a good design is to have the Edit button at the top as the only Edit button (no Wysiwyg button) and Edit meaning the "human friendly" editor is TinyMCE - when the TinyMCEPlugin is enabled.

And then in the lower action bar The Edit link also means TinyMCE and we replace the Wysiwyg with a Link to the "plain text edit". We just need to find a good one word label for this then. Or two words if impossible.

This way

• The geeks have their plain edit easily at hand.
• The normal users are exposed to the plain text editor as a secondary user interface. It is not hidden to them. No secret shift function. The function is there when you need it.

The more brave geek-wannabes can learn and love the mode when playing with more advanced TWiki applications. There are plenty of examples where you need to know about the TML to create applications and need to understand it and test the TML you want generated by plugins and searches as plain simple TML first.

One powerful feature of TWiki is that a normal user can - without programming skills, and by self study - learn to create rather complex TWiki applications. The hiding of features is not the right way to get more users to create twiki applications. And to create twiki applications you quickly want to edit the raw content. The statement only a mall minority of users should ever need to use the TML editing mode is exactly what we do not want. We want at least 10-20 % of the users to be able to create or modify TWikiApplications. Never forget that this is one of the main strengths of TWiki. I am impressed how more and more users at work learn to create small applications with forms and everything. They read and experiment and copy things others have made and modify it. And this copying and modifying is difficult without seeing and editing the raw TML. I really do not want to hide any user interface from potential new TWiki Application builders.

It is a balance between not having to confusing a UI and having one that hides features. To summarize what I think is the right balance.

• EDIT at the top is WYSIWYG using TinyMCE
• No WYSIWYG button at top
• Edit link at bottom bar is WYSIWYG using TinyMCE
• No WYSIWYG at the bottom
• New "Edit Code" link at bottom opens plain old editor - name to be brainstormed

-- KennethLavrsen - 26 Aug 2007

Kenneth: the need to fall back to raw edit mode is less prevalent now that the wysiwyg automatically protects the TWiki variables (iirc).

FYI, i did some quick testing with kupu and tinymce on one of my macs. This is with osx 10.3.9, safari 1.3 (v312). Kupu shows the editor, but does not function. TinyMCE just crashes the browser. I'll see if i can find out why it crashes, if time permits!

FWIW, i agree that wysiwyg should be the default edit mode. TML is something that (like all wiki markup languages) was invented because editing HTML was not something anyone wanted to learn. Perhaps an idea will be to eliminate the TML -> html -> TML option entirely, as an option, so that you can store html content in your wiki instead of TML. Of course, there will be some issues there, for example automatic wikiword links.

-- KoenMartens - 26 Aug 2007

Thanks Koen. TinyMCE as we use it is literally out-of-the-box, so perhaps the Moxicode site may have some clues about Safari problems.

-- CrawfordCurrie - 26 Aug 2007

I also think that

• TinyMCE should replace kupu
• There should be one edit button, calling TMCE
• Geeks should be able to go into the textarea edit mode (or better, smartedit :-), with a shift operation, and/or a button labelled "edit code" or "edit source" (anything as long as there is a key accelerator - we are speaking of power users there). Going to "edit code" from TMCE maybe good also
• Of course, new page creation should also go to TMCE
• copy/paste from Open Office (with images) should be a goal (copy/paste from MS Office can be a goal of TWiki.net)

I was the culprit of asking Crawford for WYSIWYG_EXCLUDE. And I agree now that it is a usability disaster.

This does not preclude offering other WYSIWYG editors in the long term. But standardzing the whole community on a single effort is really what is needed now. And I think Firefox and IE are the important short term ones.

-- ColasNahaboo - 26 Aug 2007

Maybe "Edit Raw" and side by side with "View Raw". Then they both makes sense. People can relate them to each other. Adding this is OK since we remove the WYSIWYG link so we do not end up with more than we have today.

-- KennethLavrsen - 26 Aug 2007

That is an excellent idea. And the "Edit" link on the "View raw" screen could always link to it.

-- CrawfordCurrie - 27 Aug 2007

Hi! I will post a few comments as I followed closely the development of several WYSIWYG addons for TWiki. I installed Crawford's kupu support in the two twiki installation I maintain at the university of Nice and my students + collegues started to use it. After a few months everybody stopped using it. It worked ok for "standard" editing, a little buggy but nothing really severe. The problems occured as soon as people started to copy and paste content from various sources.

My guess was that the translation between TWikiML and XHTML was the problem.

For my research work I had to develop a "semantic wiki" from scratch, a wiki articulated around the technologies of the semantic web : Sweetwiki (can be tested at http://argentera.inria.fr/wiki). This wiki is a research project, not a complete/industrial quality wiki like TWiki. In the design step we decided to go 100% WYSIWYG and avoid all kind of markup langage. We do support the WikiWords, but no other tricks. The idea was to use XHTML as the formatting langage for tha pages + enhance this XHTML using the RDFa syntax for adding metadata withing the pages (RDFa is XHTL anyway). By using XHTML, a XHTML editor sounds natural.

I tried several editors two years ago : FckEditor, Kupu and TinyMCE. We discarded FCKEditor rapidly because we encountered many problems with the support on that time. Several things did not work and we could not get any answers from the web site or from the developers. TinyMCE was promising at that time but there was no support for a java backend (SweetWiki is written in java, just JSPs + servlet, no strange heavyweughted framework is used). Kupu developers were nice and there was an irc channel, a mailing list, etc... + we had some experience with kupu and twiki (my students did the very first kupu addons for TWiki and I was their supervisor).

Some features we wanted were :

• Support for copy and paste from various sources, including microsoft products like word, excel, powerpoint, in fact copy and paste should not break the system ! Maybe we will loose some formatting but the system had to be robust.
• Support for importing office documents and turn them into topics/pages, including pictures.
• Support for multimedia content like videos (youtube-like),
• Use ajax features for improving usability, in particular for making hyperlinks, uploading pictures/attached documents/tags the pages or parts of the page (pictures, etc...) directly from the editor.
• Extensibility, supporting new features, new content should be possible.

So what is the return on experience ?

First, all the WYSIWYG editors I tested, including TinyMCE, broke somewhere when we decided to test copy and paste on multi browsers/multi OS. Kupu is just not supported by Opera/Safari for example. The behavior of 99% of editors is based on the APIs of the browsers themselves. For example, putting a text in bold will generate some STRONG XHTML statements on IE, b tags or span style=bold tags on others browsers. Some events like copy/paste will behave differently depending on the OS/browser couple as well.

All in all, it was a kind of nightmare.

Support for copy and paste: we have several layers of XHTML filtering. First pass is in Kupu. It comes with several tools for filtering tags ans characters (we do many more things than the twiki kupu port here). Second pass is through XSL stylesheets. We have about 20 rules there that try to avoid the most common cases that could break the formating (empty bold tags, etc...). Last pass is Tidy. For months we had to adjust these filters and frankly it was not fun.

Support for Office documents: we do have an Open Office Server that receives the uploaded documents. It translates them into XHTML documents, we use Tidy for filtering there too, then the converted documents appears in the WYSIWYG editor, and the content is once agaon filtered during the save.

Another nightmare was the support for all the characters encoding, but this is common story... We tried to copy and paste pages from all over the word in all kind of encoding. Strangely we had to make some special cases for Mac Users, the UTF-8 enconding generated from some Mac documents was not supported by all our libs...

And of course, Kupu has its own bugs too... Fo rexample it requires some restrictions in the CSS the document uses during the edition. The table editing is bad. Just bad. Etc...

So... now we do plan to abandon kupu. The kupu developers seem more interested by "Kupu in Plone" than by "Kupu in other apps", and it does not work well in multi browser/multi os configuration. We made some tries with the dojo editor that is (as far as I know) the only editor that comes with its own DOM API (it does not rely on the API from the browsers, for editing the dom). We wrote ultra-rapidly a small wiki based on the dojo editor from the current dev release of dojo and : 1) we managed to implements features that our users have been asking for a long time like : save without quitting, auto-save, better table editing and 2) most of the test cases that broke the common editors passed easily.

In SweetWiki we also support the integration of videos directly from the editor. We designed a system were a multimedia component has an "editor view" and a "rendering view". Using some xsl processing this is done easily and 100% in XHTML. I can detail how we do this...

I hope this helps... I would not build a wiki on a WYSIWYG editor that relies on the DOM of the browsers. DOJO way is the good one.

There should be also a discussion about user's behaviour. Most of the my users will never write TWiki Applications, on the twiki sites I maintain since 1999. Most of them just edit text and tables and never use WikiWords. They don't know how to restore a previous version of a page, they ask the gurus for such a simple operation, etc... For them, a WYSIWYG editor is certainly appealing.

-- MichelBuffa - 27 Aug 2007

Bugs:Item4507 is a pretty good example of what Michael is telling.

I raised it this morning and all I did was to copy some heading text from the browser window and pasted it in. For sure people will do this all the time. I think this will be a big challenge to fix but some degree of fix is needed if we want to ship 4.2.0 with TMCE.

-- KennethLavrsen - 27 Aug 2007

I'd really like to see native WYSIWYG as the default, this is a major roadblock for any non-technical users. Also agree that copy/paste is a major issue - even if we provided official converters for Microsoft Office, many people would simply copy/paste.

Michel - on your problem with pasting UTF-8 from Mac documents, the Mac uses Unicode Normalisation Form D (NFD), which may be what is causing this. See MacOSXFilesystemEncodingWithI18N and UnicodeNormalisation for more on this. Generally the browser will convert from the source character encoding (of copy/paste buffer in the OS) into the page's character encoding (e.g. ISO-8859-1). This is another good argument for implementing full UnicodeSupport - if the TWiki page is using UTF-8, it is possible to convert from virtually any source character encoding into UTF-8, without loss of data (i.e. characters being converted into ↤ style XML numeric character entities).

-- RichardDonkin - 27 Aug 2007

This was accepted at FreetownReleaseMeeting2007x08x27

Main reason is that it resolves a huge amount of bugs related to Kupu (including many not even opened as bug items) and it is a step in the direction of our number 1 TWikiRoadMap priority.

-- KennethLavrsen - 28 Aug 2007

I suggested this in the TinyMCEPluginDev topic, but thought it was worth saying here too - how about combining the functionality of TinyMCE and NatEdit - so that TinyMCE is the default editing mode, but when it has to fall-back to raw edit mode, the NatEdit plugin kicks in - that way you get the best of both worlds - WYSIWYG by default, and NatEdit otherwise.

I should also mention that TinyMCE works OK for me on my Mac using both Safari 3 beta and the WebKit nightly builds - I've not done exhaustive testing, but it seems OK in standard usage. I've tested this on TWiki 4.1.2, using the latest version of the WYSIWYG plugin as per Crawford's instructions.

-- JasonWickham - 28 Aug 2007

Falling back to NatEditContrib would indeed seem to give us the best of both worlds. MichaelDaum, any comments?

-- CrawfordCurrie - 28 Aug 2007

Thanks a lot Richard for the info about the Mac. I'll check this closely...

-- MichelBuffa - 28 Aug 2007

Konqueror currently does not implement the midas specs and thus is not able to do any wysiwyging. This will only change after KDE-4.0 has been released, according to the bug item for konqueror. KDE-4.0 will be release Q4 this year.

Wrt, NatEditContrib being a fallback for WysiwygPlugin: I will take a look at it to see how to do it in a clean way, such that it fits into the other improvements that I was planning for NatEdit.

I want to make the edit screen a tabbed interface where the tabs are the textarea, the form, the topic preferences, the attachments and a help tab. So wysiwyging / nateditting will only happen on tab one, while all the other stuff aggregates features that are loose ends right now. And I don't know how TinyMCE's plugins come into play here, e.g. for attachment integration. Anyway, not scope of this FeatureRequest.

-- MichaelDaum - 28 Aug 2007

I am currently the only one really raising bugs against TMCE.

I test for approx 30 seconds and then I find a show stopper bug.

Then I spend 10 minutes isolating the problem and reproducing it.

Then I spend 10 minutes fighting with TMCE which I cannot turn f**king off on bugs web, trying to get some verbatim error descriptions pasted in.

I currently give TMCE 20% that it will be in 4.2.0. And after having read the open bug reports at http://drupal.org/project/issues/tinymce?states=1%2C16%2C8%2C13%2C14%2C15%2C2%2C4&categories=bug then I am beginning to doubt that it is the right decision to make TMCE the default edit button.

Significant improvements will have to happen.

And all you other guys reading this. Please test thins new thing. Do not just play with it for 5 minutes and get excited about headings and bullets.

Play with it in Internet Explorer. Forget Firefox for now. Copy paste some text from MS Word, other IE pages, Outlook, other programs into some of your existing test topics.

Try and add verbatim text blocks.

Try and move text around. Try to bullet and unbullet. Try and add new bullets in the middle of existing bullets. Try and paste text into bullets.

Nothing fancy. Just things a typical user will do on a normal day.

And you will find trouble. Lots of trouble. And please raise them as bug reports. One more thing. Put a " * Set WYSIWYG_EXCLUDE = " (yes blank) into Main.TWikiPreferences so you can test it on topics with TWiki variables that take parameters.

Edit topics with twiki variables like searches that spans several lines.

And remember to save and look at the result. And try and edit again and save. Often it is the 2nd save that causes problems.

View the topic raw afterwards to see what changed.

Please report the bugs so we can address them.

We all need to have used the editor seriously to make a qualified community decision if it is in the final 4.2.0. We will put it in the first beta but it will need significant improvements if it is to be the default editor in 4.2.0.

-- KennethLavrsen - 28 Aug 2007

I don't see anything to panic over in the Drupal bugs list. Most of those reports are easily survivable, which I suspect is why they are left open (same scenario as for TWiki).

Having said that, Kenneth is almost right; he is not the only tester, I also test continuously but my bugs are usually closed as soon as they are opened. Please, please, please test!

Kenneth, please don't panic. When you make statements like

• I currently give TMCE 20% that it will be in 4.2.0
• And you will find trouble. Lots of trouble

the above, you demotivate me, and scare people away from contributing. I have added a "nowysiwyg" option to the URL so you can disable TinyMCE for entering bug reports. Just edit/Codev/ReplaceKupuWithTinyMCE?nowysiwyg=1

-- CrawfordCurrie - 29 Aug 2007

Crawford, Michel made an interesting point about going to Dojo rather than an editor based on the Browser's own DOM API. What are your feelings on this? Should not we directly jump to Dojo rather than stay on a Browser DOM based editor? (I understand Dojo requires using the huge jotspot framework however)

Kenneth: the fact that Drupal uses TMCE should be in favor of it: if an editor is used by such active communities as Drupal & Wordpress, it means it will have a lot of testers and bug reports, which is the road to progress.

PS: we installed Wordpress-Mu internally to be used by non-technical people, and we had no complaints on its wysiwyg editor, which is TMCE. This means our users have learned to go around TMCE bugs

-- ColasNahaboo - 29 Aug 2007

Dojo is a possibility, but at this stage it would require a lot of research and experimentation to go that way. I'm not ready to do that at this point, though don't let me discourage anyone else!

The problems Kenneth is seeing with paste are down to the HTML to TML conversion not being tuned to deal with pasted HTML. It's really, really hard to do that well.

-- CrawfordCurrie - 29 Aug 2007

I refactored discussion on dropping TML out to DropTML

-- CrawfordCurrie - 29 Aug 2007

I fully support this request, especially if the new editor integration does less damage to topic content. A solid WYSIWYG editor is a must have for the TWiki project; we can't easy the perception that TWiki is a geek tool without one.

-- PeterThoeny - 31 Aug 2007

I will put online the demo we wrote with the Dojo editor. It's a one week work but very promising. We do use TinyMCE on several projects in my research group and it will break where every WYSIWYG javascript editor base don the DOM of the browser will break. The W3C has a working group about normalizing the API for the DOM edition in browsers but it just started.

Crawford, the small ugly proto we wrote with the dojo editor is very small (we named it "smallwiki"). Colas tried it some weeks ago, but it is no more online, I asked the administrator of our server to put it back. It should be ok the next week.

If you just try Kenneth's tests on this editor, most of the time it will not break.

But in all our software, we don't do any TML/XHTML translation. Never, it was a design decision not to support any markup langage and go 100% WYSIWYG. But we do support macros, complex queries, etc... in the text. The only thing is that we edit them directly from the WYSIWYG.

How do we do this ? We have a model where macros/variables/components (video flash player for ex) have different "views". For example, we do support SPARQL queries in the pages. It acts like the twiki SEARCH (but uses the sparql langage instead, with a completely different syntax). In the editor we have a menu for entering requests (you can even try them before inserting them), a request will the appear as text in the topic, surronded by a colored table (in fact it's a span that contains the request, and the css matches that so in the editor we can have a particular view, easy to identify). Then we the topic is saved, we translate this into a particular xhtml tag. When the page is rendered, this tag is in turn translated into a set of xhtml code (link to the search engine) and the result set is in turn inserted at rendering time into the xhtml stream. Why do we use xhtml tags instead of embedding code in the middle of the topic ? Like that we have pure XHTML, we can easily go back and forth from the wysiwyg view / persitant text file without loss, etc... Same for the flash videos : we do have a tv icon in the wysiwyg editor where there will be a video rendered. Etc...

SO for each "component/variable/macro" we have a span type= tag that is translated with an xsl file before editing the topic (it will the be visible as picture, icons, colored table, etc.), we have a css that matches that and sometimes we have some hooks in the editor to display some contextual things (if you select a picture, it will show the corresponing tags if the picture is tagged etc...)

We went quite far with kupu, but the browser DOM problem is very ennoying (undo breaks, etc.) + the browser has a lot of problems locating the cursor when you have non visible html code. For example, you type some text in bold. Then click at the end of this text and keep typing. Will it be bold or plain text ? The behavior will differ from browser to browser, from OS to OS. At least with the dojo editor, it will behave the same.

It is possible to cut down the size of the dojo framework classes you need to import in order to use the editor. We will investigate more on that. So far we have a minimal editor in a small php wiki that is just a few hundreds of code lines. Crawford, I'll give you the source so that you have an example. But we used the dev version of dojo (night builds) so there is no guarantee it will run with the current dev version.

BTW : even with the bugs, etc... I have a small company that runs Sweetwiki, a prototype 100% based on kupu we wrote, The have been running it for months now, without big problem. They just "learned how to avoid the bugs"... Like "always put some blank lines or some text beween pictures, always press the "filter special chars if you copied and pasted from a mac, etc..."

-- MichelBuffa - 31 Aug 2007

Crawford. I am sorry if my remark had a demotivating effect. That was not the intention. On the contrary.

What I should have written is more clearly is "I currently give TMCE 20% that it will be in 4.2.0 unless more people help testing and contributing"

And I am still in doubt if replacing the Edit button function to default to TMCE is the right one. If TMCE give people too much problems then I will prefer that we use the WYSIWYG button for it and keep the classic Edit.

But let us give it a chance and see if we can get it to an acceptable functional level. But for that more people than I (and naturally Crawford) needs to test it and report bugs. And that was my main message. Come and help testing - otherwise we will not get this ready for 4.2.0.

-- KennethLavrsen - 01 Sep 2007