~ 2 min read
Attachment Links module for Drupal fixes for in-browser downloads
If to quote the attachment links project on Drupal:
The Attachment Links module provides permanent links to files attached to a node. A single, easy-to-remember URL can be used to retrieve the preferred (canonical) or newest version of a file regardless of how many versions of that file have been attached to a node.
Incase the light-bulb didn’t turn on yet for you – with Drupal, if you upload a file attachment then if it doesn’t exist yet it will be saved as .tar.gz. If the user then updates that node with a new file upload of the same name, the filename will change to _1.tar.gz and so on since Drupal will transliterate and correct the filename to make sure such file doesn’t exist yet in it’s files directory.
Attachment Links module mitigates this problem by allowing you to specify a link like
node/2600/attachment and by doing that it’s controller will already pull the correct file attachment for this node and send it over the wire. This enables you to give permanent links (in the form of
http://example.com/node/2600/attachment) because otherwise the exact file system link will always change when you update the file entry.
So far that was a somewhat short introduction to the use-case for
Attachment Links module.
As with most modules, they don’t always scratch your exact itch (@see http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar guideline number 1), and so for us we had the issue that attachments do no retain their original
Content-Type header. Meaning, every file will be forced to download so that if
node/2600/attachment is actually sending over a
readme.txt file, instead of that file to open up in the browser (which was the required case for us) it got downloaded. Same for images, PDFs, etc.
We found it a bit annoying so worked on a fix to maintain this original behavior while still working with this module. For your enjoyment: http://drupal.org/node/1856422