Item1905: Deprecated handlers in WysiwygPlugin

The WysiwygPlugin uses two deprecated handlers: startRenderingHandler and endRenderingHandler

These handlers have been deprecated for every version of Foswiki, so the WysiwygPlugin should be updated to use other handlers instead.

-- MichaelTempest - 08 Aug 2009

We could also un-deprecate the two handlers.

The person that deprecated them is also the person that has not been able to eliminate them for something like 3 or 4 years.

It does look rather silly to show deprecated handler warnings for plugins we ship with Foswiki

-- KennethLavrsen - 20 Sep 2009

I implemented a change to address this bug a long time ago, but I had not been sure that there were no subtle side effects. I've given this bug some back-brain time, and now I am sure of where we are.

endRenderingHandler was deprecated a long time ago. It was not used in (tm)wiki 4.2, and it has been erroneously in use on Foswiki because of something missed during rebranding. I am sure we can remove this one with confidence.

startRenderingHandler is not the same as preRenderingHandler.

startRenderingHandler converts

<pre> <sticky> sticky inside pre </sticky> </pre>

to

<pre>  sticky inside pre  </pre>

but preRenderingHandler does not.

We can get exactly the same effect as startRenderingHandler by replacing it with preRenderingHandler and insidePREhandler (so that each does the same as the existing startRenderingHandler). Bzzzt - the insidePREhandler is also deprecated but, unlike other deprecated handlers, it is not marked as such in Foswiki::Render.pm.

I do not think a commonTagsHandler would do the job, because the result would depend on the {PluginsOrder}.

So:

1. Is there any harm in having <pre> <sticky> sticky inside pre </sticky> </pre> sent to the browser?
2. What is the problem with startRenderingHandler, and can we not un-depreprecate is?

-- MichaelTempest - 25 Sep 2009

IIRC the problem with startRenderingHandler was that it does a fairly random amount of pre-rendering before it passes the topic to the handler, as you have seen. That means the handler is working with something that looks like, but is not, the source of the topic. It also requires the meta-data to be textually embedded in the topic, which is shit. I would rather finish eliminating it.

If you pass sticky tags to the browser, it may (1) barf or (2) strip them.

-- CrawfordCurrie - 07 Oct 2009

I can only say that it does not look very professionel to deprecate something, flag it in red in our user interface for the admin, and having done with with a default core key plugin for years now. Either we fix for 1.1 or we un-deprecate.

I am quite OK with having none-core plugins being flagged. But the plugins we distribute must present themselves as clean.

-- KennethLavrsen - 07 Oct 2009

If you have <sticky> content </sticky> in a topic, and WysiwygPlugin is not enabled, then the sticky tags are passed to the browser. In this case, only the core can remove them.

The sticky tag is part of the standard markup. It is documented in EditingShorthand and used in several topics distributed with Foswiki. I think the core should handle these tags during rendering.

So then - let the core remove sticky tags during rendering, and the WysiwygPlugin won't need a startRenderingHandler any more.

-- MichaelTempest - 07 Oct 2009

Even if we remove the sticky tag, to maintain compatibility with old versions of Foswiki we still need to keep the startRenderingHandler (as I recall, that's why I kept it in the first place - compatibility).

-- CrawfordCurrie - 08 Oct 2009

Compatibility... can do that If we change the trunk core to remove sticky tags, and WysiwygPlugin does $FoswikiCompatibility{startRenderingHandler} = 2.1; then WysiwygPlugin will not use deprecated handlers from 1.1 onwards (i.e. no red messages on InstalledPlugins), but will still run on older versions of Foswiki.

There is still that if - is it okay for the core to remove the sticky tag?

• Update: Crawford indicated that this is okay: http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2009-10-08,Thu&sel=41#l37

-- MichaelTempest - 08 Oct 2009