Tips and Tricks HQ Support Portal › Forums › WP eStore Forum › "Download file cannot be opened. Please let us know. Thank you!"
Tagged: allow_url_fopen, downloads, estore, fopen
- This topic has 31 replies, 4 voices, and was last updated 11 years, 6 months ago by mankush.
September 14, 2011 at 1:01 pm #36621VanessaMember
Excellently explained. Many thanks for your help.September 14, 2011 at 6:10 pm #36622
My cart was working fine and great till yesterday.
Now it says:
“Download file cannot be opened. Please let us know. Thank you!”
While you can actually download the file if you just write the exact url as it appears in the “add/edit products”.
I have tried EVERY method possible (1- and every url convertion.
Also turned off PHP safe mode.
Customers are a-n-g-r-y.
Want to kill me with big knife. or gun.
Please advise as I think I`m going mental here : (September 14, 2011 at 6:59 pm #36623
What did you change since the day before “yesterday?”September 15, 2011 at 4:58 am #36624
Nothing. absolutely nothing!
Have also tried the tech support of godaddy [virtual server] and they didnt have a clueSeptember 15, 2011 at 5:09 am #36625
This is what it is writing in the debug
[09/15/2011 5:06 AM] – Advisory : Log file reset.
[09/15/2011 5:07 AM] – Status : Unresolved DL file path = here is the file name
[09/15/2011 5:07 AM] – Status : Resolved DL file path = here is the file name
[09/15/2011 5:07 AM] – Advisory : No DL file path conversion performed on URL.
[09/15/2011 5:07 AM] – Status : Dispatching DL method = 1
[09/15/2011 5:07 AM] – FAILURE : Error on fopen(‘here is the file name’)
here is the file name = working link that I cannot put here as a post
Any ideas?September 15, 2011 at 10:50 am #36626
If you’d like, please go to my contact form at TheAssurer.com/contact and paste your unredacted log file into the form. I can’t determine anything from what you just provided. Please include EVERYTHING (no editing) from the download_manager_debug.log file.September 15, 2011 at 1:23 pm #36627
Sending you now the file.
Thank you!September 15, 2011 at 1:35 pm #36628
I have reviewed your unredacted log file.
It seems that the “Relative” URL conversion is failing. Please change the URL conversion option back to “Absolute,” and try again.September 15, 2011 at 2:04 pm #36629
Have tried… Still not working…
Have sent you the log file again
Is there anything else I can do?September 15, 2011 at 2:22 pm #36630
What is apparently happening, is that your server is configured in such a way, that both the “Absolute” and “Relative” URL conversion methods are failing. See my explanation on the second page that explans the differences.
In each case, after the conversion fails, eStore tries to use the “Do Not Convert” option, which also fails. The reason it fails is because the “allow_url_fopen” option is not configured for your server…
What makes this interesting, is that usually “allow_url_fopen” is automatically disabled if the PHP Safe Mode is active. But eStore should issue a warning message in the log file if PHP Safe Mode is detected. This tells me that someone at your hosting provider made a conscious decision to disable the “allow_url_fopen” option.
The best advice, right now, is to ask/beg/threaten/sue/hack your hosting provider into enabling the “allow_url_fopen” option for you.September 15, 2011 at 2:26 pm #36631
Doing it now.
Thank you for all your time and effort : )September 15, 2011 at 2:29 pm #36632
P.S. What version of eStore are you running?
You can also try download method 7, but it will only work if the cURL library is installed.September 15, 2011 at 4:20 pm #36633
This is their answer:
Thank you for contacting Server Concierge. In regards to your server, dancehost:
We understand that you would like fopen enabled. We were able to verify that fopen is already installed and active on the server:
firstname.lastname@example.org [~]# php -i grep fopen
allow_url_fopen => On => On
Do you have any fresh ideas?September 15, 2011 at 4:37 pm #36634
You’ve got mail!September 15, 2011 at 6:19 pm #36635
Ok, I see what part of the problem is, maybe if you take care of this, everything will work again. I noticed that you have spaces in your folder and file names (on the server). For instance, you have a folder called: “BELLY DANCING”
Linux, which is the O/S of your server, really doesn’t like to see spaces in file names. There are ways to accommodate spaces, but there are too many ways in which they can be misinterpreted by either the user’s browser, WordPress, and the plugin.
1. Keep the URL conversion preferrence as “Absolute.”
2. Rename all folders and files, such that “BELLY DANCING” becomes “BELLY_DANCING”
3. Update the Product database with the corrected paths.
4. Try again.
It should work. As to “why” it was working the way you had it before, I haven’t a clue; luck I guess.
- You must be logged in to reply to this topic.