Homepage funziona ma tutti i permalink danno 404 con nginx e PHP-FPM
Sto cercando di risolvere uno strano problema con la mia configurazione nginx, che sembra aver smesso di funzionare dopo un aggiornamento dei backports Debian.
La pagina principale del mio blog (http://blog.balaji-dutt.name/) funziona perfettamente, ma cliccando su qualsiasi altro permalink (Esempio 1, Esempio 2) ottengo un errore 404 di nginx.
Ecco la mia configurazione, che ora è praticamente la configurazione standard del Codex:
server {
listen 80;
server_name blog.balaji-dutt.name;
error_log /var/log/nginx/blog-error.log;
access_log /var/log/nginx/blog-access.log combined;
## Percorso root
root /var/www/wordpress;
## Questo dovrebbe essere nel blocco http e se c'è, non serve qui
index index.php;
#Gzip
include /etc/nginx/sites-available/gzip.conf;
location / {
# Ottimo perché il PHP non viene toccato per i contenuti statici
# include "?$args" così i permalink non standard non si rompono con le query string
try_files $uri $uri/ /index.php?$args;
}
# nega l'accesso ai file .htaccess, se la root document di Apache
# coincide con quella di nginx
location ~ /\.ht {
deny all;
access_log off;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#fastcgi_intercept_errors on;
fastcgi_pass 127.0.0.1:9010;
}
}
Questo è ciò che vedo nel log degli errori di nginx quando provo ad accedere a un permalink (http://blog.balaji-dutt.name/about/):
2014/10/19 03:35:09 [error] 21698#0: *76739 "/var/www/wordpress/about/index.php" is not found (2: No such file or directory), client: 174.36.241.151, server: blog.balaji-dutt.name, request: "GET /about/ HTTP/1.1", host: "blog.balaji-dutt.name", referrer: "http://blog.balaji-dutt.name/"
Sembra che nginx non stia leggendo la direttiva location per i file .php, ma non sono riuscito a capire il motivo. Ogni suggerimento o aiuto è ben accetto!
Aggiornamento 1 - 20 Ott 2014
Elenco delle directory nella root nginx:
# ls -la /var/www/wordpress
total 256
drwxr-xr-x 5 blog www-data 4096 Sep 28 03:09 .
drwxr-xr-x 8 www-data www-data 4096 Jan 15 2014 ..
-rw-r--r-- 1 blog www-data 418 Sep 25 2013 index.php
-rw-r--r-- 1 blog www-data 19930 May 16 22:23 license.txt
-rw-r--r-- 1 blog www-data 1764 Oct 5 01:17 nginx.conf
-rw-r--r-- 1 blog www-data 7192 Sep 28 03:09 readme.html
-rw-r--r-- 1 blog www-data 55174 Mar 27 2014 sitemap.backup.xml
-rw-r--r-- 1 blog www-data 7125 Mar 27 2014 sitemap.backup.xml.gz
-rw-r--r-- 1 blog www-data 4951 Sep 28 03:09 wp-activate.php
drwxr-xr-x 9 blog www-data 4096 Dec 12 2013 wp-admin
-rw-r--r-- 1 blog www-data 271 Jan 8 2012 wp-blog-header.php
-rw-r--r-- 1 blog www-data 4946 Sep 28 03:09 wp-comments-post.php
-rw-r--r-- 1 blog www-data 2746 Sep 28 03:09 wp-config-sample.php
-rw-r--r-- 1 blog www-data 237 Dec 22 2013 wp-config.php
drwxr-x--- 9 blog www-data 4096 Sep 28 03:09 wp-content
-rw-r--r-- 1 blog www-data 2956 Sep 28 03:09 wp-cron.php
drwxr-xr-x 12 blog www-data 4096 Sep 28 03:09 wp-includes
-rw-r--r-- 1 blog www-data 2380 Oct 24 2013 wp-links-opml.php
-rw-r--r-- 1 blog www-data 2714 Sep 28 03:09 wp-load.php
-rw-r--r-- 1 blog www-data 33043 Sep 28 03:09 wp-login.php
-rw-r--r-- 1 blog www-data 8252 Sep 28 03:09 wp-mail.php
-rw-r--r-- 1 blog www-data 11115 Sep 28 03:09 wp-settings.php
-rw-r--r-- 1 blog www-data 26256 Sep 28 03:09 wp-signup.php
-rw-r--r-- 1 blog www-data 4026 Oct 24 2013 wp-trackback.php
-rw-r--r-- 1 blog www-data 3032 May 16 22:23 xmlrpc.php
Quando provo ad accedere all'URL (http://blog.balaji-dutt.name/2013/481-nginx-apache-w3-total-cache-a-bad-combination/), ecco cosa appare nel log degli errori di nginx:
*14 "/var/www/wordpress/2013/481-nginx-apache-w3-total-cache-a-bad-combination/index.php" is not found (2: No such file or directory), client: 174.36.241.151, server: blog.balaji-dutt.name, request: "GET /2013/481-nginx-apache-w3-total-cache-a-bad-combination/ HTTP/1.1", host: "blog.balaji-dutt.name", referrer: "http://blog.balaji-dutt.name/"
Il percorso nel log degli errori è confuso, perché la parte dopo /var/www/wordpress/
è in realtà il permalink e non sono sicuro del motivo per cui viene aggiunto alla richiesta.
Aggiornamento 2 - 25 Ott 2014 [RISOLTO]
Si è scoperto che il file di configurazione nginx creato da W3 Total Cache per la cache Disk Enhanced rompe i permalink, ma poiché il file viene letto solo al riavvio di nginx, il sito funziona finché non si riavvia nginx. Risposta dettagliata e una configurazione funzionante pubblicata in questa risposta.

Si scopre che la configurazione di nginx che W3 Total Cache inserisce se la modalità Disk Enhanced è abilitata interromperà i permalink, ma solo se si riavvia nginx dopo che W3 Total Cache ha iniettato la configurazione per la modalità Disk Enhanced.
Sulla base del suggerimento di birgire, ho disattivato tutti i plugin e verificato il sito, che ha iniziato a funzionare correttamente. Poi ho riattivato W3 Total Cache e sorpresa! il sito ha continuato a funzionare correttamente. Ha continuato a funzionare correttamente fino a quando non ho riavviato nginx, momento in cui è stato caricato il file nginx.conf creato da W3 Total Cache e il sito si è rotto. Ciò che causa questo comportamento è la seguente riga:
if ($w3tc_rewrite = 1) {
rewrite .* "/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_rewrite$w3tc_ext" last;
}
Quando nginx viene riavviato, la riga sopra viene caricata e tutti gli URL vengono reindirizzati ai file HTML memorizzati nella cache in wp-content/cache/page_enhanced
. Al riavvio però, i file HTML vengono eliminati e quindi i link diventano 404. La soluzione che ho trovato è stata prima di cambiare i permessi sul file di configurazione nginx che W3 Total Cache normalmente sovrascrive in modo che non potesse essere modificato. Poi ho modificato la configurazione sopra:
location / {
rewrite ^(.*\/)?w3tc_rewrite_test/?$ $1?w3tc_rewrite_test=1 last;
if ($w3tc_rewrite = 1) {
rewrite .* "/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_rewrite$w3tc_ext" last;
}
try_files $uri $uri/ /index.php?$args;
}
La configurazione fa un paio di cose - la riga di rewrite originale è racchiusa in un blocco location in modo che, anche se il file HTML non viene trovato, si ripieghi su un normale modello di rendering index.php. Inoltre, la riga w3tc_rewrite_test
serve a eliminare un errore nella Dashboard. Sto facendo questo in un file separato per centralizzare la mia configurazione W3 TC, quindi ci sono due direttive location \
per il mio sito.
Per approfondire, si scopre che anche la configurazione nginx per il modulo minify di W3 Total Cache è rotta. Ecco una configurazione funzionante1:
#Test Rewrites
location ~ ^/wp-content/cache/minify/[^/]+/(w3tc.*)$ {
try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?w3tc_rewrite_test=$1;
}
#End Test Rewrites
# BEGIN W3TC Minify core
set $w3tc_enc "";
location ~ ^/wp-content/cache/minify/(.+/[X]+\.css)$ {
try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?test_file=$1;
}
location ~ ^/wp-content/cache/minify/(.+\.(css|js))$ {
try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?file=$1;
}
# END W3TC Minify core
Poiché molte informazioni su Wordpress/W3 Total Cache dipendono dalla versione, ecco le informazioni sulla versione per la configurazione sopra: W3 Total Cache v0.9.4 / Wordpress 4.0 / nginx 1.6.2-2~bpo70+1
1 https://rtcamp.com/wordpress-nginx/tutorials/single-site/w3-total-cache/

Non sono sicuro su qual è il modo migliore per procedere con il bounty. Qualche suggerimento?

Basta accettare la tua risposta come quella corretta. Vedi "Posso assegnare un bounty alla mia risposta?" http://meta.stackexchange.com/questions/16065/how-does-the-bounty-system-work

Puoi risolvere senza modificare il file di configurazione di w3 semplicemente aggiustando la tua regola di location/rewrite con try_files $uri $uri/ /index.php$is_args$args;
. Riferimento: http://wordpress.stackexchange.com/questions/98271/enable-minify-in-w3total-cache-using-nginx
