September 14, 2011 at 8:36 am #4313
I’m getting “Download file cannot be opened. Please let us know. Thank you!” after purchasing a digital download. I’ve found other posts on this subject in the forum but no answers.
I have a clean install of WordPress and an up-to-date eStore plugin (purchased yesterday). I have not modified any files or styled up the site yet. So don’t understand why I’m getting this error.
All works well up until the download page and email. The links just do not work.
Essentially, what I need to do is to offer free downloads of high resolution images for those who give details of where the images will be used (Site will be for a PR company).
Eventually I will need to turn off the ‘large image link’ on the thumbnails and customise the forms and cart etc if possible but for now just need to get the basic function working.
I’ve tried it on small files and it still doesn’t work.
Site is in a folder on my testing server at the moment, not a subdomain- http://22.214.171.124/longthorn.org.uk/pmd/
ThanksSeptember 14, 2011 at 8:41 am #36607
I tired this too by the way…
WP eStore -> Settings -> Addon Settings -> Download Manager Related Settings -> Automatic URL Conversion Preference -> Do Not Convert
That doesn’t work either.September 14, 2011 at 8:51 am #36608adminKeymaster
Did you try this?
Also, make sure to check this checklist and correct any mistake:September 14, 2011 at 10:19 am #36609
Thanks. Just tried all 8 methods.
1-6 – Still get “Download file cannot be opened. Please let us know. Thank you!” 3 and 4 were slower but same result.
7 – Tried a couple of times but if anything’s happening it’s very very slow. Waited almost minutes on 2nd try then gave up.
8 – Nothing at all! Just a blank screen when I click link.
Just to clarify, these are not huge files. The samples I’m trying are under 2Mb. I can’t see my files ever being over 5Mb as they are jpgs.
Any ideas?September 14, 2011 at 10:39 am #36610
Please enable the debug logs, try again, and report the contents of the debug_manager_debug.log file.September 14, 2011 at 10:58 am #36611
[09/14/2011 10:53 AM] – Status : Unresolved DL file path = http://126.96.36.199/longthorn.org.uk/pmd/wp-content/gallery/walk-in-wardrobes/meadowfield-10.jpg
[09/14/2011 10:53 AM] – Status : Resolved DL file path = http://188.8.131.52/longthorn.org.uk/pmd/wp-content/gallery/walk-in-wardrobes/meadowfield-10.jpg
[09/14/2011 10:53 AM] – Advisory : No DL file path conversion performed on URL.
[09/14/2011 10:53 AM] – Status : Dispatching DL method = 1
[09/14/2011 10:53 AM] – FAILURE : Error on fopen(‘http://184.108.40.206/longthorn.org.uk/pmd/wp-content/gallery/walk-in-wardrobes/meadowfield-10.jpg’)
BTW if you put that path into a web browser it can find it immediately. Is there anything else you need to see? The other logs don’t have much in them.September 14, 2011 at 11:33 am #36612
What version of PHP are you using?September 14, 2011 at 11:35 am #36613
5.3September 14, 2011 at 11:44 am #36614
Try setting the URL conversion preference to “Relative” and try again. Also, by any chance, are you running in PHP Safe Mode?September 14, 2011 at 11:46 am #36615
The reason why it isn’t working now, is that the PHP allow_url_fopen option is disabled, usually because PHP is in Safe Mode.September 14, 2011 at 12:08 pm #36616
That worked. Many thanks!!September 14, 2011 at 12:11 pm #36617
Going to “Relative” or turning off PHP Safe Mode?September 14, 2011 at 12:14 pm #36618
Going relative. I wouldn’t know how to turn off PHP safe mode if i needed to so I’m glad it’s not that!!September 14, 2011 at 12:20 pm #36619
Could you explain briefly what ‘relative’ does to the URL as opposed to ‘do not convert’?September 14, 2011 at 12:46 pm #36620
In the beginning, of PHP, only local filesystem paths could be accepted by fopen(). Later, the use of “URL wrappers” was added, so that full http:// paths could be used with fopen().
But because of abuses perpetuated by hackers, PHP Safe Mode was added; which allows you to turn off URL wrappers. If Safe Mode is active, then “Do Not Convert” will fail every time.
So, that means, eStore has to “convert” an http:// file path back into a local filesystem path that can be used by fopen(). There are two ways of doing this; “Absolute” and “Relative.” In the majority of cases, “Absolute” works; that’s why it is the default. In a rare number of cases, usually due to the way you organize content on your server, it is necessary to adjust the way the conversion is calculated.
“Absolute” conversion uses the server’s document root directory as the reference point for the conversion. “Relative” uses the WordPress root directory as the reference point.
“Do Not Convert” will work if you have content that is hosted on other domains, but requires that URL wrappers be permitted, via the allow_url_fopen configuration option. “Absolute” and “Relative” will only work if the content is stored below your server’s document root.
The native Amazon S3 integration feature is unaffected by everything I just said.
- You must be logged in to reply to this topic.