You are here: Foswiki>Tasks Web>Item572 (04 Oct 2010, KennethLavrsen)Edit Attach

Item572: Issues with afterAttachmentSaveHander API

Priority: Enhancement
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component: Plugin API
Reported By: Foswiki:Main.EugenMayer
Waiting For:
Last Change By: KennethLavrsen
Issues with afterAttachmentSaveHander API

I have encountered several issues with the afterAttachmentSaveHander API. We need to decide how to resolve them. Background: I am developing a plugin that wants to save a companion attachment. It's not possible with the current API. See

In this case, when an image is saved, I want to generate and save a companion thumbnail. I want this to happen automagically whenever an attachment is saved, transparently to the user. (Except that the user gets to use the thumbnail!)

Secondarily, I want default links to images to display the thumbnail, but link to the large image. Issues

  • the afterSave handler is called holding the topic lock. So any attempt to call saveAttachment recursively will deadlock.
  • saveAttachment closes the temporary file that (may have) used to hold the data just before calling the handler. This guarantees that the handle must reread the data all the way from the repository. This is unfortunate - on performance and atomicity grounds.
  • saveAttachment does not pass the new attachment's metadata to the handler - and it hasn't written the topic text back yet either. So the handler really can't know what it's doing.
  • there is no hook for the createlink option. It would be useful to be able to modify the returned link to meet coding or functional requirements. For example, to use %ATTACHMENT% or otherwise use an image in the link. (You may have seen the AttachLinkPlugin? appear...I suspect that could export some useful methods for it and the ImgPlugin? , but I digress.)


  • Implement a postAttachmentSaveHander callback - right at the final } of saveAttachment. It should pass everyting it knows.
  • Provide an "already locked" flag to saveAttachment for recursive handlers - this would prevent the deadlock. But the handler would need the open topic.
  • Move the tempfile unlink down to after the if( haveHanderlFor ) block.
  • Fill in %attrs before calling the handler, and pass them along.
  • Do something really different.
  • I can do something local - the prototype simply writes directly to pub/web/topic/file

Thoughts? Takers?

-- Contributors: TimotheLitt - 21 Dec 2008

This API was deprecated in favour of the afterUploadHandler, but there is a risk that this new API may have inherited some of the issues described here, so raising from 'Enhancement' to 'Urgent' as the API must be reviewed before 1.1 is released.

  • locking - looks OK to me
  • new handlers use streams, and should not close streams (as documented)
  • meta is now passed
  • createlink is not supported - the handler is called far too late for that.

Marking as releaseable. There is still scope for improvements, but they should go through the feature proposal process.

-- CrawfordCurrie - 12 Jul 2010

ItemTemplate edit

Summary Issues with afterAttachmentSaveHander API
ReportedBy Foswiki:Main.EugenMayer
SVN Range TWiki-4.2.3, Wed, 06 Aug 2008, build 17396
AppliesTo Engine
Component Plugin API
Priority Enhancement
CurrentState Closed
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r4 - 04 Oct 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy