No matter how I respond to this. I'm sure you will somehow manage to take offence, although none is intended.
MHulak:
the spaces dont make a difference.
You are wrong. Spaces DO make a difference.
MHulak:
it was working before with those spaces as well
I'm not going to argue with you, because if it somehow did work, it shouldn't have.
I will point you to a couple of references that I beleive you will get some great benefit from though.
Firstly, from the ZenCart FAQ file:
https://www.zen-cart.com/content.php?113-how-do-i-make-products-downloadable which states
"Download filenames should not use special characters, spaces, etc"
Next I will refer you to RFC 1738: (The stuff that the 'internet' is 'built' upon), which defines what the 'special characters' are, and how they should be dealt with.
You may or may not recognise the name of the author, but if you wish to have an arguement about this I suggest you take it up with him :)
--- extract from RFC 1738 -----
Network Working Group T. Berners-Lee Request for Comments: 1738 CERN
URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII,** and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded.** Unsafe: Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character "%" is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "", "^", "~", "[", "]", and "`". All unsafe characters must always be encoded within a URL. For example, the character "#" must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.
MHulak:
anyways, i have Filename: /wallpaper/2009_04_25_IMG_7615_ED.jpg as a test
this one still has the issue
I'm not trying to be difficult, but did you REALLY enter "/wallpaper/" as a
part of the filename ? Or was this simply a bad example.
As well as the space characters being illegal, the filename entered for
downloads should not contain a file path, as this would also
cause an error. In other words, you could have two different problems, either one of which will
produce the same error message.
Do you have ANY downloads that DO work? (I've tried several of your freebies, all give the same error).
When I went to test your downloads, I did so assuming that only "this one still has the issue".
I didn't expect to find they all have an issue.
I'm sorry if I appear to be pedantic, but computers are far more pedantic than I could ever be, and we
both tend to take whatever people type on their keyboard literally. As such, I tend to make the
same 'mistakes' as a computer will <g>. The difference is, unlike a computer, instead of simply producing an
error message I try to figure out what was actually meant. To do this I often need to ask some
pretty 'stupid' questions.
Anyway, before going further could I please ask you to create just one download item without spaces,
and without a possible "/wallpaper/" as a part of the filename. Whether it has worked ok with these before
or not is of no consequence. I'm not asking/expecting you to update all of them, just one.
The idea is to start out with things that we know will work, rather than what could work,
or what has worked in the past. If you still get permissions problems we can investigate further, but
without this groundwork we could just be going around and around in circles.
Cheers
Rod
NOTE: We are sorry that Rod is no longer with us.
We are grateful for all his contributions to the Zen Cart community.
Ozpost - The Ultimate Shipping module for Australian Merchants. Click these links for its Homepage, or Download from Zen-Cart.com.