release file attachments should use drupal upload functionality

Out of curiosity, if we were to allow multiple files per release node, how would we alter the project release download table UI to integrate with multiple files per release? I'm curious if you've thought about this and whether you had ideas for this. This might be something to keep in mind when working on http://drupal.org/node/176776, though I realize it's a bit late to be bringing this up now.

something to keep in mind when doing this is the current global url option, which allows files to be located on a different server than the web server. i'm not sure how we would be able to do this if we used the core upload module.

I just marked #11416: Please provide *.zip downloads. as postponed until this is fixed.

One other potential complication I thought of relates to the update status module. If multiple files are available on one release node, I have a feeling that update status will get confused, since it probably expects there to only be one file per release node.

Jumping on this issue as it appears to be relevant to my own project which has multiple files per release.

file handling for release nodes is broken in HEAD now (one of the problems reported at #357920: Numerous errors when previewing/submitting a new release node). I'd rather we just worked on this issue, instead of fixing the existing file upload code.

One thought on how to make this work at all... Initially we have the problem where there are lots of places in the code (download tables, browsing views, etc) that assume 1 file per release node. It seems like it should be possible to form_alter() the upload form elements to add a set of radios to select which file attached to a release node should be the "main" file that shows up in all these other places. We could still keep {project_release_nodes}.file_path and friends, and just populate it with the data from whichever file the user selected as the primary file for that release.

Via views and/or your theme, you could still provide a table of downloads of different files on the same release node (e.g. you have compiled software and you ship binaries for N different platforms) if you really needed.

I dunno, maybe this is a hack that just postpones the inevitable. At some point we need to come to grips with the fact there are going to be N files and you might want to see more than 1 of them. I'm just trying to figure out how we can get this working without too much hassle in the short term, while paving the way for goodness in the long term. I certainly don't want to keep supporting out own upload code, especially since it's currently completely broken in HEAD (and was until very recently totally insecure in D5).

I realize I'm not really in a position to say that we shouldn't take the easy way and not hack this in when I can't volunteer to be the one to make that happen, but what the heck, I'll say it anyway :)

Say a site wants to provide both .zip and .tar.gz files to download. If we keep {project_release_nodes}.file_path and file date, md5, etc. only for one file then for a site to make it possible and useful to have multiple files for a release node, they would have to do a lot themselves, like keeping track of the MD5 hashes, etc. They could probably provide just additional files but not the other file metadata information, but to an extent that is the whole point of a project release node.

I really think we should provide .zip files on d.o as well, for usability. For people who are trying to use Drupal on windows (even if its a newbie who wants to provide a simple patch or play around with Drupal some), .zip files are much easier to work with because they don't require downloading a separate program that can open and extract them. So I'd be in favor of us tackling this problem (both on the back end and front end) sooner than later.

From what I've heard this could potentially be a lot easier to do in D7, with its improved file handling, but that would be a long time to wait.

Just to be clear, I realize that you agree that we should use the core upload.module instead of project_release for file attachments, and that you think that should be done soon. I'm just arguing that postponing the inevitable might not be the best approach for the rest of this issue.

I don't think core upload.module provides sufficient permissions for this to really work, does it?

@merlinofchaos: As far as I know there is no way to limit the number of files that can be attached to a node with upload.module (at least, not to a small number like 1 or 2) built into core. I think we could get around such a limitation via hook_form_alter. Can you clarify what you meant in your comment above? Are you talking about permissions we could use to limit uploading of files, or limiting downloading of files already uploaded via upload.module?

upload.module provides very limited permissions or no permissions for:

What kind of files you can upload (this is global)
Who can attach files (this is global)
Who can view attached files (this may not even be a permission)
How many files you can upload (no limit)
How much storage space you can use (this may not matter).

Given the potential problems with this route, we decided over at #357920: Numerous errors when previewing/submitting a new release node to basically port our own upload code to D6. In the process, we changed the schema to introduce a new {project_release_file} table. Release files are now stored in the {files} table, and this table stores the additional metadata (filehash) and the release nid. Much of the plumbing is now in place to support N files per release, but there are a few // TODO comments for places we still assume 1 file/release. See also #366448: Port packaging script to new {project_release_file} schema.

Therefore, this specific issue is hereby postponed, probably until D7 when upload.module a) doesn't quite suck as much and b) allows more flexibility for the kinds of stuff we need.

Hey, is Drupal 7 now looking like it might resolve this? I'm following the issue spaghetti here in an attempt to work out why we don't package Zip files, and this issue seems to be the blocker. I said elsewhere, I am happy to devote some of my (company and/or personal) time to pushing this on, if anyone wants to take me up on it. I think the whole zip thing is a really important issue and ties in well with the Drupal 7 efforts to make Drupal more approachable for newbies. As such, this issue becomes a whole lot more critical, to my mind, since it's the blocker for zips as packages on Drupal.org.

Nope, this issue is irrelevant for .zip on d.o. Still postponed and normal here...

D7 uses a file field for this and works well.