I am trying to set a custom root dir in nginx, and whilst it does seem to point to the correct directory (confirmed in error logs - directory index of /var/www/mysite.com/web/current/ forbidden). I cannot get php to work now. Any call to a php file in the custom root gives a 404. Custom nginx directive: Code: location / { root /var/www/mysite.com/web/current; try_files $uri $uri/ /index.php?$query_string; } Full vhost: Code: server { listen :80; server_name mysite.com root /var/www/mysite.com/web; index index.html index.htm index.php index.cgi index.pl index.xhtml; error_log /var/log/ispconfig/httpd/mysite.com/error.log; access_log /var/log/ispconfig/httpd/mysite.com/access.log combined; location ~ /\. { deny all; access_log off; log_not_found off; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location /stats { index index.html index.php; auth_basic "Members Only"; auth_basic_user_file /var/www/clients/client4/web20/web/stats/.htpasswd_stats; } location ^~ /awstats-icon { alias /usr/share/awstats/icon; } location ~ \.php$ { try_files /83de04d5fddbde55e5722b580f030eb5.htm @php; } location @php { try_files $uri =404; include /etc/nginx/fastcgi_params; fastcgi_pass 127.0.0.1:9029; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_intercept_errors on; } location / { root /var/www/mysite.com/web/current; index index.php; try_files $uri $uri/ /index.php?$query_string; }
If I try http://mysite.com/current/ the page does load. so it appears the new root is having issues with php or similar. Am I missing something, do I need to redefine the @php section?
I tried puting a custom php section in, but nginx complains that its already defined in the vhosts, automatically generated by ISPconfig, so I cannot remove this one.
you can merge locations like this: Code: location @php { ##merge## root /var/www/mysite.com/web/current; }
That's awesome, I had no idea that things would be 'merged' that way — or, rather, at least on the current version I'm running (I'm posting after 3 years!), 'our' @php block on the website Options tab will supercede the one on the ISPConfig template. But it's the same thing. The important issue is being able to fine-tune each website by itself, without manually editing files that might get overwritten on future versions of ISPConfig