I've about driven myself crazy with this. I used the uberinstaller to install Drupal and Ubercart about a week ago on a site I'm working on. I did the same on a different server (different host) about a month ago, and all worked well, but not this time. It appears that the installs are slightly different versions, but as far as I can tell, they are set up the same. All of the modules are installed and active (imagecache, clean urls, imagefield (CCK)) but I cannot upload images. When I try, it goes through the process and acts like it uploads the images, but it does not. I don't get any errors, and there is nothing in my log entries that is suspicious. My files directory has appropriate permissions, my file system settings are correct... I'm completely stumped.
does anyone have ANY idea what could be going on here? any idea of other settings I could check? I'm at a total loss.
Are you using the public files method or the private?
What happens when you try to upload? The files actually don't get put to the server? If that's the case, are you sure the folder's location is correct, and chmodded to 766? (Try 777 for the hell of it).
Maybe the problem is that the file is owned by a different user and so you're getting file permission errors?
Does Watchdog show any logs that are helpful? (/admin/logs/watchdog)
If the files do get uploaded but they don't show up in your templates, then that's a paths issue.
It appears the files don't get put to the server. I already tried 777, and it still doesn't work. I don't get any errors. There is no error info in the logs. When I attempt to upload the image, it appears to work, but there is no image. I couldn't imagine it being an owner problem.
I had an issue getting Clean URLs to work, but I solved that with .htaccess. Otherwise, everything appears to be working just fine. I've looked on the server to see if there are any files, but there aren't. When I look at the status report, all is well.
Here's a possibility: I originally installed this on a different server using the Uberinstaller. I used the Uberinstaller a few weeks later to install it on the current server. Some of the version numbers of the modules had changed slightly, and I used modified modules from the older versions on the new site. Could that be causing the problem?
Well, I just uninstalled everything and reinstalled. Using the Ubercart Deluxe installation package without any custom modifications, I still cannot upload images. No error messages. What could I possibly be overlooking here?
Okay, so this is in the node edit form for a product? And you're trying to upload a file for the product image?
I can't upload images anywhere. I've tried it in the Category node and the Product node. With the Product node, I get the diagonal "loading" bars when I hit upload, then it flickers and there is nothing. The server is running FreeBSD. Are there any known problems with that?
Hmm, not that I'm aware of. But it does sound to me like an issue on the server somewhere. Do you have access to the server error logs? Perhaps you can contact someone at tech support, describe the issue, and ask them what could be causing it. It might be something simple they can fix on their end.
In the meantime, you might also try the upload using Firefox and two web developer plugins: Firefox, and Live HTTP Headers. Have those two open when you try to make an upload. If anything pops up, such as a "Permission denied" error (which is what I think this is) it will tell you a little more information as to what's happening behind the scenes.
You can scroll through the log and copy and paste it here if you need help, if you can't figure it out based on what it tells you (if it tells you anything helpful, of course, which it might).
OK, I'll give that a try tonight. Thank you for your input!
Looks like I may have found the problem in the error logs
[13/Aug/2008:22:05:07 +0000] [error] [client ] mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions MaxRedirects' to increase the limit if neccessary.
I assume this would be in the .htaccess file?
I wouldn't change MaxRedirects, I'd figure out where the problem was. Sounds like you have an infinite loop here - maybe your symbolic links are messed up, or you have some rewrite rules fighting each other in your .htaccess, or you have conflicting aliases, etc. Not something that should show up in a clean install - this is probably related to something you did on your server.
The only thing I did on my server was activate mod_rewrite in the .htaccess file. That shouldn't be causing the problem, should it?
Did you leave the imagecache module on version 1.X or did you upgrade it to version 2.X ? (as far as I understand, Ubercart requires version 1.X)
I didn't upgrade any modules. Imagecache is version 1.5.
You shouldn't have had to edit the .htaccess file... you said you turned on Clean URLs right? Doing so should have made aliases work automatically. Did you not have the proper (server) permissions to modify that file?
The host my client uses (Verio) requires any server modifications to be made through .htaccess files and the like. I cannot make modifications to the server files like httpd.conf. I had to turn on mod_rewrite in the .htaccess file to get the Clean URLs to work. It did not work without that modification.
Hmm, maybe that's a limitation then. Is the client's site in a subfolder, or at a top-level domain? In other words, is it www.example.com or www.example.com/client? Some hosts do that and in cases like those I think you do have to edit the rewrite rules to account for that.
Not sure what else it could be at this point except for permissions having to do with either the folders themselves, or the "owner" - in other words, since this is shared hosting, perhaps they haven't given the "user" that Drupal uses the correct permissions? In most cases with Dedicated servers, the apache user (the "owner") is apache, or root. You can see who owns a file or folder by typing ls -l in the command line, if you have Shell (SSH) access.
Were you able to contact anyone at a tech support position? Different hosts set things differently and allow different server parameters, such as magic quotes and safe mode. Maybe its a permissions issue with the tmp file? Maybe the tmp director doesn't exist? Usually it's /usr/tmp, or just /tmp, and sometimes that folder doesn't exist or can't be read to / written from. Doubly so on shared hosting. It could be an open_basedir restriction. The only way would be to check the logs and see if this message is there - although I'm surprised to learn that there's nothing even in Watchdog about it.
The domain is a top-level domain. I changed the tmp directory so that it wasn't in the root just to see if that was the issue, and it still didn't work. I haven't heard back from the tech guys yet. Hopefully soon. I'll check the owner stuff in a bit. The only error that was in the error logs is the one I pasted above.
Here is the content from Live HTTP Headers
http://www.my-domain.com/imagefield/js
POST /imagefield/js HTTP/1.1
Host: www.my-domain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: Cookie:">http://www.my-domain.com/node/add/product
Cookie: SESS705fd597b353e8d5b130ed99e77ca768=839073a58fd3c5bb7bb65240e50be58a; SESS6992681bb8afe63da7fa9286d18a3d05=02c95ac327c74b7baf9c7f008f14565d
Content-Type: multipart/form-data; boundary=---------------------------72956569542
Content-Length: 60011
-----------------------------72956569542
Content-Disposition: form-data; name="title"
-----------------------------72956569542
Content-Disposition: form-data; name="body"
-----------------------------72956569542
Content-Disposition: form-data; name="format"
1
-----------------------------72956569542
Content-Disposition: form-data; name="files[field_image_cache_upload]"; filename="CMV_66_EBONY_38.jpg"
Content-Type: image/jpeg
ÿØÿÃ
HTTP/1.x 200 OK
Date: Sun, 17 Aug 2008 00:40:53 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 mod_ssl/2.8.28 OpenSSL/0.9.7m
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-Powered-By: PHP/5.2.6
Last-Modified: Sun, 17 Aug 2008 00:40:54 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Does anything look hokey?
No, everything looks fine. You get an HTTP 200 OK which I guess is just the reloading of the page.. hmm.
At this point I'm not too sure. I'd still recommend talking to someone in tech support, my guess is that it's a permissions issue.
I got a reply from tech support, and he said that they couldn't support a 3rd party app. He did offer the following:
So I Googled for the error... and found a few posts addressing this problem.
The fix is with the .htaccess file in the root directory of of your Drupal installation. Now the FIX is to find this line:
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
And replace it with this line RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]
The whole internal server error is caused by a single forwardslash (/).
Links from the Drupal forums which point out how to solve the "maximum number of internal redirects" error.
mod_rewrite error
Drupal 4.5 RC - SAFE MODE Restriction in effect.
However, when I changed that line in the .htaccess, it didn't make any difference. I've also deleted everything and manually installed everything instead of using the Uberinstaller, but no change.
One question I have is this: In the Live HTTP Headers output, the first line says http://www.my-domain.com/imagefield/js. There is no /imagefield directory. Should there be?
No, the path is an internal module's path, that is served up by the .htaccess files. That appears to be working correctly.
And the tech support's links look like they are talking about Drupal 4.5, but you're running Drupal 5, correct?
What version of Imagefield are you using? What version of CCK? Are they the latest versions?
Yep. Drupal 5. Imagefield is 2.1, but CCK is 1.7. Imagecache is 1.5.
Hmm I'm still running Imagefield 1.1 on my production site. I wonder if it's a bug in that module? Try reverting to an older version and see if that has any effect. I recently had an issue with the latest CCK and had to roll back a few minor versions, because I was unable to add new fields to any node type.
Rolled it back to 1.1. Nothing. I'm beginning to think it's hopeless.
Hmm, well I don't think it's hopeless, but it's definitely a pickle. Are you married to that host? 
I've installed Drupal systems on GoDaddy, SoftLayer, AnHosting, Network Solutions, Cari.net, and DreamHost - and never had the issues you're describing. Would you mind giving it another shot - but installing all the modules 1 at a time? I know you said you'd used the UberInstaller - has that been the case each time? Sometimes there are bugs in the installer, but I'm pretty sure it's usually kept up-to-date with the current Ubercart releases...
But again I'm fairly certain that it's an issue with imagefield.
Are you able to upload file attachments? Say you want to attach a PDF to a node - can you do that? Or does the upload function not work for anything? If so then it's gotta be a permissions upload. (Speaking of permissions, do you have the User access permissions configured correctly?
Sometimes there are several steps in getting everything setup to work right... something you have to try a couple times to get down.
It turns out that it was a configuration problem. The tech support guys finally came through and told me I needed to set an upload_tmp_dir in my php.ini file. Thank you for all of your advice!
