HTTP 404 con enlace permanente del nombre de la publicación

7 minutos de lectura

avatar de usuario
Ortund

Bien, acabo de crear la primera página en este sitio. Funciona cuando uso la configuración predeterminada de enlace permanente.

Si cambio la configuración del enlace permanente para usar el nombre de la publicación, obtengo un HTTP 404.

No estoy seguro de qué salió mal o si he roto algo. ¿Alguien puede ayudarme a arreglar?

El sitio está alojado en apache.

La página existe, el enlace está roto

avatar de usuario
Jared Cobb

¿Estás usando XAMPP o MAMP? Hay un par de contratiempos comunes con esos entornos, tomados del Codex de WordPress: Solucionar problemas de enlaces permanentes

Usuarios de XAMPP (Windows): Algunas versiones de XAMPP no habilitan mod_rewrite de forma predeterminada (aunque está compilado en Apache). Para habilitarlo, y así permitir que WordPress escriba el archivo .htaccess necesario para crear bonitos enlaces permanentes, debe abrir apache/conf/httpd.conf y quitar el comentario de la línea LoadModule rewrite_module modules/mod_rewrite.so (es decir, eliminar el signo almohadilla/almohadilla al frente de la fila).

Usuarios de WAMP (Windows): Algunas versiones de WAMP (¿todas las versiones?) no habilitan mod_rewrite ni permiten seguir SymLinks de forma predeterminada. Para habilitar la funcionalidad requerida, navegue hasta el archivo apache/conf/httpd.conf, ábralo con un editor de texto y elimine el comentario de la línea LoadModule rewrite_module modules/mod_rewrite.so (es decir, elimine el signo almohadilla/almohadilla al frente de la línea). Luego, más abajo en el mismo archivo hay una sección que comienza con la línea “Opciones FollowSymlinks”. Cambie la segunda línea de esa sección de “AllowOverride none” a AllowOverride all. Guarde el httpd.conf editado y reinicie todos los módulos WAMP. Tus enlaces permanentes ahora deberían funcionar.

También podrías ver Enlaces permanentes sin mod_rewrite si tu sandbox no tiene mod_rewrite disponible.

apache

Si está utilizando Apache, generalmente hay otros dos culpables de los enlaces permanentes rotos: .htaccess no se genera (debido a la configuración de permisos) o Apache AllowOverride La directiva no está habilitada.

Primero, si usa SSH en su servidor, ¿ve un archivo .htaccess generado en la raíz? De lo contrario, es posible que WordPress no tenga permisos para escribir ese archivo. También es posible que el archivo lo hace existe, pero que WordPress no puede editarlo. En cualquier caso, puede chmod ese archivo (y créalo si no existe) al 666.

A continuación, asegúrese de que su configuración de Apache tenga la siguiente configuración:

  <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

Finalmente, lea el Solucionar problemas de enlaces permanentes sección del Codex de WordPress. Hay varios otros consejos y sugerencias sobre por qué los enlaces permanentes podrían no funcionar.

  • Esto está alojado en apache.

    – Ortund

    17 de junio de 2014 a las 14:09

  • @Ortund Lo siento, me lo perdí. Actualicé mi respuesta, espero que eso ayude.

    – Jared Cobb

    17 de junio de 2014 a las 14:24

  • No te lo perdiste, pensé que era evidente, así que no incluí esa información. Sin embargo, lo agregué ahora

    – Ortund

    17 de junio de 2014 a las 15:08

  • Bien, ¿el .htaccess debería estar en el directorio raíz de WP o en el directorio raíz del tema?

    – Ortund

    17 de junio de 2014 a las 15:09

  • @Ortund Debería estar en la raíz del sitio (y parece que tienes WordPress ejecutándose en la raíz de tu sitio). Debería estar al mismo nivel que el primer WordPress index.php expediente.

    – Jared Cobb

    17 de junio de 2014 a las 15:12

En mi caso, primero tuve que actualizar el .htaccess archivo dentro de la carpeta raíz de mi sitio web:

# 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

WordPress hace esto automáticamente si tiene permiso de escritura. De lo contrario, se quejará de que no puede escribir en él y le dará el ejemplo de código anterior para que pueda actualizar manualmente el .htaccess.

Después de eso, edité el apache2.conf expediente. En Linux, reside en /etc/apache2/apache2.confhabrá una sección como esta:

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Cambio AllowOverride None a AllowOverride FileInfo.

Finalmente, ejecute los siguientes comandos:

