Cambiar los enlaces permanentes me da errores 404 en nginx
EDICIÓN
Resultó que estaba equivocado tratando de editar .htaccess, ya que nginx no lo usa. Lo que aparentemente necesito hacer es editar mi archivo .conf. Antes de leer esto, mi my_app.conf se veía así:
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;
}
# Este bloque de ubicación coincide con cualquier cosa que termine en .php y lo envía a
# nuestro socket PHP-FPM, definido en el bloque upstream anterior.
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;
}
# Este bloque de ubicación se usa para ver las estadísticas de 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;
}
# Este bloque de ubicación se usa para ver las estadísticas de nginx
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
Ahora se ve así, y todavía no funciona:
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;
}
# Descomenta una de las líneas de abajo para el plugin de caché apropiado (si se usa).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Este bloque de ubicación coincide con cualquier cosa que termine en .php y lo envía a
# nuestro socket PHP-FPM, definido en el bloque upstream anterior.
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;
}
# Este bloque de ubicación se usa para ver las estadísticas de 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;
}
# Este bloque de ubicación se usa para ver las estadísticas de nginx
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
¿Alguien sabe qué estoy haciendo mal?
FIN DE LA EDICIÓN
He cambiado mis enlaces permanentes del valor predeterminado a /%postname%/, y ahora los enlaces dentro del panel de administración de WordPress me dan errores 404 - No páginas 404 de WordPress, sino páginas 404 de nginx. Al buscar por qué, me dijeron que esto debería estar editando mi archivo .htaccess o indicándome que WordPress no puede reescribir .htaccess - el archivo .htaccess no existe, y WordPress no da ningún error cuando cambio los enlaces permanentes.
He intentado crear un archivo .htaccess en blanco en mi carpeta de WordPress, dándole permisos 666, cambiando el usuario y grupo a www-data y luego cambiando los enlaces permanentes, pero eso no funcionó. Luego lo cambié a esto antes de cambiar los enlaces permanentes:
# 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
Cuando eso no funcionó, cambié RewriteBase
a /wordpress/
antes de cambiar los enlaces permanentes nuevamente - aún nada.
También he ido a mi archivo .conf del sitio y cambiado try_files $uri $uri/ /index.php;
a lo siguiente, reiniciando nginx y php5-fpm cada vez;
try_files $uri $uri/ /index.php?$query_string;
try_files $uri $uri/ /index.php?q=$request_uri;
try_files $uri $uri/ /index.php?$args;
Estoy ejecutando un servidor doméstico con nginx. ¿Alguna idea de qué está pasando aquí?

Estoy usando WordPress multisitio con configuración de enlaces permanentes personalizados: /%categoría%/%nombre-del-post%/
/etc/nginx/sitios-disponibles/dominio.conf
En server{
location / {
try_files $uri $uri/ /index.php?q=$uri$args;
}
Si tu instalación raíz de WordPress no está en la raíz web sino en http://dominio.com/wordpress/:
location /wordpress/ {
try_files $uri $uri/ /wordpress/index.php?q=$uri$args;
}
Si estás usando una versión antigua de WordPress con blogs.dir, añade: location ^~ /blogs.dir { internal; alias /var/www/wordpress/wp-content/blogs.dir; access_log off; log_not_found off; expires max; }
Verifica la configuración de nginx: sudo nginx -t
Recarga nginx: sudo service nginx reload
También prueba cambiando la configuración de enlaces permanentes.

¡Esta es la mejor respuesta para cualquiera que quiera mover manualmente una instalación de WordPress a un subdirectorio bajo un nuevo nombre de dominio! ¡MUCHAS GRACIAS! Esta debería ser la respuesta aceptada.

La ruta: /etc/nginx/site-available/ debería decir: /etc/nginx/sites-available/

La segunda opción funcionó para mí ya que mi sitio estaba en un subdirectorio

Estas son reglas de reescritura de Apache .htaccess
, pero has indicado que estás en un servidor Nginx. Nginx no utiliza un archivo a nivel de directorio similar a .htaccess
, y mucho menos utiliza el archivo .htaccess
en sí. Necesitas editar la configuración del servidor directamente. El Codex tiene un ejemplo detallado:
# Reglas para un blog único de WordPress.
# Diseñado para ser incluido en cualquier bloque server {}.
# Este orden puede parecer extraño, pero intenta coincidir al final si fallan las reglas siguientes.
# http://wiki.nginx.org/HttpCoreModule
location / {
try_files $uri $uri/ /index.php?$args;
}
# Añadir barra diagonal final a las solicitudes */wp-admin.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Directivas para enviar cabeceras de expires y desactivar el registro de errores 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;
}
# Descomenta una de las líneas siguientes para el plugin de caché apropiado (si se utiliza).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Pasar todos los archivos .php a un servidor php-fpm/php-fcgi.
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
# Esta es una solución robusta para el problema de seguridad de path info y funciona con "cgi.fix_pathinfo = 1" en /etc/php.ini (por defecto)
include fastcgi.conf;
fastcgi_index index.php;
# fastcgi_intercept_errors on;
fastcgi_pass php;
}

