Ubuntu 11.10 ISPC 3.0.4.1 Nginx 1.0.10 Zen Cart 1.3.9h - php cart software. BIG problems with a login page - it just kept redirecting until it threw a "too many redirects" error. Well, after 18 hours (no joke!) of going round and round in circles, with a little help from the developer of Zen Cart we spotted something: For a script called, for example, phpinf0.php we get _SERVER["PHP_SELF"] /phpinf0.php/phpinf0.php which is clearly wrong and breaks certain scripts. Finally, I ended up at http://forum.nginx.org/read.php?11,212439,212439#msg-212439 locojohn's server setup is different to mine, and I am using ISPConfig so I have worker pools for php-fpm, so this is what I did: In /etc/nginx/fastcgi_params , comment out the line fastcgi_param SCRIPT_NAME $fastcgi_script_name; - that made Zen cart login work! But... it broke phpmyadmin. So, my phpmyadmin block now looks like this PHP: location /phpmyadmin { root /usr/share/; index index.php index.html index.htm; location ~ ^/phpmyadmin/(.+\.php)$ { try_files $uri =404; root /usr/share/; include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_NAME $fastcgi_script_name; # THIS is what needs adding # .... rest of file etc I don't know of any way of "unsetting" a server var/param once it's been set, because obviously, it would be better to REMOVE it from the one place it's causing trouble with the old script and leave the master config untouched, rather than delete it from the master file and have to add it back to various other locations "just in case". Any ideas? This is noted in php bugs at https://bugs.php.net/bug.php?id=55208 but nothing has really been done since 2011-07-17 and as they're discussing 5.3.6 and I'm on 5.3.8, I guess it hadn't been resolved. However, it HAS taken up my entire weekend, so I'll be putting some effort into waking the bug report up a bit!
Has anyone got any ideas on this? This is truly becoming a PITA, as I have to gone in and re-add fastcgi_param SCRIPT_NAME $fastcgi_script_name; back into apps.vhost under the phpmyadmin section every time I want to use it. Of course, I suppose a better solution would be to "unset" the troublesome fastcgi_param SCRIPT_NAME $fastcgi_script_name; in the nginx block for the "old" script for which is causes trouble, in the ISPC admin interface, but as you can see, this post is a few weeks old and despite occasional googling, I've not found a way of "unsetting" a fastcgi param. Although I'd have a play with obvious things like " " and "" and just a blank space - it doesn't complain, but it doesn't do the trick either! (Even better would be if php fixed that bug, but it's been a LONG time now!)
I got the same problem I you comment fastcgi_param SCRIPT_NAME $fastcgi_script_name; you willl fix that redirection but in the phpmyadmin it ill redircto to / instead /phpmyadmin when login in. I think the solution is to change the template of the vhost creation for the php entries location ~ \.php$ { try_files $uri =404; include /etc/nginx/fastcgi_params; fastcgi_pass 127.0.0.1:9059; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_intercept_errors on; } I think this line: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; should be fastcgi_param SCRIPT_FILENAME $fastcgi_script_name; or something like that
well that will not fix it. I guess we should comment that line in fastcfig_params and then if a vhost got problem set: fastcgi_param SCRIPT_NAME $fastcgi_script_name; on the vhost cfg file. lame