sudo a2enmod rewrite
service apache2 restart

Todos estos pasos fueron necesarios para poder trabajar.

  • AllowOverride FileInfo era mi pieza perdida.

    – Traca

    3 de marzo de 2019 a las 5:43

encontré esta publicación en otro sitio que ya ayudó a muchas personas

¡Finalmente logré resolver el problema! La solución: estaba usando una estructura de enlaces permanentes personalizada http://kyl.fi/%category%/%postname%/. Eliminé la barra inclinada final (es decir, la última /) y listo. Sin embargo, estoy bastante seguro de que antes usé una estructura de enlace permanente con la barra inclinada sin ningún problema, por lo que todavía estoy confundido y me interesaría saber más sobre este problema si alguien tiene una explicación.

Todos los enlaces permanentes estándar tienen un final / allí.

En mi caso, estoy usando el navegador web NGINX con mi instalación de WordPress. La solución es agregar el siguiente fragmento de código a las Directivas NGINX:

location / {
try_files $uri $uri/ /index.php?$args;
}
# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
location ~* \.(jpg|jpeg|png|gif|css|js|ico)$ {
expires max;
log_not_found off;
}

Si está utilizando el excelente sustituto (de código abierto) ISPconfig.org CPanel, vaya a su página de Sitios, en la pestaña Opciones, ingrese el fragmento de código anterior para las Directivas NGINX. ISPconfig tiene una función para agregar fragmentos de código comunes para un acceso rápido en la pestaña Opciones.

Después de hacer la corrección anterior, pude usar cualquiera de las opciones de Permalinks de WordPress.

avatar de usuario
Estiércol

Solución de trabajo probada:

en su archivo de configuración apache2, por ejemplo:

/etc/apache2/sites-enabled/000-default.conf o mysite.conf etc..

Asegúrese de haber configurado el parámetro y no vacío: ServerName www.example.com or 123.212.333.111

También asegúrese de haber establecido las reglas de directorio como se muestra a continuación (es posible que sus reglas de reescritura no hayan tenido efecto en .htaccess, por lo tanto, colóquelo aquí e intente averiguar por qué .htaccess no funciona .htaccess no funciona apache):

<Directory /var/www/html>
       Options Indexes FollowSymLinks MultiViews
       AllowOverride All
       Order allow,deny
       allow from all

       RewriteEngine On
       RewriteBase /
       RewriteRule ^index\.php$ - [L]
       RewriteCond %{REQUEST_FILENAME} !-f
       RewriteCond %{REQUEST_FILENAME} !-d
       RewriteRule . /index.php [L]
</Directory>

avatar de usuario
Amir Goodarzi

Debe ser una verificación de 2 puntos: 1. Agregue el código al archivo .htaccess:

# 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
  1. Y el permiso del archivo .htaccess, debe ser: 644

avatar de usuario
máxima

en centos 8 y apache 2.4 busque en /etc/httpd/conf.d en el archivo .conf de su sitio agregue AllowOverride All, ejemplo como este

<Directory /path/to/site>
     #add the following setting to allow .htaccess in your web dir to work
     AllowOverride All

</Directory>

MI PUERTO DE ESCUCHA 80

    #Listen 80
<VirtualHost *:80>
    DocumentRoot "/var/www/mysite.com"
    ServerName www.mysite.com

    # Other directives here
    

        <Directory "/var/www/mysite.com">
                Options FollowSymLinks
                AllowOverride All
        </Directory>
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.mysite.com [OR]
RewriteCond %{SERVER_NAME} =mysite.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

MI HOST VIRTUAL SSL:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    DocumentRoot "/var/www/mysite.com"
    ServerName www.mysite.com

    # Other directives here
    <Directory "/var/www/mysite.com">
                Options FollowSymLinks
                AllowOverride All
        </Directory>
ServerAlias mysite.com
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/mysite.com/fullchain.pem
SSLCertificateKeyFile /live/mysite.com/privkey.pem
</VirtualHost>
</IfModule>

Reinicie el servicio de apache. Verifique su .htaccess (en mi sitio, el .htaccess se encuentra en /var/www/mysite.com Mi .htaccess

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteRule ^helloWorld/?$ /index.php [NC,L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

mira la regla de reescritura de helloWorld. Si invocas url www.misitio.com/holaMundo y el navegador muestra su página de inicio, la configuración funciona y la ruta del enlace permanente al sitio funciona.

¿Ha sido útil esta solución?