Gracias, votaría esto si tuviera la reputación. Estoy teniendo un poco de dificultad para implementar esto en mi archivo .conf ya que ya fue modificado significativamente desde el predeterminado, pero al menos ya no estoy jugando con el .htaccess.

@s_ha_dum, usé esta configuración hasta ayer cuando actualicé a WordPress 4.8 y ahora estoy obteniendo errores 404 en la estructura personalizada de enlaces permanentes... he intentado depurarlo desde ayer pero nada funciona, ¿alguna idea?

Tuve que agregar este fragmento de código tanto en /sites-available/archivo-de-configuracion
como en /sites-enabled/archivo-de-configuracion
:
server {
[...]
if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}
[...]
}
Ahora está funcionando correctamente para mí.

¡Esto funcionó! ¿Podrías explicar qué hace? (especialmente la parte de "last"...)

Los archivos en sites-enabled/ son enlaces simbólicos de sites-available/, así que básicamente estás editando el archivo dentro de sites-available/ y los cambios se reflejarán en la otra carpeta automáticamente. Solo una aclaración.

Paso 1. Editar /etc/nginx/site-available/example.com
location / {
try_files $uri $uri/ /index.php?q=$uri$args;
}
Paso 2. Iniciar sesión en el servidor Paso 3. Ejecutar el siguiente código para crear un enlace simbólico de tu dominio
ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
Paso 4. Probar la configuración
sudo nginx -t
Paso 5. Reiniciar el servidor Nginx
sudo systemctl restart nginx
Paso 6. Guardar los enlaces permanentes desde el panel de administración de WordPress ***** Feliz navegación ****
Más detalles http://toihid.com/wordpress-permalink-in-nginx-server/

La respuesta de @Angelo resolvió el problema para mí. Votaría a favor pero no tengo suficiente reputación, así que publico una respuesta.
Solo para mayor claridad, lo siguiente:
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;
}
}
se convirtió en:
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 el añadido:
if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}

Aquí hay una solución que me funcionó en un servidor relativamente nuevo. El servidor nunca tuvo Apache funcionando en él. Cuando cambiaba los enlaces permanentes, obtenía error 404 en todas las páginas excepto en la página de inicio. Activé Apache en lugar de Nginx, luego CAMBIÉ la configuración de enlaces permanentes y guardé. Luego probablemente cambié nuevamente a lo que quería y guardé. Esto creó un archivo .htaccess. Luego volví a activar Nginx y todo funcionó.
Nginx tiene un sistema para mirar el archivo .htaccess y configurarse a sí mismo. Pero hasta que no haya un archivo .htaccess, no puede hacer eso.
Esto fue en Plesk, WordPress 6.5 y PHP 8.2 en Linux.
