Item4894: No support for documented TML format: [[http://host/blah this style of link]]

Kupu is enabled on TWiki.org and pages are getting corrupted - see http://twiki.org/cgi-bin/rdiff/Codev/ProposedUTF8SupportForI18N?rev1=45;rev2=44 this revision for example. It's happened on other pages too such as TWiki:TWiki.WindowsInstallCookbook (see comment at end).

I think the problem is the 'easier external links' format, i.e. [[http://someurl.example.com text describing link]], which is corrupted by WYSIWYG - since this is a supported feature (and I use it a lot so it's in quite a lot of TWiki.org topics) please can we get it fixed?

Also, perhaps Kupu should be disabled on TWiki.org until it stops corrupting common pages.

-- TWiki:Main/RichardDonkin - 27 Oct 2007

This is a problem with TWiki.org, not with the twiki code nor the plugins.

CC

OK - so what's the solution? Disable WYSIWYG on TWiki.org, or fix Kupu, or ...? Is it just misconfiguration of Kupu that's corrupting pages?

We need to stop TWiki.org pages getting corrupted....

-- TWiki:Main.RichardDonkin - 28 Oct 2007

Remove KupuContrib, upgrade WyswiygPlugin, install TinyMCEPlugin, would be my recommendation.

-- TWiki:Main.CrawfordCurrie - 28 Oct 2007

TWiki.org is running the latest production release of TWiki, e.g. 4.1.2. Saying that this is a problem of twiki.org implies that this is a problem of the 4.1.2 release. Indeed, it is!

Richard's point is correct, the [[http://someurl.example.com text describing link]] is a supported format, and the WYSIWYG editor should support it.

Crawford is probably not going to fix the Kupu integration. How does the TinyMCE plugin handle those links?

-- TWiki:Main.PeterThoeny - 28 Oct 2007

small note: TWiki.org is runing 4.1.1 ( http://twiki.org/cgi-bin/view/TWiki/WebHome ) due to the split TWikiUsers thing - Which I've fixed, though we could do with re-testing it..

-- TWiki:Main.SvenDowideit - 29 Oct 2007

This should be an easy fix to Kupu (at least I hope it is) - just add one regex. TMCE looks better than Kupu but I'm not sure if the server side plugins work with 4.1.1.

-- TWiki:Main.RichardDonkin - 01 Nov 2007

On re-reading I realised that the issue that Richard mentions is an issue with WysiwygPlugin, not with Kupu, and I do not plan to fix it. "Just" add one regex..... it's not quite that simple.

If you don't expand TWiki variables, there are two possible interpretations of the same text in square brackets. For example, [[%LINKVAR% link to web topic]] can be resolved two ways; as a link to ]%LINKVAR%LinkToWebTopic]], or you can assume that %LINKVAR% expands to a protocoled link, and thus the link is [[%LINKVAR%][link to web topic]]. Since the TML2HTML converter cannot expand TWiki variables, it's impossible to tell which is intended.

Because of this, and because the [[protocol:// text]] link form is apparently deprecated (it is not mentioned in documentation anywhere that I can find) I chose to consistently apply the first interpretation to all square-bracket links that have spaces in. The fact that WYSIWYG has been "out there" for so long without anyone else spotting this problem suggests that this approach was correct.

I could jump through hoops hack in a "special case" to handle a literal protocoled string in the first position, but the experience we had with older WYSIWYG work and "special cases" suggests that this will almost certainly lead to other problems. Supporting undocumented, minority, legacy syntax just ends up confusing people who stumble on it by accident - especially when TWiki variables are involved. If anything, I'd rather remove support for the deprecated syntax from the core rendering engine.

I am re-directing this to WysiwygPlugin, and changing the headline from "Kupu is enabled on TWiki.org and pages are getting corrupted". Anyone who feels strongly about it, please make your points.

CC

The old legacy format with a twiki variable being the link is a pretty unsual case and IMHO can be ignored. It makes no sense to try and support that.

Left is to regex the first word to match protocol:// and in practical matching http, and ftp is probably fine.

I would see no issue if a round trip open and save in PMCE would convert the [[protocol://link text string]] to [[protocol://link][text string]] and that the conversion happens when you hit edit to the TMCE itself only sees that is knows.

Thinking TWiki 5.0 and long term strategy.

At WikiSym we saw some Germans that had developed a pretty powerful Wysiwyg which was NOT saving HTML. It was not yet open source but they have to release the sources soon when they start distributing it because it was based on TMCE.

This editor was based on WikiCreole.

I am not the one to jump up and down because TWiki would get same markup as other wikis. But I see a huge synergy in several wiki development communitites working together on Wysiwyg editing. And WikiCreole is as a markup very very close to TWiki. And with the Creole editor also being based on TMCE there is hope that integration with TWiki is not too difficult.

The WikiCreole link format is [[link | link text]].

So keeping this in mind, it may be worth the investment of a few more code lines in WywiwygPlugin to support multiple square bracket link styles and at the same time not make too bad a hack to support the old legacy TWiki style.

If we accept that an edit/save round trip converts from other style to TML then it may not be too bad to implement. And if Richard has used the old style then probably many others have as well.

Unless someone else screams urgent I think however this can be lowered to Normal.

-- TWiki:Main.KennethLavrsen - 01 Nov 2007

I think corrupting pages on TWiki.org that are using a documented TML syntax is quite important and should be fixed soon.

This TWiki:Codev.EasierExternalLinking was added quite a while ago (by me) and is documented in text formatting rules, even if not in most obvious place but still under "external links" heading so not too hard to find. It should supported by WysiwygPlugin to avoid pages getting corrupted, in both TWiki.org and user installations.

We could support this directly (preferable, as otherwise we have to deprecate a documented part of TML) or by converting to another link format, possibly WikiCreole.

The variable name issue is a red herring, and I believe the fix is simple and unambiguous - the format only works with [[http:// foo bar]] type links, i.e. not with a variable as the first item. This was intended for interactive users anyway, as an alternative to the main format.

-- TWiki:Main.RichardDonkin - 02 Nov 2007

OK, now you point it out, I see the (rather terse) documentation. I had missed it completely, despite having read that topic at least 1000 times

However, we're all being stupid, especially me; it works fine, and has done for many revs of WysiwygPlugin. http://stupid.org demonstrate this. The action is to update TWiki.org with the latest WysiwygPlugin.

BTW Kenneth, don't get carried away about a TMCE that "uses" WikiCreole. It doesn't. All it does is to move the WikiCreole to HTML to WikiCreole translations into the Javascript, instead of having it server side (as we do with TML to HTML to TML). The mapping still has all the same problems we face (such as formatting removal). I have considered doing the mapping in JS several times, and even have code to do some it, but have stuck with server-side simply for performance reasons.

CC

I don't know the status of WysiwygPlugin on TWiki.org. So this is a ping to those maintainers, to make sure it is using the latest release.

-- CrawfordCurrie - 06 May 2008

No-one gave a shit back then, and for sure no-one gives a shit now. Closed.

-- CrawfordCurrie - 05 Nov 2008 - 17:42