Summary: Talk Page for Attachtable recipe
Maintainer: Eemeli Aro


I'm open to suggestions for how to improve this. More specifically, I'd be interested to hear about the following: --EemeliAro November 25, 2007, at 04:58 PM

  • What other information columns should there be?
  • Is there a need for more fine-tuned control of the action links?
  • Should the JavaScript prompts and confirmations be replaced by HTML pages?

HansB:This is a great recipe, thanks! But I fail to understand from the documentation how to display thumb images in an attachtable or better when hovering with the mouse over an image link of the attachtable (onmouseover => css popup of thumb image). how can attachtable use thumb images? I do understand setting a thumb pattern with $FileInfoThumbnailFmt.

Hi. Thanks for this useful recipe, I really needed this! I have two request for the deleted files.

  1. Could you please change the link on the filename with a normal download link (or maybe better no link at all), and add two superscript commands like for the visible files: "r" to restore the file, and "x" to physically delete the deleted file from the directory.
  2. The "x", "Δ" and "r" links, as well as the deleted file names should be displayed only to users with 'upload' rights. Thanks! --Petko November 24, 2007, at 09:58 AM
Done and updated as version 2007-11-25. Normal download links for removed attachments don't really work since the internal function MakeUploadName by default takes away the comma in the filename, so I just made the restore link a superscript R. If you need easier access to different file versions, you're talking about a different thing than Attachtable -- though it could be nice... --EemeliAro November 24, 2007, at 04:46 PM
Fantastic, thanks for the lightning fast reply! Wow. I also like very much the higher level of authorization for really deleting files. Excellent! (P.S. On sites with the default $EnableDirectDownload=1; it is possible to download a deleted file for review even if the server sends it as binary. But never mind, I am not sure if it will be really used. Thanks again.) --Petko November 24, 2007, at 05:16 PM
True, but I'm not convinced providing the link is a good thing; I'd say it's more likely to confuse. As an alternative, I've changed the restore action to prompt for an optionally different filename. --EemeliAro November 25, 2007, at 04:58 PM
... and now you can get direct links as well, if you want them, using $EnableAttachtableLinkDeleted. --EemeliAro November 27, 2007, at 06:08 AM
Thank you my friend. I tested the new version with the renames and it is excellent. --Petko November 27, 2007, at 09:18 AM
Don't seem to be able to stop fiddling with this. Direct links to deleted files now work, independent of $EnableDirectDownload and with the proper MIME types, so should display correctly in the browser. --EemeliAro November 27, 2007, at 06:01 PM
Excellent! This is the best solution. Thanks again! --Petko November 29, 2007, at 01:01 PM
I think the current features are great. We could hardly have another column of information, as PmWiki doesn't store any (like: who uploaded the file). I'd like to have a way to hide some files from the list, and this possibly to be configured in config.php and overridden in the wiki page. For example: $AttachtableSkipPattern = "/^th\\d+---/"; and (:attachtable skip="/^th\\d+---/":) will allow us to not display thumbnails created by ThumbList.[1] And skip=none to display all files. About the JavaScript: I believe it's fine. Most webmasters have decent browsers, and a JS prompt is very easy, fast and straightforward. Additionally, it is preventing search robots from messing with the attachments (for example, on completely open wikis). Thanks. --Petko November 27, 2007, at 09:54 AM
Hmmmm. File uploader information isn't necessarily impossible. PmWiki indeed doesn't store the info, but that just means it's a matter of modifying HandlePostUpload until it does. Also page histories could tell who and when first referred to an attachment, which is relatively synonymous to a file creation date. --EemeliAro November 27, 2007, at 06:01 PM
like the skip idea, will see about implementing it. The JavaScript doesn't do anything about stopping spiders, as the links still have valid targets. If your wiki is so open that you let anyone have upload permission and you implement Attachtable, you really ought to require some authentication for the Attachtable actions. --EemeliAro November 27, 2007, at 06:01 PM
How about adding such a hook:
# added after "if ( @$matchext &&..."
   && !$AttachtableFileCheck($file, $opt) ) continue;
   $filelist[$file] = $file; # current line 266
