Schimbarea permalink-urilor cauzează erori 404 pe nginx
EDITARE
Se pare că am greșit încercând să editez .htaccess, deoarece nginx nu îl folosește. Ceea ce trebuie să fac de fapt este să editez fișierul meu .conf. Înainte să citesc asta, fișierul my_app.conf arăta așa:
upstream backend {
server unix:/u/apps/my_app/tmp/php.sock;
}
server {
listen 80 default;
root /u/apps/my_app/www;
index index.php;
access_log /u/apps/my_app/logs/access.log;
error_log /u/apps/my_app/logs/error.log;
location / {
try_files $uri $uri/ /index.php;
}
# Acest bloc de locație potrivește orice se termină în .php și îl trimite către
# socket-ul nostru PHP-FPM, definit în blocul upstream de mai sus.
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /u/apps/my_app/www$fastcgi_script_name;
include fastcgi_params;
}
# Acest bloc de locație este folosit pentru a vizualiza statisticile PHP-FPM
location ~ ^/(php_status|php_ping)$ {
fastcgi_pass backend;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include fastcgi_params;
allow 127.0.0.1;
deny all;
}
# Acest bloc de locație este folosit pentru a vizualiza statisticile nginx
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
Acum arată așa, și tot nu funcționează:
upstream backend {
server unix:/u/apps/my_app/tmp/php.sock;
}
server {
listen 80 default;
root /u/apps/my_app/www;
index index.php;
access_log /u/apps/my_app/logs/access.log;
error_log /u/apps/my_app/logs/error.log;
location / {
try_files $uri $uri/ /index.php;
}
location /wordpress/ {
try_files $uri $uri/ /index.php?$args;
}
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires max;
}
# Decomentați una din liniile de mai jos pentru plugin-ul de cache corespunzător (dacă este folosit).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Acest bloc de locație potrivește orice se termină în .php și îl trimite către
# socket-ul nostru PHP-FPM, definit în blocul upstream de mai sus.
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /u/apps/my_app/www$fastcgi_script_name;
include fastcgi_params;
}
# Acest bloc de locație este folosit pentru a vizualiza statisticile PHP-FPM
location ~ ^/(php_status|php_ping)$ {
fastcgi_pass backend;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include fastcgi_params;
allow 127.0.0.1;
deny all;
}
# Acest bloc de locație este folosit pentru a vizualiza statisticile nginx
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
Știe cineva ce fac greșit?
SFÂRȘIT EDITARE
Mi-am schimbat permalink-urile de la cele implicite la /%postname%/, și acum link-urile din panoul de administrare WordPress îmi dau erori 404 - Nu pagini 404 WordPress, ci pagini 404 nginx. Căutând de ce se întâmplă asta mi s-a spus că ar trebui să editez fișierul .htaccess sau că WordPress nu poate rescrie .htaccess - fișierul .htaccess nu există, iar WordPress nu dă nicio eroare când schimb permalink-urile.
Am încercat să creez un fișier .htaccess gol în directorul wordpress, i-am dat permisiuni 666, am schimbat utilizatorul și grupul la www-data și apoi am schimbat permalink-urile - nu a funcționat. Apoi l-am schimbat la următorul conținut înainte de a schimba permalink-urile:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Când nici asta nu a funcționat, am schimbat RewriteBase
la /wordpress/
înainte de a schimba din nou permalink-urile - tot nimic.
Am intrat și în fișierul .conf al site-ului meu și am schimbat try_files $uri $uri/ /index.php;
la următoarele variante, repornind nginx și php5-fpm de fiecare dată:
try_files $uri $uri/ /index.php?$query_string;
try_files $uri $uri/ /index.php?q=$request_uri;
try_files $uri $uri/ /index.php?$args;
Rulez un server local cu nginx. Are cineva idee ce se întâmplă aici?

