I prefer the number of clicks/days before expiration option. As stated in the previous thread. I don't really like the use of my_files in relation to purchasing products, to complicated for the user, and requires registration.

I noticed you didn't address anonymous purchasing, and the location of the files -> keeping them out of the web access.

Idan

Erik,

Thanks for all of your contributions to this important functionality.

You mentioned in your note that many of these features you've been working on are already up and running on your project site. Is there a URL where we can access this site and try it out?

Seeing what you've done in action might help jog some ideas for needed features, improvements, or bug fixes...

Thanks,
Ben

I've been thinking about the posts made regarding file_products into core. So far I've come up with two things:

limits on downloads need to be flexible:
It looks like everyone has different needs/wants with how downloads are restricted. Instead of providing a few options for restrictions (by IP address, # of downloads, a set expiration date, etc.), it seems the thing to do is provide a hook that would be called to allow or deny the file download when the file is requested. This way someone could provide their own logic in a separate module for how they want to restrict downloads based on all the different variables (time since purchase, anonymous users, # of time downloaded and so on...).

file management needs to be flexible:
Like with limits on downloads, the way files are managed (uploaded, edited, etc.) is going vary a lot between applications. Music files might need preview versions for customers, images files might need to be watermarked, PDFs might need to be password protected, software will need to have a serial key, and so on. All of this too much for a general purpose file product module. Hooks should be set in place to operate on a file when it is uploaded, to provide new operations in the file manager, and so forth.

I'll try to come up with more hooks as I start writing code.

I think I'd lean more toward torgos' idea of keeping as much as possible in a single module. I don't have any thoughts on what that would include, though. Do you need me to go ahead and move the file product contrib over to you so you can update the download w/ your latest version?

Let me know what you guys would like from me at this stage. I talked to my supervisor and we're thinking about opening up our currently-in-development shopping cart site up so that the other developers here can take a look. A lot of it is broken (I'm still working on theming it). It's either that or create a completely blank slate with different products, etc.; although for ease of use I'd like to keep everything more or less mirrored in both areas.

For now though I can start pasting snippets of code (or attaching them) with regard to the changes I've made. I can also update the current File Product module with the change for order statuses in it. I don't think uploading MY custom version of the module is a good idea yet, since it's not yet feature-complete as far as my needs go.

Let me know what you think.

I'm really excited that so much progress is happening on the file product module. This is definitely something we'll be taking advantage of.

I like the idea of the middle-road... Have a complete working out-of-the-box solution for the most common virtual product strategies like torgos has explained, but keep the inner workings of the module as flexible & hook based as possible so developers can customize everything every step of the way. But hey isn't that whole philosophy behind Drupal?

From what I've read the planned features for the default file product settings sound like exactly what we would need to start selling virtual products through the site. We'd also like to allow users to feature purchased products on their profile, purchase products as gifts for other users, all sorts of cool music sharing stuff so I'm really looking forward to playing with these new core features to see how it works.

Just wanted to introduce myself and let you all know I'm a big fan of any file product progress.

I agree, the core of the module should allow for flexibility - but I am also unsure as to whether or not it should just be left at hooks for future modules.

For instance, I would like to keep a lot of the flexibility I have already coded, and not have to write an additional module (or split the two apart) to provide the anti-leeching mechanism. I think perhaps brainstorming all of the different "core" features, such as time limit, allowable clicks, allowable IP addresses, etc., is fairly broad enough to be usable by everyone requiring downloadable content - enough so, I think, to have them as selectable options in the File Product core.

I understand the need for a single module that does some percentage of most requested feature set. it's probably simpler initially. but is it really simpler in the long run? i like shawn's idea about hooks.

i mean would it really be that hard to modify what you've done to use hooks versus how you have it hard coded right now?

i'm thinking you could keep your code the same and add a few hooks where it's likely that multiple functionality in a given area might be desired. in those hooks you might want to switch / case on an option setting which then calls your original functions depending on the store owners needs. right now, you simply make your most-desired functionality (probably a function call in the case block) the default behavior.

in this sense, my description of a hook is not necessarily a traditional drupal hook where every module is traversed to invoke the hook and add some functionality. It's more or less a wrapper function that checks for a configuration option setting and then simply calls a function based on the setting. the function can be supplied by an include file. in otherwords, your base module will provide a framework which is easier to enhance and dis
|en able functionality.

just a suggestion. i personally like the idea of extensibility in an area that is going to be heavily used and require a lot of tweaking. fwiw, i believe you edited CPill's original module to get the functionality you wanted. what about the next guy/gal, etc.

you can already tell by the interest here file downloads are highly in demand. anyway, i don't have time to code the thing so you'll eventually make your own decisions but thought i'd cast my vote in terms of hooks

sounds good. i guess we're in agreement. rock on ..

I guess the thing to do is both; implement the functionality Erik mentioned (IP limits, download limits, time limits...) and also throw in a hook that gets called after all those other checks are made. This gives us the flexibility for anyone to throw in their needed file download limits and the usability of just enabling the module, configuring limits, and being set to go. If anyone needs only a custom built file limit solution, they can turn off all the built in option and use the hook.

torgo,

is the code with your "complete" mods available for download yet?

i know you worked in and posted 1 change to cpill's original code under his original thread. but i don't think that has any of the enhancements you presented at the top of this thread even though i think you have most of it already working on your test site. not sure you if you followed that .

if it's not posted yet, any idea on a rough eta for posting and where it will posted? i guess if it's going to wind up in core then we just need to bzr update.

fwiw, one thing i've noticed is that sometimes i'll see a thread that's listed as being 'recent' in my tracker meaning i've posted to it and someone else has updated it recently. however, when i go to inspect the thread, the dates are often very old (not recent at all). i think this is probably occurring because someone "edits" a previous post but the original CREATION dates don't change. drupal tries to keep the post context based on the creation date but marks the thread as "recent" based on MOD time. as a result, it's hard to figure out which post about a given thread made it different / recent. I think this is often the case where someone changes the link in an existing (older) contrib module post to update a contrib module download link. It's hard to be fully certain that the module download has actually been updated or not. at least for me it is

i see this same behavior in "alpha ## battle plan" type threads a lot.

not sure if what i'm saying makes sense but thought i'd bring it up since you're going to be taking over this module and it's probably going to be pretty popular. hence a method of posting updates would be best served if as confusion free as possible. of course if this is rolled into core than you simply have to bzr update.. but it's also possible that you will let people bang on the code as a contrib module before making it a permanent part of core.

thanks bud