This will allow me to write the checking function. --Petko November 27, 2007, at 08:09 PM
Done, see above and source code as it's slightly different from what you suggested. --EemeliAro November 28, 2007, at 05:31 AM
Thanks, it works for me (the "static" variable may interfere if there are two attachtables in a page). --Petko November 29, 2007, at 01:01 PM
It shouldn't, as each is processed in turn, and each gets initialised before looping through the files. Hence provided your $AttachtableFileCheck doesn't assume the static variable is FALSE if the property you're looking for isn't in the (:attachtable:) directive. --EemeliAro November 29, 2007, at 02:17 PM

I have now this idea of implementing a parameter like list= in pagelists, and an array similar to $SearchPatterns which admins can define. May be much better and flexible than skip=. This could be a lot of work, I don't know yet, so unless you like it a lot and are impatient, I'll write it in a couple of days. :-) --Petko November 29, 2007, at 01:01 PM

Something like the pagelist list= is probably the right answer for this, but I haven't the time to implement it just now -- it'll probably be more than a week until I've next got time to look at the code that deeply again. So go ahead and implement it, if you want, and publish it here. Hopefully I'll have enough time tomorrow to polish up a new version, which can provide summary info and optionally ties together with your RecentUploadsLog. --EemeliAro November 29, 2007, at 02:17 PM
Ok, very good. Thanks. --Petko November 29, 2007, at 03:01 PM
Here it is - Demo. I talked with Patrick who suggested to do it this way (MakeName, list=default...) and that some day he will add such a function to PmWiki. It is brilliant now, really! (Removed the hooks that we added for the $AttachtableFileCheck, as the new way is more powerfull and fast.) Thanks! --Petko November 29, 2007, at 07:52 PM
The recipe now includes a filter=xxx parameter for the directive that allows for this kind of regular expression filtering --Eemeli Aro April 17, 2009, at 08:02 AM

I've modified Attachtable to use UserAuth to support specific page and group auth access i.e. <action>_group/page. You can download it here: attachtable_userauth.phpΔ //Aidin

The UserAuth port probably ought to be updated to account for the new version. I've never used it, but I find it surprising that it doesn't work with the RetrieveAuthPage function. --Eemeli Aro April 17, 2009, at 08:02 AM

Nice recipe, but I have one Question: I've added this recipe to our project wiki (, but deleting files doesn't work. I don't seem to have delattach permissions (action link not displayed, only upload and rename) even when I'm logged in as admin. The wiki does not use any advanced auth mechanisms (AuthUser, UserAuth, ...), just definitions for the $DefaultPasswords admin, upload and attr. How do I gain "postattr" permissions? The PmWiki docs say nothing about it. --Jan R

Hi. Somehow I have had similar problems, so here is my local configuration:

$HandleAuth['deldelattach'] = 'admin';
$HandleAuth['delattach'] = 'upload';
$HandleAuth['renameattach'] = 'upload';

This allows me to delete the "deleted" files as admin. Hope that helps. --Petko June 11, 2008, at 01:04 AM

Thanks a lot, that solved all my problems! This is exactly what I wanted. --Jan R
This should now be fixed in the recipe, probably caused by not including a few defaults for $HandleAuth that are set in upload.php which in many cases is included after attachtable.php. --Eemeli Aro April 17, 2009, at 08:02 AM

How would one go about changing the display of filesize from bytes to KB, or even to MB? thanks!

overtones99 June 18, 2008, at 06:08 PM

In the current version this is not possible; I could code this next week if Eemeli didn't do it in the meantime. --Petko June 24, 2008, at 05:57 PM
Sort of answered this and the following question on a post to the mailing list, but haven't actually implemented the code. Petko: feel free to code this if you've got the time and interest & add yourself as a recipe maintainer; I wouldn't actually mind you modifying the "official" attachtable.php either, as long as you keep me up to date. --EemeliAro June 25, 2008, at 05:08 PM
Thanks Eemeli! the code you pointed me to works! simply switch:
//$s .= '<td>'.number_format($stat['size']).'</td>';   /// original this is where the byte size is created/calculated
  $s .= '<td>'.bytesToNBytesFunc($stat['size']).'</td>';   /// *** call func to convert to KB