Folosesc WordPress Multisite cu setări personalizate pentru permalink-uri: /%category%/%postname%/
/etc/nginx/site-available/domain.conf
Pe server{
location / {
try_files $uri $uri/ /index.php?q=$uri$args;
}
Dacă directorul rădăcină al WordPress nu este webroot-ul, ci http://domain.com/wordpress/:
location /wordpress/ {
try_files $uri $uri/ /wordpress/index.php?q=$uri$args;
}
Dacă folosești o versiune veche de WordPress cu blogs.dir, adaugă: location ^~ /blogs.dir { internal; alias /var/www/wordpress/wp-content/blogs.dir; access_log off; log_not_found off; expires max; }
Verifică configurația nginx: sudo nginx -t
Reîncarcă nginx: sudo service nginx reload
Încearcă și să modifici setările pentru permalink-uri.

Acesta este cel mai bun răspuns pentru oricine dorește să mute manual o instalare WordPress într-un subdirector sub un nou nume de domeniu! MULȚUMESC FOARTE MULT! Acesta ar trebui să fie răspunsul acceptat.

Calea: /etc/nginx/site-available/ ar trebui să fie: /etc/nginx/sites-available/

A doua opțiune a funcționat pentru mine, deoarece site-ul meu se afla într-un subdirector

Acestea sunt reguli de rescriere .htaccess
pentru Apache, dar ai menționat că utilizezi un server Nginx. Nginx nu folosește un fișier la nivel de director similar cu .htaccess
, cu atât mai puțin folosește fișierul .htaccess
în sine. Trebuie să editezi configurația serverului. Codex oferă un exemplu detaliat:
# Reguli pentru un singur blog WordPress.
# Proiectate să fie incluse în orice bloc server {}.
# Această ordine poate părea ciudată - este încercată pentru a se potrivi ultima dacă regulile de mai jos eșuează.
# http://wiki.nginx.org/HttpCoreModule
location / {
try_files $uri $uri/ /index.php?$args;
}
# Adaugă slash final la cererile */wp-admin.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Directive pentru a trimite antete expires și a dezactiva înregistrarea erorilor 404.
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires max;
}
# Decomentează una dintre liniile de mai jos pentru plugin-ul de caching utilizat (dacă este cazul).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Trimite toate fișierele .php către un server php-fpm/php-fcgi.
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
# Aceasta este o soluție robustă pentru problema de securitate a path info și funcționează cu "cgi.fix_pathinfo = 1" în /etc/php.ini (implicit)
include fastcgi.conf;
fastcgi_index index.php;
# fastcgi_intercept_errors on;
fastcgi_pass php;
}

Mulțumesc, aș vota acest răspuns dacă aș avea reputația necesară. Am o mică problemă în a implementa acest lucru în fișierul meu .conf, având în vedere că a fost deja modificat semnificativ față de setările implicite, dar măcar nu mai măresc cu .htaccess.

@s_ha_dum, am folosit această configurație până ieri când am actualizat la WordPress 4.8 și acum primesc erori 404 pe structurile personalizate de permalink-uri... am încercat să depanez problema de ieri dar nimic nu funcționează, ai vreo idee??

A trebuit să adaug acest fragment de cod atât în /sites-available/fisierul-tau-de-configurare
cât și în /sites-enabled/fisierul-tau-de-configurare
:
server {
[...]
if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}
[...]
}
Acum funcționează corect pentru mine.

A funcționat! Poți să explici ce face mai exact? (mai ales partea cu "last"...)

Fișierele din sites-enabled/ sunt legături simbolice către cele din sites-available/, așadar practic editezi fișierul din sites-available/ iar modificările se vor reflecta automat în celălalt folder. Doar o clarificare.

Pasul 1. Editați /etc/nginx/site-available/example.com
location / {
try_files $uri $uri/ /index.php?q=$uri$args;
}
Pasul 2. Autentificați-vă pe server Pasul 3. Rulați următorul cod pentru a crea o legătură simbolică pentru domeniul dumneavoastră
ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
Pasul 4. Testați configurația
sudo nginx -t
Pasul 5. Reporniți serverul Nginx
sudo systemctl restart nginx
Pasul 6. Salvați structura de legături permanente din panoul de administrare WordPress ***** Navigare plăcută ****
Mai multe detalii http://toihid.com/wordpress-permalink-in-nginx-server/

Răspunsul lui @Angelo a rezolvat problema pentru mine. Aș fi dat upvote, dar nu am suficiente puncte de reputație, așa că postez un răspuns.
Pentru claritate, următoarea configurație:
server {
server_name xxx.xxxx.com;
root /var/www/wordpress;
listen 80;
listen [::]:80;
index index.php;
location / {
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
}
}
a devenit:
server {
server_name xxx.xxxx.com;
root /var/www/wordpress;
listen 80;
listen [::]:80;
index index.php;
location / {
try_files $uri $uri/ =404;
}
if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
}
}
Observați adăugarea:
if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}

Iată o soluție care a funcționat pentru mine pe un server relativ nou. Serverul nu a rulat niciodată Apache înainte. Când am schimbat structura legăturilor permanente, primeam eroarea 404 pentru toate paginile, cu excepția paginii de start. Am pornit Apache în loc de Nginx, apoi am SCHIMBAT setările pentru legăturile permanente și le-am salvat. Apoi, probabil, le-am schimbat din nou în ceea ce doream și le-am salvat. Acest lucru a creat un fișier .htaccess. Apoi am repornit Nginx și totul a funcționat.
Nginx are un sistem care analizează fișierul .htaccess și se configurează în consecință. Dar până când nu există un fișier .htaccess, nu poate face acest lucru.
Această soluție a fost testată pe Plesk, WordPress 6.5 și PHP 8.2 pe Linux.
