Feature Proposal: Improve attachment handling

See also: SharePointVsTWiki. Related: Document Management System, DMS

Foswiki's current attachment display is made for a small number of files. To be able to use Foswiki as document repository we need advanced features.



  • Instead of searching (and better than to copy the file hierarchy) use filter view options with the attachment table. Show only documents of type, or uploaded since date.
  • Tag documents, or classify them by type; add metadata such as author, document type, document status.
    • Not supported yet
  • Tag multiple attachments at the same time.
  • Tag image attachments to be used as thumbnail when displaying this topic in search results (e.g. the logo of a company on a company topic) * SolrPlugin currently takes the first image attachment found; the next release will look for an isthumbnail attribute in the attachment metadata


File handling
  • Move multiple attachments at once to a different topic / to trash.
  • Download multiple attachments as a ZIP file
  • Update topic references with attachment move
    • Not supported yet

Impact and Available Solutions


-- Contributors: ArthurClemens, MichaelDaum


Exciting prospect!

If it could look and (largely) behave as a Windows-explorer type document repository, than that'll certainly keep training times down. Being able to create a folder hierarchy would be a part of this.

In MsWordToTWikiMLAddOnDev, i've included a link to a VBA macro available for MediaWiki. Apart from converting the Word file, they are able to instantly upload all data (including all extracted images) to the correct location on the server, making the transition from Word to MediaWiki a snap. Having some kind of central document repository in TWiki could perhaps help us achieve the same thing...

-- JosMaccabiani - 17 Dec 2006

A little cleanup of this brainstorming topic.

-- ArthurClemens - 22 Dec 2009

ThumbnailPlugin contains the attachutil utility, which is a command-line script for manipulating attachments.

It's particularly good at managing multiple attachments - it will do wildcard attach, remove, etc.

It could easily be packaged as a separate utility.

-- TimotheLitt - 06 Jan 2010

How about the ideas from http://twiki.org/cgi-bin/view/Plugins/JavaPasteAddOn ?
  • Paste pictures from the clipboard to the browser
  • Drop files as attachments onto the page using drag-and-drop.

The beta-quality code has been available for close to a decade.

-- MartinCleaver - 27 Jan 2010

I second the idea for an explorer like interface. My colleagues here still mostly use Frontpage (!) and this is the only feature of Frontpage that distinguishes it from Foswiki. Bulk uploading attachments in Foswiki is too time consuming; it detracts from an otherwise excellent tool.

-- JohnPoplett - 17 Feb 2010

There are a couple of uploaders that I recently evaluated. Most promising is Plupload. It has got support for uploading attachments using

  • Adobe Flash
  • Google Gears
  • HTML 5
  • Microsoft Silverlight
  • Yahoo BrowserPlus

It allows to specify a preference list of "runtime engines" using the first one that is supported by the current browser. It supports features like chunking, drag&drop and client-side resizing (not supported by all runtime engines though). This software is still quite young being just released 1.0. Out of the box the queuing widgets do not quite support what we need. However, the lower uploader class, which encapsulates the different runtime engines, offers a way to build a custom widget on top.

Independent from this, the new firefox-3.6 implements the File API w3c spec. While firefox is the first browser to actually implement including drag&drop, hope is that long term browsers will adopt this API step by step. This will allow to create very nice uploader interfaces as can be seen in this demo (needs firefox-3.6+).

While Plupload does support html5, it does not make use of File API to that extend. It does however implement the html5 runtime engine using the means available in older firefox versions, as well as in some other browsers that already implement html5 to that level.

That' said I don't think that using a java applet does age well. For now best to do is to give Plupload yet another release cycle and then build an uploader on top of it that satisfies the needs for Foswiki (base authentication, parallel uploads, reassembling of chunking). Note also, that the transfer encoding of Plupload is not supported by CGI.pm as the net data is posted as an octet-stream. So this needs a bit of work as well. I am currently exporing this as part of a next UploadPlugin release which will come with a matching upload rest handler. This will allow us to explore these new techniques before adding it to the core.

-- MichaelDaum - 17 Feb 2010

Ping. Something along this lines sure would help the battle here between sharepoint and Foswiki.

-- CraigBowers - 12 Jul 2011

See Also: at top of topic gives: Access Denied Attention Access check on SharePointVsTWiki failed. Action "VIEW": access not allowed on web.

-- CraigBowers - 12 Jul 2011

Attachment handling has been vastly improved using the TopicInteractionPlugin which integrates plupload. It is the successor of UploadPlugin.

Wrt SharePointVsTWiki, yep, there still might be some useful resources in that content. For now the Legacy web is read/write protected by the ContentMigrationGroup.

-- MichaelDaum - 13 Jul 2011

I'm a newbie/end user, and I have been using wiki pages with forms to store metadata. That way, each document has structured, predefined metadata. I can't do full text search on stored documents, but this does make it relatively simple to include any type of metadata that FosWiki supports in forms, including an autoincrementing document #. And the metadata is searchable using standard FosWiki search tools. Another FosWiki tool that is useful here is users subscribing to the page for automatic notification of changes.

The other thing that I like about this approach is, I can create a wiki page (with the autoinc generated document #) before I need to save the document. That way, I can include the doc # in the file itself when I save it the first time. I'm using my repository to save technical drawings, and the doc# is part of the notes in the drawing.

The thing I can't do right now is control revisions. I can store revisions as separate attachments, but there is no locking/unlocking of revisions, thus no enforceable workflow. What I like about using FosWiki as a repository is that it is easy to reference stored documents from within other Wiki pages, since I also use FosWiki as a tool during the design process.

-- PaulHarrison - 01 Aug 2011

FWIW There's a semi-commercial WebDAVContrib which allows you to mount the wiki as a filesystem; it enforces access controls, checks in new revisions, takes care of locking, etc. There's also the new SolrPlugin which allows you to search in attachment content.

I have many single-attachment-per-topic type structures, and I wish that we'd just let attachments be first class citizens of topics.

Rather than topic text, we have the attachment binary instead.

That way files can have have their own separate lives, with a DataForm, topic parent, access controls, everything a normal topic has.

-- PaulHarvey - 08 Aug 2011

I second Paul Harvey: "I wish that we'd just let attachments be first class citizens of topics".

That would solve the Attachment version/Topic version sync problem. That being said, I do see a need to store images that are displayed in topics, as children of the topic. And now we're back to the Attachment version/Topic version sync problem...

I still like the idea of "File" type for topics.

-- PaulHarrison - 26 Apr 2012

Added TopicInteractionPlugin to be used to implement this proposal. See also AttachmentStorageInCMS.

-- MichaelDaum - 27 Apr 2012

TopicInteractionPlugin is great, thanks a lot! There is one remaining request which I hear a lot from my colleagues, which is uploading images from the clipboard. TopicInteractionPlugin already implements the uploading machinery, and it also provides an area in the UI which can be used to drop attachments, which makes me think it could be simple to add "upload from clipboard" functionality. Help offered, of course, but I guess I'd need someone to point me into the right direction first...

-- ClausBrod - 07 Mar 2014
Topic revision: r15 - 07 Mar 2014, ClausBrod
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