Tags:
create new tag
, view all tags

More Plugin Hooks

Existing Plugin Hooks in latest Alpha

$VERSION Hook parameters Description
1.000 InitPlugin $topic, $web, $user, $installWeb Called once at startup as the plugin system is initialised
1.010 RegistrationHandler $webName, $wikiName, $loginName Called from register script. Can be used for sending cookies, (UserCookiePlugin) or any other SessionPlugin processing
1.000 CommonTagsHandler $text, $topic, $web Called once per line of the text
1.000 StartRenderingHandler $text, $topic, $web, $meta Called just prior to the mainloop
1.000 OutsidePREHandler $text, $web Called once per line, before any changes - as long as outside PRE & verbatim
1.000 InsidePREHandler $text, $web Called after closing any lists when in a PRE or VERBATIM area, before any other changes
1.000 EndRenderingHandler $text, $topic, $web Called after almost all modifications to a topic - ie this is the result of getRenderedVersion. <nop> tags are removed after this
1.010 BeforeEditHandler $text, $topic, $web Called when the text is edited to allow pre-processing of edited text. See TranslateTagPlugin
1.010 AfterEditHandler $text, $topic, $web Called when the text is previewed (or checkpoint-saved) to allow post-processing of edited text
1.010 BeforeSaveHandler $text, $topic, $web BeforeSaveHandler
1.010 WriteHeaderHandler $query Called just prior to writing header. Returns a single result: a string containing HTTP headers, delimited by CR/LF and with no blank lines. If returns FALSE, the default header gets written. Plugin generated headers may be modified by core code before they are output, to fix bugs or manage caching. Plugins should no longer write headers to standard output.
1.010 RedirectCgiQueryHandler $query, $url Generic Hook into the redirect functionality.
1.010 GetSessionValueHandler $key Called to get a session value... Used perhaps in a plugin..?
1.010 SetSessionValueHandler $key, $value Called to set a session value... Used perhaps in a plugin..?
1.023 BeforeAttachmentSaveHandler \%attachAttributes, $topic, $web Called before an attachment is saved
1.023 AfterAttachmentSaveHandler \%attachAttributes, $topic, $web Called after an attachment is saved
????? BeforeCommonTagsHandler $text, $topic, $web Callback at the very beginning of the common tags handler; needed for Plugin that caches variables

Desired Plugin Hooks (once complete listed on PluginHandlers)

Proposal No. Hook requestor Parameters Description
1 InternalLinkHandler GregLindahl, MartinCleaver ??? RenderedWikiWordHandler
2 SpecificLinkHandler GregLindahl ??? ???
3 ExternalLinkHandler GregLindahl ??? ???
4 MailtoLinkHandler GregLindahl ??? ???
5 PostRenderedHandler DavidWeller ??? 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; 
in Form::changeForm() )
6 PreIncludeHandler TWikiGuest $topic, $web, $includeTopic, $includeWeb This hook would be called just as we're about to include a document into the current text. At this point, we know the include Topic's name & web. The idea of this hook was to allow plugins to follow the traversal through the file tree - ie to come up with realistic last-modified dates. Example usage is here: LastModifiedFieldOfHttpHeader
7 InitializeUserHandler   $loginName, $url, $pathInfo Allows a plugin to set the username (used by SessionPlugin & UserCookiePlugin)
9 RenderFormFieldForEditHandler JohnTalintyre $name, $type, $size, $value, $attributes, $output Allows a plugin to produce an edit control for new and existing form field field types, see ExtendingFormControls
11 AfterSaveHandler WalterMundt $text, $topic, $web, $error Callback after a topic is saved, with status of save available.
12 PluginContentTypeHandler SimonClift $contenttype, $text? In TWiki.pm sub writeHeaderFull, allows the plug-in to change content type, e.g. to application/xhtml+xml so that the LaTeXToMathMLPlugin works cleanly, but if MathML isn't required, the old text/html type is used (to allow older, non-XHTML-compiliant text not to confuse the browser.
13 NotificationHandler MartinCleaver $topic, $web A couple of plugins have special mail-out scripts. These could be eliminated if a handler was added to FuncDotPm
14 UiExtendedActionHandler MartinCleaver $topic, $web, $param1.. $paramN Could we eliminate PluginBinNameClashes and indeed, new bin entries by adding a binHandler, and centralised handling a la the mega script in MegaTWiki ?
16 AfterCommonTagsHandler PeterThoeny $text, $topic, $web Callback at the very end of the common tags handler; needed for Plugin that caches variables
17 BeforeBreakLockHandler MartinCleaver $topic, $web, $user2 Asks permission to break a TopicLock
18 AfterBreakLockHandler MartinCleaver $topic, $web, $user2 Called after a TopicLock is broken
19 TopicRenamedHandler MartinCleaver $webTopic1, $webTopic2 See AvoidRenameLosingHistory
20 TopicRequestedNotFoundHandler MartinCleaver $topic, $web See AvoidRenameLosingHistory
21 WebRequestedNotFoundHandler MartinCleaver $web, $user Generalise hook for create web
22 RegistrationWikiNameHandler MartinCleaver $emailAddress See RegisterCgiScriptRewrite
23 processInternalLink JuergenPabel $web, $topic, $anchor, $theLinkText, %linkAttributes See PluginHandlerForLinks
24 processExternalLink JuergenPabel $web, $topic, $anchor, $theLinkText, %linkAttributes See PluginHandlerForLinks

Plugin Hooks Rejected

Proposal No. Hook requestor Parameters Description

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; 
in Form::changeForm() )

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


Refactored to make it easier to track propsed plugin hooks.

-- 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 smile

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

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

Edit | Attach | Watch | Print version | History: r58 < r57 < r56 < r55 < r54 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r58 - 2007-02-17 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.