More Plugin Hooks

Existing Plugin Hooks in latest Alpha

Desired Plugin Hooks (once complete listed on PluginHandlers)

 $tmpl =~ s/%TEXT%/$text/go; 

Plugin Hooks Rejected

Further Discussion of Proposals

Proposals 1 - 4

I'd like hooks for more Plugins, namely alternate handlers for internalLink, specificLink, externalLink, and mailtoLink. Anyone think this is a bad idea? I would model the code after writeHeader / writeHeaderHandler, which calls the plugin first, and if the plugin returns false, the usual TWiki code is executed.

-- GregLindahl - 10 Dec 2001

I concur. This is exactly what I need to remove the Hack in TWiki.pm for SpacedOutWikiWordsPlugin

-- MartinCleaver - 28 Aug 2002

I'd like to vote for this one as well. Controlling the presentation of internal links to gain a more corporate-acceptable look is a crucial step for TWiki to gain momentum in the intranet sector. SpacedOutWikiWordsPlugin is a good start, but the TWiki.pm hack required makes it difficult to maintain an installation across versions of TWiki and/or plugin.

-- StefanLindmark - 05 Jun 2003

I'd like to refine this suggestion a little: Presentation of links, or any other elements, should not be controlled by any .pm file or a plugin. Rather presentation should be controlled by CSS, and the code - be it core or a plugin - should enable that control. So, for example, an internal wiki-link should have be <a href class="wikilink"> while an external link would be <a href class="extlink"> and so on.

-- MattWilkie - 05 Jun 2003

Proposals 5

Let me take this another step further. I'm not too concerned about having a billion hooks into the system, but I DO need access to the post-rendered topic, before it's mashed into the template. Somehow, it would be nice to have a plugin be able to see/change the topic text.

One idea I can think of is making a call to the Plugin after the topic is loaded, maybefore it's transferred to the template (like just before

 $tmpl =~ s/%TEXT%/$text/go; 

Just my $0.02.

-- DavidWeller - 16 Dec 2001

David - how does this vary from the "endRenderingHandler" ?

-- TWikiGuest - 03 Feb 2002

I'll answer this one:

• several endRenderingHandler plugins modify the rendered text in various ways, my RecursiveRenderPlugin included.
• <verbatim> text is still missing during endRenderingHandler calls.
• <nop>'s are still around.
• getRenderedVersion is in many cases called several times during topic rendering, and every endRenderingHandler is called for each invocation. Not to mention that any plugin that desires to do so may invoke it yet more times via TWiki::Func::renderText.

I think the idea of this request is that the plugin desires access to the final, completely rendered topic just before it gets stuffed into the template. Now, what the plugin would do with such access, and how it would avoid messing up <verbatim> text, I don't know.

-- WalterMundt - 22 Jan 2003

-- TWikiGuest - 03 Feb 2002

I think we also need a couple of hooks to allow alternate authentication methods. If you look at the SiteMinderPlugin you'll see a couple of hacked work arounds. These could be avoided with some proper hooks. (I apologise for the vaugness - I didn't write the plugin so I lack the detail of what is needed).

-- MartinCleaver - 06 Feb 2002

Why isn't this topic in FeatureBrainstorming? I don't mean to kill off this topic, but this is more of a feature then a "how do I do development on the current TWiki codebase".

-- DavidLeBlanc - 24 Mar 2002

One way to defer plugin loading is to require that all plugin syntax be of the form %PluginName:Function%. This has a nice resonance with some possible future xmlized version of TWiki

-- DavidLeBlanc - 27 Mar 2002

Correct, this is not a TWikiDevQuestion, I set it to FeatureToDo. We still need to refine and prioritize the new hooks.

-- PeterThoeny - 27 Mar 2002

Other proposals

I'd like to propose a change to writeHeaderHandler, to address the need for some HTTP headers to be controlled by the core in some cases to address bugs such as BackFromPreviewLosesText (current fix breaks this handler for the Edit page):

See Accepted section, above

This is important so that a plugin doesn't break this bug fix in the core code, causing data loss for InternetExplorer users.

-- RichardDonkin - 28 Mar 2002

Since there weren't any comments on the change to writeHeaderHandler, and a change was needed to have the fix for BackFromPreviewLosesText work with SessionPlugin etc, I've now implemented this in the TWikiAlphaRelease, and moved the hook details to the 'Accepted' table above. Silence = assent

-- RichardDonkin - 20 Apr 2002

+++ Proposal 10

I propose the addition of the beforeEditHandler handler, to pre-process topic text before placing the text in the edit box. Paired with the (yet unimplemented) afterEditHandler allows us to pre/post-process the edit text as it's done in TranslateTagPlugin.

