Make imagecache work with private downloads

No, sorry, that doesn't happen at my place, I don't know what could be causing it. I suggest to wait for this patch being applied, and to open a new issue then, it doesn't quite belong in this one.

> Could you please clarify what you mean by "Just add the appropriate menu entry, remove the requirement message, and you're done."?

Sorry, I meant that code-wise. Menu entry, as in "item that is returned by hook_menu(), and catches system/files/*". Requirement message, as in "the thing that causes the admin root page to display a warning that public downloads are required". Nothing you have to do by yourself (it *should* just work).

> This preset is called in node-image.tpl.php with the line [snip]

Maybe there's a difference in calling the imagecache theme function directly vs. letting imagefield (with the preset as field display method) do it. I need a break from image{field,cache} so I'm not currently motivated to research this.

Please try if it works in an imagefield, and maybe have a look at imagefield's theming code. If that doesn't work, try to apply the immediate image previews patch for imagefield, and try again (I changed the filepath stuff a bit there, your problem might stem from the same origin as image previews). If that still doesn't work, you can ask me for my heavily patched module set. And if that doesn't work, you might wait for the next best coder who is annoyed enough to fix it, or try it for yourself.

Well I don't dislike Windows users per se, but...

• There's a reason that .module is not allowed as an extension. Posting complete .module files is evil, keeps the maintainer from doing real work, doesn't tell what has been done, marks you as incompetent (sorry), and the file will be out of date as soon as the official module is modified in some other way. In other words, don't do it. I diffed your version of the module with the CVS version and made a patch out of your changes (attached).
• Get an editor that is able to keep line endings in their original format (which is Unix format for most Drupal modules, imagecache included).
• To make a patch, it's advisable to check out the current CVS version of the code, and let CVS (either the command line client or your favorite GUI) generate a patch. If you don't want to use CVS (which you really should if you want to contribute) then you can get Cygwin, and that includes the 'diff' tool (for creating patches) and the 'patch' tool (for applying patches). Patches and diffs are two names for the same thing, they describe changes to the code.
• If you want to get your code accepted, try to separate coding style fixes from functionality changes. Keep two different versions of the module, one with style fixes and the other one with functionality changes. Make patches out of each modified version, and see your code applied with much less hassle for everyone.
• When you submit a patch which does something that's not obvious, try to explain the reasoning behind your changes.
• If you don't like doing all this stuff, keep in mind that the official version of the module changes and improves as well, and if you don't get your changes into CVS, you don't get all the improvements and bug fixes. Getting changes into CVS is for your own good - more effort initially, but minimal maintenance effort once your code has been accepted. Doing stuff the right way also gets you a good reputation in the community.

Apart from that, there's no way that imagecache can work with public downloads AND clean urls, without pre-generating images (which imagecache does not intend to do). It's just not possible, because of the way that imagecache intercepts menu paths. Don't delete the concerned requirement message and claim it works, because it can't.

Apart from that as well, I still vote for the inclusion of my patch. Less intrusive, clearly scoped.

@leo_pape:
Yes, my patch works with Private downloads only, in addition to the already working Public download method with Clean URLs enabled. I explained in your new issue why this is the maximum of what's possible if you want to keep the characteristics of Public downloads.

On further thought, it should actually be possible to support Public downloads without Clean URLs - we just need to handle those (and only those, not the ones _with_ Clean URLs) like Private downloads. That nukes the performance gains of Public downloads of course, but in opposition to what is the case now, it would actually work. I'll look into improving my patch into this direction. Like, er, Soon(tm).

My patch from here is now deprecated, its official successor has been posted to issue #141127. Closing this issue with "duplicate" status.