Tips and Tricks HQ Support Portal › Forums › WP eStore Forum › WP eStore F.A.Q/Instructions › WP eStore Download Methods – Change Encrypted Download Methods
- This topic has 23 replies, 8 voices, and was last updated 8 years, 4 months ago by wzp.
-
AuthorPosts
-
September 3, 2013 at 12:32 am #24227wzpModerator
Bingo… “Interesting to note that when I use Safari web browser I can see a message that says: Compression Failed”
https://support.tipsandtricks-hq.com/forums/topic/encrypted-links-not-downloading-in-ie8
BTW, how big is the ZIP file?
September 3, 2013 at 1:03 am #24228dhellisSpectatorThe zip file is about 32 megs. I normally use Firefox but used Safari to eliminate the possibility of things being stuck in FF cache. I have had others try to down load the file and one gets an error stating that the file is either an unknown format, or is corrupt. He is using IE on Windows Vista.
September 3, 2013 at 1:38 am #24229wzpModeratorAnd I’m presuming this is perhaps one of the largest files you’ve tried to offer? How long does it “seem” to be downloading, before it stops?
You may have to use Amazon S3 Integration.
https://support.tipsandtricks-hq.com/forums/topic/broken-zip-file
September 3, 2013 at 2:37 am #24230dhellisSpectatorIt might be one of the larger files, though I do have some that are larger. This file contains 5 different PDF files, I have several that are over 50 megs.
No, I have not tried S3 but as mentioned I did move it to a ‘Public’ folder on Dropbox then changed the download link. I get the same problem when generating the encrypted link but if I use the actual link to the file it downloads.
The file appears to download in about 3 seconds, though is 0 length so not working.
Here is a newly generated link, it will expire in 72 hours or 10 attempts
[http://www.coinslots.com/wordpress/wp-content/plugins/wp-cart-for-digital-products/download.php?file=2VvX%2FikEWvWXgKXpgA%3D%3D]
September 3, 2013 at 1:04 pm #24231wzpModeratorIt’s important to realize, unless you use Amazon S3 integration, that when you externally host a file on any other site besides your own; you are **DOUBLING** the bandwidth usage of your server. That’s because the file must first be read (pulled) from the external site and then sent (pushed) to the user’s browser.
Obviously, 3 seconds is too short. If you followed all the advice given in the other threads; you should have also enabled the eStore debug logs, and checked to make sure there are no errors in the download_manager_debug.log file.
If the log file **seems** to think that no errors occurred, although the reality is different, it is indicative of an HTTP session timeout issue. If that is the case, then using the eStore Amazon S3 integration feature is really your only option.
September 3, 2013 at 4:16 pm #24232dhellisSpectatorThanks, I had enabled the logs this is what the log says that it was unable to resolve the path for the www address but did resolve for the real link (/home2/coinslot/…….
OK so I guess that means I need try Amazon S3,
September 3, 2013 at 10:50 pm #24233wzpModeratorYep.
July 25, 2016 at 5:10 pm #24234FEON14MemberFixing “Part could not be saved, because the source file could not be read” Also, “Page not found” conundrum.
I’m not certain I’m putting this in the right thread, but this is about what worked for me re the above issues.
My website is currently selling my partner’s music and also a book I’ve written. They are all downloads, MP3s, PDF, EPUB and ZIP. The ZIP files are the complete music albums and the largest is 63mb.
In running tests for the downloads I found the MP3s and PDF files presented no major problem. But with downloads of the larger ZIP files there were issues.
The biggest stumbling block was repeatedly receiving the alert that the “Part could not be saved, because the source file could not be read.”
It seems a lot of people think this “Part could not be saved…” is a Firefox issue, or an issue with security on one’s machine. I fell into believing that too – and spent a fair amount of time making adjustments with no improvement.
I also discovered the same alert was happening across different browers and also on different machines.
Meanwhile I never experienced any issues downloading a ZIP file straight from the website. It was only happening when pulling it through WP eStore.
The fix
So anyhow, after a long trawl the fix I’ve found that works is a simple one as follows:
- In the eStore settings, under Advanced Settings, I had, almost from the bat, switched on Enable Alternate Redirection Method.
This was initially a tryout to see if it made a difference – it did. When I took this back off I was getting “Page not found” on testing (through the Admin Functions – very useful testbed) any of the downloadable files; so I switched it back on again.
I also discovered, when this was left on, a customer could actually download the smallest ZIP file of just under 40 mb while the two larger files still attracted the “Part could not be saved, because the source file could not be read” alert.
- I took advantage of a post in the forum suggesting trying out the Download Method under Addon Settings for larger files. And hey presto, I found Method 6 worked for me – when nothing else would.
- From suggestions in the WP eStore forum I also earlier changed my .htaccess permissions from 644 to 755. This may have helped to resolve the situation but I didn’t see it in any immediate sense.
July 25, 2016 at 6:28 pm #24235wzpModeratorUsing the native Amazon S3 also works:
Sometimes, it is more productive, to stop trying to out-think the behavior of low end hosting packages.
Please read the following post so you understand a few things:
https://www.tipsandtricks-hq.com/ecommerce/selling-large-files-with-wp-estore-796
- In the eStore settings, under Advanced Settings, I had, almost from the bat, switched on Enable Alternate Redirection Method.
-
AuthorPosts
- You must be logged in to reply to this topic.