| 8:02 pm on Oct 7, 2011 (gmt 0)|
Do you have any further information as to what actually happens when they "cannot upload a picture"? Times out? Any errors reported? Any errors logged? Is the form actually submitted? Does the file get to the server, but fails in moving/processing the image?
| 8:15 pm on Oct 7, 2011 (gmt 0)|
I know, it would be helpful, but users are horrible at giving any good info. And in this particular situation, since it always works when I try it, I never get any more info from them.
I should dig through the logs for errors.
| 8:24 pm on Oct 7, 2011 (gmt 0)|
I THINK the page processes as expected but they just don't see the image upon returning to the page (and the file, as far as I know, does not exist on the server). I do not think they get a white PHP error page or a timeout.
| 6:09 pm on Oct 9, 2011 (gmt 0)|
Might be caching issue. Profile image, so I'm guessing you're overwriting an image in the same location with the same name?
Two ways I know of to resolve it (assuming of course it is a caching issue). First is to append ?t=<?php echo time(); ?> into the img src. The other is to pass the image through a PHP script, and point the img src at that php script. Then you can pass a no-cache header.
| 4:20 am on Oct 10, 2011 (gmt 0)|
It's not a caching issue. When I first pulled up the profile it had the non-custom (clipart) image on the profile. I hadn't viewed the profile before this. Then I upload and boom the image is there. The pages are set to expire, as well; so that hasn't been an issue for years (site is 7 years old).
It's a mystery, for sure.
| 7:43 am on Oct 10, 2011 (gmt 0)|
Could the site be experiencing heavy traffic at the time? What if several users upload a profile image at the same time?
| 7:44 am on Oct 10, 2011 (gmt 0)|
If you upload the exact same image bit-for-bit I think it might be a client-specific issue. Do you have an HTTP error log? Whenever someone hits a 403 or other error response it gets logged on my site and includes information so I can analyze it and see if it was something on my part or if they were up to no good for whatever reason. There is also the possibility that their computer(s) could be having problems such as a virus so you could ask them to attempt to upload it from another computer on the same internet connection and if it still fails I would ask them if they could try uploading from a different location.
| 5:09 pm on Oct 10, 2011 (gmt 0)|
Another thing to consider and is 100% possible - when someone emails you a file, your email client encodes the data to some standard algo. So for example if someone sends you a file that has some unsupported feature, like an extra photoshop layer saved in a .gif or .png, it can basically filter it out. So you may not actually be seeing the problem when you upload their file.
|but users are horrible at giving any good info. |
Which is really your cue for doing it for them. :-) A corollary to your comment, it's even more difficult to work with them to step through, although you SAY "click this button" they may be doing something else, or somehow navigating to a completely different page. You can distrust their comments, but you MUST distrust their actions. :-)
I've always found error logs, or any server logs in general, cryptic at best when I want to know specific bits of info. Every good script will have error trapping, and for critical user input such as file uploads, when you REALLY want to know what they are up to, is an excellent place to use a custom logging function.
FYI, it's not just PHP. I had the same issues with a client years ago that had a huge Perl based real estate site. It wasn't until I started logging everything input into this system it all became clear. I can't remember the specifics of the errors - probably something like spaces or dots in the file name (which really hoses you up if you're validating by extensions) and in once case a .bmp extension uploaded as a .jpg.
The biggest advantage to custom logging is you can use it to improve your setup, it will reveal things you hadn't thought of. You can specify exactly what info you want in your logs, from the user's uploaded path to any cleansing and conversion of file names you might be doing. You can even record the process id of the upload to check it later against those cryptic server logs. :-)
It's not that difficult . . . create a location off the root of your server and append to a file. I set mine up so if they reach 100K, it overwrites the file (big files get difficult to work with in plain text editors.)
| 7:10 pm on Oct 10, 2011 (gmt 0)|
There is a PHP log and I did go over it for the day in question. I didn't see anything.
I have had the .bmp/.jpg issue before, and it's usually what we expect when they say it doesn't work.
This case is the first time that my support staff has attempted the upload and it hasn't worked (when the file wasn't some other format, or "corrupted" - according to PS).
I like your thoughts about email clients. That could very well be something I'm experiencing.
| 7:23 pm on Oct 10, 2011 (gmt 0)|
What program is doing the uploading and resizing ?
I had a problem with ImageMagick on my site occasionally crashing with certain files. If I changed the file slightly (by saving it at 99% quality) then the upload worked fine. It was a bug with ImageMagick and was fixed by uploading to the latest version from source.
| 7:25 pm on Oct 10, 2011 (gmt 0)|
Standard PHP upload/resize.
| 7:55 pm on Oct 10, 2011 (gmt 0)|
PHP will be using some program under the covers to do the resizing (possibly libgd). It might be worth investigating if there are any known bugs with the version you are running. [php.net...]
| 4:04 pm on Oct 11, 2011 (gmt 0)|
Well, sometimes something "just won't work" yet won't generate an error. One example is checking the existence of the file after upload, if you custom log the entire process you can see the precise steps and exactly where it stops.
I remembered one of the issues. My scenario was to re-save all the files using the user's file name (and fixing it, removing spaces, etc.), and it started out splitting off the extension for re-use on upload.
Mac files never used to have extensions <facepalm moment>. Once logged, it was plain as day because part of the logging was to gather as much info about the user as possible - IE 5.0 for Mac <shudder>.