... and changed the code from the PHP site to make it "American" style (decimals instead of commas):
/// from [[]]
function bytesToNBFunc($a) {
   $unim = array("B","KB","MB","GB","TB","PB");
   $c = 0;
   while ($a>=1024) {
       $a = $a/1024;
   //return number_format($a,($c ? 2 : 0),",",".")." ".$unim[$c];
   return number_format($a,($c ? 1 : 0))." ".$unim[$c];  // using decimals instead of commas, 
                                                              and only 1 decimal point...
works great. thanks for the suggestion. overtones99 June 25, 2008, at 08:15 PM
This is now included in the recipe directly, with a slightly more terse output & the full filesize shown in a tooltip. --Eemeli Aro April 17, 2009, at 08:02 AM

Hi. How can I prevent attachtable from redirecting to the confirmation on Group.Page?action=upload..., and instead just go back to the page where I was uploading from (in this case, Group/Uploads)? Even better, I'd love to be able to have an options field like this:

(:attachtable MyGroup.MyUploadPage

Is something like this possible? Thanks, overtones99 June 22, 2008, at 04:58 PM

In the current version this is not possible; there are a number of actions (uploading, deleting, renaming, replacing a file...) which issue a redirect to the uploads form and list -- after which of these actions you need to redirect elsewhere? --Petko June 24, 2008, at 05:57 PM
Note that you may find Attachtable extremely useful if you place it below the uploads form, in the page "Site.UploadsQuickReference" on your wiki, replacing the Attachlist markup. This way it will show on all your uploads pages, and it is maybe what you need. --Petko June 24, 2008, at 06:04 PM
Hi. I guess in my situation I've been using attachtable on a Group/Uploads page (each user has their own group and uploads page), which employs a couple modified versions of the uploadform recipe... problem i'm having is the confirmation page that you get... but i figured a way out of my predicament (minus the confirmation):
// *** Prevent confirmation page - Placed in both deleteattach and renameattach functions ***//
if(stristr($pagename,"Uploads")) { // skip uploads page, and redirect right back to page's uploads	
               // good if upload list is at the bottom of the page
  Redirect( $pagename, "{\$PageUrl}#currentUploads" ); 
} else { // DEFAULT ACTION
  Redirect( $pagename, "{\$PageUrl}?action=upload&uprname=$upname&$result" ); // original redirect
my only suggestion was that it my be nice to have a 'redirect' option where redirect=1 or by default uses the default confirmation page... and 'redirect=$PageUrl#currentUploads' goes to where you want after uploading
overtones99 June 25, 2008, at 09:27 PM

Brilliant! Great work, thanks so much for this recipe! /Elk

I just downloaded the latest version. It seems to be failing (as if in an infinite loop?) on line 371: $html = MarkupToHTML( $pn, $pg['text'] );

When I comment out this line it seems to work. I can't find that anything is done with the $html variable anyway, so maybe this is leftover code from the previous version? ~Kory -> mailto:webmaster [snail] herpsofarkansas [period] com, April 18, 2009

This step is necessary for counting attachment references in wiki pages. The important part isn't the resulting HTML, but the way that MarkupToHTML() ends up calling AttachtableCountUploadLinks() for each attachment link it encounters. As to why it fails I'm not really sure. It could be that it's just taking too long to parse pages before encountering a PHP max execution time. For a quick fix, try adding the following to your config file:
$AttachtableProperReferenceLookupMaxPages = 0;
That'll force Attachtable to always use a simpler/faster attachment link detector. You may also try setting that to other low values; it defaults to 8. —Eemeli Aro April 20, 2009, at 06:46 AM

I'm hoping to use this recipe in conjunction with ThumbList. Do you have suggestions about how to get the most out of this combination? ...such as, I would like to HIDE the thumbnail files created by ThumbList. ~Kory -> mailto:webmaster [snail] herpsofarkansas [period] com, April 18, 2009

To hide files from Attachtable output you can use the filter= parameter. For ThumbList, I believe the following may be appropriate:
(:attachtable filter="!^th\d+---!":)
Alternatively, to globally hide files matching a pattern you may assign that pattern to the variable $AttachtableDefaultFilter. —Eemeli Aro April 20, 2009, at 06:46 AM

Have you considered adding a thumbnailing capability to the recipe? (Maybe as a separate column, or on mouse-over)

Thanks. ~Kory -> mailto:webmaster [snail] herpsofarkansas [period] com, April 18, 2009

This is... a possibility. I'll have to ponder on this a little more, but it might indeed be interesting to do this. Actually, this kind of ties together with other development ideas I have for Attachtable... —Eemeli Aro April 20, 2009, at 06:46 AM
Now implemented on mouseover; you'll need to define an apporpriate $FileInfoThumbnailFmt to get this to work. —Eemeli Aro April 27, 2009, at 02:06 PM

Currently the CSS clutters every page. Could you add a simple expression to include attachtable conditionally for all used actions?

Is looking for upload|attach|downloaddeleted sufficient? OliverBetz

For version 2009-04-20: assuming that you're only using (:attachtable:) from Site.UploadQuickReference, the following conditional should do the trick:
if (in_array( $action, array('upload','delattach','renameattach','downloaddeleted') )
Alternatively, what I actually do on my own sites is to include the relevant CSS as an external file and set $HTMLStylesFmt['attachtable'] = '';
For version 2009-04-27: Fixed by putting the CSS into a separate file, see the install instructions for more information. —Eemeli Aro April 27, 2009, at 02:06 PM

There seems to be an issue with the show parameter in version 2009-04-28. show=deleted and show=normal does not work as expected. It shows the whole table without the filtered filenames. show=linkonly does what it is supposed to do.

Thanks! JL? May 09, 2009

Thanks for the great recipe! I am trying to hide the thumbnails created by the Thumblist recipe using the "filter=xxx" feature but am geting errors. This is what I have:

(:attachtable filter=!th*:)

I get the following errors:

Warning: preg_grep() [function.preg-grep]: 
  No ending delimiter '!' found in [snip]/pmwiki.php on line 604
Warning: array_diff() [function.array-diff]: 
  Argument #2 is not an array in [snip]/pmwiki.php on line 604
Warning: Cannot modify header information - 
headers already sent by (output started at [snip]/pmwiki.php:604)
in [snip]/pmwiki.php on line 1079

Also, the (:attachtable -sortable:) does not work...

Am I doing something wrong? skumar? May 20, 2009, at 10:40 AM

You should use (:attachtable filter='!^th\d+---[0-9a-f]{6}?--!':) to not list the thumbnails.
JL May 20, 2009, at 04:00 PM

I have tried that and it did not work. However, what did work was (:attachtable filter='!th*!':). But this seems to be case-sensitive. I am still seeing the "Thumbs.db" file show up in the list. Any tricks to making this case-insensitive? skumar? May 22, 2009, at 03:00 PM
If you use the ThumbList Recipe which creates thumbnails with names like th128---ffffff--image.jpg.jpg the filter rule definitivly works. To make it case insensitive add an 'i' at the end. (:attachtable filter='!th*!i':). But keep in mind that this will filter out every file that has a 'th' in its filename, not just at the beginning. JL May 24, 2009, at 04:47 PM

I am trying to display the attachtable cookbook, but everytime I do, it literally just displays (:attachtable) on the page. I have followed the instructions exactly, and re-installed the cookbook twice. What am I doing wrong?

  1. Make sure you're using (:attachtable:) and not (:attachtable) .
  2. Make sure you've set $EnableUpload = 1; before including the recipe.
  3. Make sure you've copied the whole switch statement from the installation instructions to your config file.
  4. If it still doesn't work, tell me exactly what you've got in your config file for Attachtable.
    Eemeli Aro July 27, 2009, at 04:51 AM

A minor possible enhancement: for show= and data= provide a "-" parameter where, say show=default,-delete etc. Thanks simon August 22, 2009, at 09:13 PM

It seems to have problems with filenames with spaces; lots of zero references when files are referenced, lots of "missing files" that are the substring to the left of the first space. I have set $AttachtableReferenceListPatterns['limit'] = ''; but it made no difference.

Maxim? September 02, 2009, at 04:46 AM

I have $UploadPrefixFmt='/$Group/$Name'; and (:attachtable *:) shows this:

file name    size (bytes)    refs    last modified    MIME type
    total 3 directories, 0 files

no matter what $EnableDirectDownload is set to. But the description seems to indicate that I should be able to browse the directories. So, shouldn't this work? - Rogutės

The cookbook works fine but I have got a 'PHP errors' with attachtable. I am using a pmwiki FARM.
Here is a typical error from apache2 logs
[Thu Feb 25 16:23:41 2010] [error] [client] File does not exist: /wiki/fields/PLANCK/planck, referer: [(approve links) edit diff]
It appears with any URL !!
It looks like the cookbook does not scan the correct directory, it should be /wiki/fields/PLANCK/uploads/ or /wiki/fields/PLANCK/wiki.d/ ???
I have echoed all configuration variables, they look fine.
It is very difficult to track which 'fopen','readdir'... functions used in the cookbook have not the correct filepath.
Of course, I tried $AttachtableProperReferenceLookupMaxPages=0; No EFFECT
I have tested version 2.2.6 and 2.2.13 of pmwiki.
Thursday 25 february 2010, Pierre PRIOUL, Institute of Astrophysics of Paris, Planck Team, France
I found the error in my configuration. In case of a wiki farm, I have to copy all /pub/attachtable.css in the sub-directory of the farm:
This way the apache2 server is able to find css files and js files.
I had the same problem with the css file of the PmCal cookbook.

How does attachtable know if the name is for a group or a page.

(:attachtable NAME:)
Shows the attachments of the group or page NAME.

I'd like to list all attachments for a group, but I don't get the expected result

thanks simon April 07, 2010, at 04:46 AM

Added EmbedBtn and AttachBtn to my version of the attachtable recipe

Hi Eemeli. i wonder if this might of use to you and the community using this recipe? i've modified the recipe so that in the far left column there are buttons that quickly post the necessary attach/embed code for each file into the edit window. i've been using a modified version of an earlier attachtable recipe for years without a hitch. i just updated to the newest version of the recipe, and added and refined my modifications. here's how to test it:

1. download: attachtable-embedBtns.zipΔ 2. substitute my version of cookbook/attachtable/attachtable.php for the one normally used with the last distribution 3. add cookbook/attachtable/attachFileBtn03.php 4. in your pub/ directory, add the embedBtns folder 5. when adding or updating an attachtable (for instance on Site.EditForm), simply add embedBtn=1 or attachBtn=1:

  • (:attachtable NAME embedBtn=1 ... :)
this will add a button next to each filename - the ones that can be embedded in the page (via (:quicktime:), (:flash:), or as an image) are assigned an "embed" button. all other files are given a "link" button which simply posts the file using the "Attach:" markup.
  • (:attachtable NAME attachBtn=1 ... :)
this will add a button next to each filename - all files will be posted using the simple "Attach:" markup, except for images, which will be embedded in the page.

i can provide more in-depth info later. the buttons are using code by PM from guiedit.php. i haven't done extensive testing on this newer version, so there may be some bugs i've missed. if you think this would be an interesting feature to add to the core of the recipe, i'd be happy to write-up more extensive documentation that could be added to the main page. otherwise, maybe i should just post it somewhere else as an alternative version of the recipe?

thanks for the feedback. overtones99 June 23, 2010, at 01:32 AM

Is there a way of having attachtable display all files for a group when attachments are organised per per page?

simon July 22, 2010, at 06:37 PM

How do I specify the sort table of the file list, eg name descending?

simon December 09, 2010, at 02:57 AM

Under Windows Attachtable should not be case sensitive, eg I have Attach:fn.doc but the document uploaded is FN.doc, the refs count says 0, even though under windows the link works correctly.
When renaming under windows (ironically) I cannot simply change FN.doc to fn.doc using attach table, nothing happens.

simon March 23, 2011, at 07:33 PM

It seems that references to image files by the Mini gallery generator don't get counted as references by Attachtable. Can that be fixed?

PaulWiegmans June 3, 2013, at 14:43

This, as with quite a lot of cookbook code, does not like PHP version 5.5, the /e evaluation modifier. See (Migration to PHP 5.5 and Markup_e()) for more background.

AndyG June, 2014

Talk page for the Attachtable recipe (users).