Pagina principală se încarcă, dar toate legăturile permanente returnează 404 pe nginx și PHP-FPM
Am încercat să rezolv o problemă ciudată cu configurația nginx, care pare să nu mai funcționeze corect după o actualizare Debian backports.
Pagina principală a blogului meu (http://blog.balaji-dutt.name/) funcționează normal, dar accesând orice altă legătură permanentă (Exemplul 1, Exemplul 2) primește o eroare 404 de la nginx.
Iată configurația mea, care acum este practic configurarea standard din 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;
## Calea către directorul rădăcină
root /var/www/wordpress;
## Acest parametru ar trebui să fie în blocul http, dacă este acolo, nu mai e nevoie aici
index index.php;
#Gzip
include /etc/nginx/sites-available/gzip.conf;
location / {
# Acest lucru este util pentru că conținutul static nu necesită PHP
# include secțiunea "?$args" pentru a nu afecta legăturile permanente non-standard
try_files $uri $uri/ /index.php?$args;
}
# blochează accesul la fișierele .htaccess
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;
}
}
Iată ce văd în jurnalul de erori nginx când încerc să accesez o legătură permanentă (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/"
Se pare că nginx nu interpretează corect directiva location pentru fișierele .php, dar nu am reușit să înțeleg de ce se întâmplă acest lucru. Orice sugestie sau ajutor este binevenit!
Actualizare 1 - 20 Octombrie 2014
Listare director pentru locația rădăcină 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
Când încerc să accesez URL-ul (http://blog.balaji-dutt.name/2013/481-nginx-apache-w3-total-cache-a-bad-combination/), iată ce apare în jurnalul de erori 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/"
Calea din jurnalul de erori este confuză, deoarece partea după /var/www/wordpress/
este de fapt legătura permanentă și nu sunt sigur de ce este adăugată la cerere.
Actualizare 2 - 25 Octombrie 2014 [REZOLVAT]
S-a dovedit că fișierul de configurare nginx creat de W3 Total Cache pentru caching Disk Enhanced poate strica legăturile permanente, dar deoarece fișierul este citit doar la reîncărcarea nginx, site-ul va funcționa până când reîncărcați/reporniți nginx. Răspuns detaliat și o configurație funcțională sunt postate în acest răspuns.

Se pare că configurația nginx pe care W3 Total Cache o inserează atunci când modul Disk Enhanced este activat va strica permalink-urile, dar numai dacă reporniți nginx după ce W3 Total Cache a injectat configurația pentru modul Disk Enhanced.
Bazându-mă pe sugestia lui birgire, am dezactivat toate plugin-urile și am verificat site-ul, care a început să funcționeze corect. Apoi am pornit W3 Total Cache și surpriză! site-ul a continuat să funcționeze corect. A continuat să funcționeze corect până când am repornit nginx, moment în care fișierul nginx.conf creat de W3 Total Cache a fost încărcat și site-ul s-a stricat. Ceea ce provoacă acest comportament este următoarea linie:
if ($w3tc_rewrite = 1) {
rewrite .* "/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_rewrite$w3tc_ext" last;
}
Când nginx este repornit, linia de mai sus este încărcată și toate URL-urile sunt redirecționate către fișierele HTML cache în wp-content/cache/page_enhanced
. Însă la repornire, fișierele HTML sunt șterse și astfel link-urile devin 404. Soluția pe care am găsit-o a fost mai întâi să schimb permisiunile pe fișierul de configurare nginx pe care W3 Total Cache îl scrie în mod normal, astfel încât să nu poată fi suprascris. Apoi am modificat configurația de mai sus:
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;
}
Configurația face câteva lucruri - linia originală de rewrite este încadrată într-un bloc de tip location, astfel încât chiar dacă fișierul HTML nu este găsit, se revine la un model obișnuit de randare index.php. În plus, linia w3tc_rewrite_test
este pentru a elimina o eroare din Panoul de administrare. Fac asta într-un fișier separat pentru a centraliza configurația W3 TC, așa că există două directive location \
pentru site-ul meu.
Pentru bonus, se pare că configurația nginx pentru modulul de minificare al W3 Total Cache este de asemenea defectă. Iată o configurație funcțională1:
#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
Deoarece multe informații despre WordPress/W3 Total Cache depind de versiune, iată informațiile despre versiune pentru configurația de mai sus: 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/

Nu sunt sigur care este cel mai bun mod de a proceda în privința recompensei. Aveți sugestii?

Pur și simplu acceptă răspunsul tău ca fiind răspunsul corect. Vezi "Pot să acord o recompensă propriului meu răspuns?" http://meta.stackexchange.com/questions/16065/how-does-the-bounty-system-work

Poți rezolva asta fără să modifici fișierul de configurare w3 prin simpla ajustare a regulii tale de location / rewrite la try_files $uri $uri/ /index.php$is_args$args;
. Referință: http://wordpress.stackexchange.com/questions/98271/enable-minify-in-w3total-cache-using-nginx
