The Private Upload module provides a very similar feature to this module.

One of the 7 principles of the Drupal project is collaboration. Would you consider merging your project into that one and collaborating with it's authors?

Otherwise, it would be great if you could document what makes this module different so that people can make a good decision about which one to use.

Comments

solipsist’s picture

donquixote’s picture

Technically..

"downld"
- D5 only (ok, I would have to push for a D6 version)
- does a http redirect (to system/files), something we like to avoid where possible.
- uses hook_init + drupal_goto, which needs a modification of module_weights.

"private_upload"
- does a lot of things that you don't need, if you use filefield for your private files. filefield_file_download does a good job of access checking (if you use a dev version or apply a patch, see http://drupal.org/node/516104), and can be extended with other modules.
- has some known conflicts.
- changing it too much could break existing sites.
- private_upload adds new access rules implementing hook_file_download, while private_downloads only does the routing to the file_download callback. In fact, these are two different and unrelated tasks.

----------

Now, that said, I notice that in fact none of these modules is needed, if you want to build a restricted download area from scratch using filefield and some other node access modules. You can just write in your .htaccess file (the one in drupal root dir) in the mod_rewrite section:

RewriteRule ^sites\/default\/files\/(download_dir_1\/.*)$ index.php?q=system/files/$1
RewriteRule ^sites\/default\/files\/(download_dir_2\/.*)$ index.php?q=system/files/$1

where "download_dir_x" is the directory you want to protect. Thanks to system_menu(), the request will be dispatched to the callback file_download(), and the effect will be exactly the same as with private_downloads.

If a requested file is not in the database, it can happen (I'm not sure atm) that Drupal will not send the appropriate headers. But as long as we are dealing with filfield and imagefield, it should be all fine.

---

Now I feel a bit stupid, though not because of the above mentioned other modules...

If the discussion does not bring up something new, then maybe I should remove the module, and instead create a documentation page (or look if there's an existing one to improve).

How do I remove a module?

greggles’s picture

It seems that functionally the modules are quite similar. If a module is unmaintained (like downld) then you should take it over rather than creating a new one. If a different module is buggy then it's worth fixing.

That said, if you want to remove this module just say the word and I can do it.

donquixote’s picture

I created a manual page,
http://drupal.org/node/540754

-------

Taking over / deleting:
I think the module in the current form is not needed. However, there are still some use cases that could justify a module different from downld and private_upload:

  • Access checking based on path or folder (useful for import directories)
  • Protection of orphan files
  • Protection of thumbnails generated by imagefield or imagecache.

I will give myself some more time to think about this, maybe later I will decide to delete the module.

donquixote’s picture

Maybe this project could have another use case some day, but for the next months I won't have time to think about that. Thus, I think it is safe to remove this module. If one day I come up with something new, I can still create a new module for that.

Please also have a look at http://drupal.org/project/private_download, which is yet another approach to put all this into a module.

greggles’s picture

Status: Active » Fixed

donquixote made a handbook page about the topic and updated the project page to reflect the handbook. I marked the releases as unsupported to put the project into a "sleep" so I think this is in a good state now.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.