Hey Jan
The new entry would have the same settings as all the other downloads you have created for that order (except for the variable parts of course).
But perhaps an alternative could be to call an event which can change the download files array before you store it in the table?
Because as I said ... if you have hundreds of lines in your Downloads view ... it will stay a real mess. Imagine someone needing to download 50 photos one by one ... would you go back to that shop?
I don't know what all the columns in that table are for. The only ones you really use are id, order_id, title, download_token, download_file, download_hits, download_days, date and published more or less, right?
Since I don't see anything else really used, not in the list of the downloads for frontend, nor backend. My ZIP file is simple there:
I know I'm cutting corners here but I'm looking for a solution to a problem which seems not to be solvable in another way for a shop which would need to handle large quantities of downloads (if sale goes well).
It's obvious that those who would also like to use the code I've written, need to be aware of the consequences.
But I don't see other problems with core functionality and security since we copy all that and they're all the same for one particular order (right after being created). (I know the download token isn't, but you only need one secret token and it's only verified back the moment a guest downloads the ZIP in this case, right?)
Or do you have a better solution?
Or are you saying Phoca Cart is not a solution for that kind of shop?
The new entry would have the same settings as all the other downloads you have created for that order (except for the variable parts of course).
But perhaps an alternative could be to call an event which can change the download files array before you store it in the table?
Because as I said ... if you have hundreds of lines in your Downloads view ... it will stay a real mess. Imagine someone needing to download 50 photos one by one ... would you go back to that shop?
I don't know what all the columns in that table are for. The only ones you really use are id, order_id, title, download_token, download_file, download_hits, download_days, date and published more or less, right?
Since I don't see anything else really used, not in the list of the downloads for frontend, nor backend. My ZIP file is simple there:
Code:
insert INTO #_phocacart_order_downloads (`order_id`, `product_id`, `attribute_id`, `option_id`, `order_product_id`, `order_attribute_id`, `order_option_id`, `title`, `alias`, `download_token`, `download_folder`, `download_file`, `download_hits`, `download_days`, `checked_out`, `checked_out_time`, `type`, `ordering`, `date`, `published`)SELECT `order_id`, 0, 0, 0, 0, 0, 0, 'Order 136 ZIP', '', `download_token`, 'AZFCoH3du2OQ8biW7', 'AZFCoH3du2OQ8biW7/secret order136.zip', `download_hits`, `download_days`, `checked_out`, `checked_out_time`, `type`, `ordering`, `date`, `published`FROM `#_phocacart_order_downloads` WHERE order_id = 136 and published = 1 limit 1;
It's obvious that those who would also like to use the code I've written, need to be aware of the consequences.
But I don't see other problems with core functionality and security since we copy all that and they're all the same for one particular order (right after being created). (I know the download token isn't, but you only need one secret token and it's only verified back the moment a guest downloads the ZIP in this case, right?)
Or do you have a better solution?
Or are you saying Phoca Cart is not a solution for that kind of shop?
Statistics: Posted by lpatrick — 29 Apr 2024, 13:24