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 preRenderingHandlerandinsidePREhandler (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:

Is there any harm in having <pre> <sticky> sticky inside pre </sticky> </pre> sent to the browser?

What is the problem with startRenderingHandler, and can we not un-depreprecate is?

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.

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.

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

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?