Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
solipsist CreditAttribution: solipsist commentedAlso similar to:
http://drupal.org/project/downld
Comment #2
donquixote CreditAttribution: donquixote commentedTechnically..
"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: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?
Comment #3
gregglesIt 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.
Comment #4
donquixote CreditAttribution: donquixote commentedI 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:
I will give myself some more time to think about this, maybe later I will decide to delete the module.
Comment #5
donquixote CreditAttribution: donquixote commentedMaybe 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.
Comment #6
gregglesdonquixote 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.