-- AndreaSterbini - 13 Jun 2002

+++ Action hook

I propose that the action and enquireAction hooks be implemented, so that scheme recommended in CommonFrontEndCgiScript can eliminate the PluginBinNameClashes problem. In the interests of expediency, I also propose that this proposal be deferred to Cairo release.

-- MartinCleaver - 08 Jul 2002

1. Moved my first request to be support for Greg's proposal number 1.
2. As Peter wants to get this feature in as part of BeijingRelease, I think we need to set a deadline for proposal requests and their supporting arguments and a schedule to get the code written and in a beta. If you have some ideas that you are sitting on, please share them now. I propose that we close this topic in a week, on Sept 7, 2002. Then again, I always did believe in setting deadlines.
3. I will work out whether Sven's request covers what I need for the SiteMinderPlugin, I suspect it does.

-- MartinCleaver - 28 Aug 2002

I do have a working version of renderFormFieldForEditHandler, but assume it's best left to the CairoRelease.

Has InitializeUserHandler changed? Has always worked okay for me in SessionPlugin.

-- JohnTalintyre - 31 Dec 2002

Yes, better to defer RenderFormFieldForEditHandler to the CairoRelease.

InitializeUserHandler has not changed by functionality, the only difference is that it goes through the normal function discovery process like the other functions instead of a hardcoded discovery. Just to make sure there are no "gotchas", could you test the latest TWikiAlphaRelease or TWikiBetaRelease?

-- PeterThoeny - 31 Dec 2002

As a workaround for InitializeUserHandlerBroken, I reverted the code for InitializeUserHandler back to the old spec. This is for the BeijingRelease. John, could you test this out?

A clean solution needs to be worked out in the CairoRelease.

-- PeterThoeny - 21 Jan 2003

I just wrote ImmediateNotifyPlugin, which needs an AfterSaveHandler, as described above...it will do immediate notification of successful topic saves via the Jabber instant messaging protocol. Along with the plugin on the plugin topic is a patch against BeijingRelease that adds this handler.

-- WalterMundt - 03 Feb 2003

I think with the AfterSaveHandler we need some type of notification if a topic is renamed. My reasoning is that one of my intended usages for the AfterSaveHandler is to cache information in a local db. Unfortunately if someone renames a topic things get out of whack.

Either if a renameHandler is created or if a rename is the equivalent of a deleteHandler & a saveHandler on a new topic then I would be set.

-- JohnCavanaugh - 21 Mar 2003

Re: MartinCleaver's request for a mailTo hook. We've already got everything we need, except an exposed TWiki::Net::sendMail API. Suggest we either (bad) add this to TWiki::Func or (good) publish a cleaned up TWiki::Net interface object for use by plugin authors.

Another request; meta-data isn't passed to the hooks. I've had to re-read the topic from scratch to extract meta-data in the beforeEditHandler. Please can we have meta-data passed to the hooks, even if it's read-only.

-- CrawfordCurrie - 23 May 2003

WRT the mailTo hook: what I was thinking is that when mailnotify calls it could check with all the plugins as to whether they have a batch mailing to do. Even more generically, we could have a batch-wakeup callback that asks each plugin whether they have any work to do, and if not right now, at what time they want waking up.

• Accordingly I've renamed it to NotificationHandler

-- MartinCleaver - 27 May 2003

My recent work on the core has made me realise we have to be very, very, very careful about adding more plugin handlers. The existing plugin handlers are already like nails through the heart of TWiki. The need to maintain plugin handler call points makes radical performance improvement in the core nigh-on impossible, because by their very nature, the plugin handlers assume a particular implementation. Every plugin handler added is another nail. So think very carefully about what you are asking for before adding any more of these blasted handlers.

-- CrawfordCurrie - 05 Nov 2004

Whilst I agree this is the case for the main view RenderPipeline, I hope you don't mean to discourage the creation of handlers elsewhere. For example, I believe we need an AfterLoginHandler so that the TodaysVisitorsPlugin doesn't need to grep and unique every entry in this months log just to work out who logged in today.

-- MartinCleaver - 05 Nov 2004

I've put this as Merged against BeijingRelease because that's what it says on that topic. Is that correct? I wasn't able to tell from skimming the above what actually shiped.

I note also that it is including topics above. Because PluginHandlers is a DefineTerm topic and not against a release it may get out of sync with what it was originally intended to docuemnt.

-- SamHasler - 15 Feb 2005

Is there a handler that is called when a new web is created? If not, could there be one and is there a hack I could use in the mean time?

-- AndrewRJones - 23 Nov 2006

No. Yes. No.

-- CrawfordCurrie - 24 Nov 2006