Anevi.com
Debugging in WordPress

Debugging PHP code is part of any project, but WordPress comes with specific debug systems designed to simplify the process as well as standardize code across the core, plugins and themes. This page describes the various debugging tools in WordPress and how to be more productive in your coding as well as increasing the overall quality and interoperativity of your code.

For non-programmers or general users, these options can be used to show detailed information about errors.

WP_DEBUG #WP_DEBUG

WP_DEBUG is a PHP constant (a permanent global variable) that can be used to trigger the “debug” mode throughout WordPress. It is assumed to be false by default and is usually set to true in the wp-config.php file on development copies of WordPress.

// This enables debugging.
define( 'WP_DEBUG', true );
// This disables debugging.
define( 'WP_DEBUG', false );

Note: The true and false values in the example are not surrounded by apostrophes (‘) because they are boolean (true/false) values. If you set constants to 'false', they will be interpreted as true because the quotes make it a string rather than a boolean.

It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs.

PHP Errors, Warnings, and Notices #PHP Errors, Warnings, and Notices

Enabling WP_DEBUG will cause all PHP errors, notices and warnings to be displayed. This is likely to modify the default behavior of PHP which only displays fatal errors and/or shows a white screen of death when errors are reached.

Showing all PHP notices and warnings often results in error messages for things that don’t seem broken, but do not follow proper data validation conventions inside PHP. These warnings are easy to fix once the relevant code has been identified, and the resulting code is almost always more bug-resistant and easier to maintain.

Top ↑

Deprecated Functions and Arguments #Deprecated Functions and Arguments

Enabling WP_DEBUG will also cause notices about deprecated functions and arguments within WordPress that are being used on your site. These are functions or function arguments that have not been removed from the core code yet but are slated for deletion in the near future. Deprecation notices often indicate the new function that should be used instead.

Top ↑

WP_DEBUG_LOG #WP_DEBUG_LOG

WP_DEBUG_LOG is a companion to WP_DEBUG that causes all errors to also be saved to a debug.log log file This is useful if you want to review all notices later or need to view notices generated off-screen (e.g. during an AJAX request or wp-cron run).

Note that this allows you to write to log file using PHP’s built in error_log() function, which can be useful for instance when debugging Ajax events.

When set to true, the log is saved to debug.log in the content directory (usually wp-content/debug.log) within your site’s filesystem. Alternatively, you can set it to a valid file path to have the file saved elsewhere.

define( 'WP_DEBUG_LOG', true );
-or-
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );

Note: for WP_DEBUG_LOG to do anything, WP_DEBUG must be enabled (true). Remember you can turn off WP_DEBUG_DISPLAY independently.

Top ↑

WP_DEBUG_DISPLAY #WP_DEBUG_DISPLAY

WP_DEBUG_DISPLAY is another companion to WP_DEBUG that controls whether debug messages are shown inside the HTML of pages or not. The default is ‘true’ which shows errors and warnings as they are generated. Setting this to false will hide all errors. This should be used in conjunction with WP_DEBUG_LOG so that errors can be reviewed later.

define( 'WP_DEBUG_DISPLAY', false );

Note: for WP_DEBUG_DISPLAY to do anything, WP_DEBUG must be enabled (true). Remember you can control WP_DEBUG_LOG independently.

Top ↑

SCRIPT_DEBUG #SCRIPT_DEBUG

SCRIPT_DEBUG is a related constant that will force WordPress to use the “dev” versions of core CSS and JavaScript files rather than the minified versions that are normally loaded. This is useful when you are testing modifications to any built-in .js or .css files. Default is false.

define( 'SCRIPT_DEBUG', true );

Top ↑

SAVEQUERIES #SAVEQUERIES

The SAVEQUERIES definition saves the database queries to an array and that array can be displayed to help analyze those queries. The constant defined as true causes each query to be saved, how long that query took to execute, and what function called it.

define( 'SAVEQUERIES', true );

The array is stored in the global $wpdb->queries.

NOTE: This will have a performance impact on your site, so make sure to turn this off when you aren’t debugging.

Top ↑

Example wp-config.php for Debugging #Example wp-config.php for Debugging

The following code, inserted in your wp-config.php file, will log all errors, notices, and warnings to a file called debug.log in the wp-content directory. It will also hide the errors so they do not interrupt page generation.

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

NOTE: You must insert this BEFORE /* That's all, stop editing! Happy blogging. */ in the wp-config.php file.

Top ↑

Debugging Plugins #Debugging Plugins

There are many debugging plugins for WordPress that show more information about the internals, either for a specific component or in general. Here are some examples:

MySQL: [solución] Unknown collation: ‘utf8mb4_unicode_520_ci’

Obtenido del Blog Oficial de Bufa, publicación original por Jorge Maiden – 17 septiembre 2018.

Solución al error: #1273 – Unknown collation: ‘utf8mb4_unicode_520_ci’ que nos sale al importar algún archivo sql que se ha creado con una versión de MySQL más reciente que la del actual servidor en en que estamos importando.

Error muy común cuando creamos por ejemplo un wordpress en local y nos decidimos a importar el sql al servidor destino.

Basta con abrir ese archivo sql y buscar todas las apariciones de:

utf8mb4_unicode_520_ci

Y reemplazarlo por:

utf8mb4_unicode_ci

Power Builder no funciona correctamente (Solución)

Esto me sucedió recientemente en 2 diferentes temas habilitados para PowerBuilder de TemplateMonster después de actualizar a WordPress 5.0.3. Después de horas de problemas para resolver y reinstalar PowerBuilder y los archivos y complementos de temas principales, encontré:

Las versiones nuevas de WordPress traen un nuevo editor de html que es diferente a el que espera PowerBuilder para interactuar. Al no poder interactuar con el antiguo editor, simplemente no funciona.

La solución:

  1. Descargue el complemento Editor Clásico y habilite para deshacerse del nuevo editor WP.
  2. Navegue hasta el complemento en la parte inferior de su navegación de administrador de WordPress. En esa configuración asegúrese de que todos los tipos de publicación con los que desea usar PowerBuilder estén habilitados. (En los 2 temas que actualizamos a WordPress 5, todos los tipos de publicaciones no estaban marcados).
  3. Listo! El editor de PowerBuilder ya debe funcionar e interactuar con el editor clásico de html.

Cómo desactivar plugins de WordPress sin acceso al área de administración

Obtenido de Blog Oficial de Daniel Nabil – 20 noviembre 2011.

Respuesta rápida (en caso de urgencia):

  • Por FTP. Renombra la carpeta «plugins» y crea otra igual, pero vacía.
  • a través de phpMyAdmin. Edita el campo «active_plugins» (en la tabla «wp_options«) y vacía la lista de plugins activos sustituyendo el contenido por: «a:0:{}» (sin las comillas)

Respuesta completa

Es probable que en alguna ocasión necesitemos desactivar todos los plugins (o solo alguno) de nuestra instalación de WordPress pero, por una u otra razón, no podamos acceder al area de administración: páginas en blanco, pérdida de los datos de acceso o cualquier otra razón.

Por ejemplo, podemos encontrarnos con páginas en blanco en el panel de administración cuando algún plugin no es compatible con la versión de WordPress que tenemos instalada (o simplemente porque contiene errores), cuando el archivo «functions.php» del tema activo o «wp-config» están mal formados, etc.

Para comprobar si se trata de un problema con algún plugin instalado, tendremos que desactivarlos todos e ir activándolos de uno en uno, pero como no podemos acceder a la página de gestión, no podemos hacer nada.

Hay dos maneras de solucionarlo: por FTP o accediendo directamente a la base de datos a través de phpMyAdmin (o cualquier otro gestor).

Cómo desactivar plugins por FTP

Si tenemos acceso FTP a los archivos de la instalación, lo único que tenemos que hacer es cambiar el nombre de la carpeta «plugins« (en wp-content/plugins), por ejemplo llamándola «plugins_original», y crear una carpeta nueva vacía. Paso a paso sería así:

  1. Acceder por FTP a nuestra instalación de WordPress
  2. Abrir la carpeta «wp-content«
  3. Buscar la carpeta «plugins» y cambiarle el nombre (por ejemplo, «plugins_original»)
  4. Crear una carpeta nueva y llamarla «plugins»

Al volver a acceder al panel de administración nos aparecerá un mensaje de error por cada plugin que teníamos activado, pero en este caso, eso es precisamente lo que buscábamos: «El plugin X se ha desactivado debido a un error: El archivo del plugin no existe.»

Si volvermos a renombrar la carpeta original por FTP, los plugins aparecerán como inactivos y podremos volver a activarlos uno a uno, fijándonos bien cual es el que causa problemas.

Cómo desactivar plugins en phpMyAdmin

Lo que vamos a hacer es decirle al sistema que no tenemos ningún plugin activado, es decir, el mismo método que el anterior pero, esta vez, marcándolo directamente en la base de datos. En otras palabras, no vamos a eliminar ninguna extensión, solo a desactivarlas «a distancia». Para ello tendremos que:

  1. Acceder a través de phpMyAdmin a la base de datos de nuestra instalación de WordPress
  2. Examinar la tabla «wp_options» (el prefijo «wp_» puede variar según la instalación)
  3. Buscar en la columna «option_name» la fila «active_plugins» (puede que no esté en la primera página). O también podemos hacer una consulta SQL directa. Así:SELECT * FROM wp_options WHERE option_name = ‘active_plugins’;
  4. Editar esta fila
  5. En el campo «option_value» veremos una lista de todos nuestros plugins activos en forma de cadena. Lógicamente la longitud y el contenido variará dependiendo de los que tengamos activados:a:2:{i:0;s:19:»akismet/akismet.php»;i:1;s:27:»wp-pagenavi/wp-pagenavi.php»;}
  6. Guardar una copia de esta cadena (por si acaso, para poder volver a activar los plugins más tarde) y sustituirla por:a:0:{}
  7. Finalmente guardamos los cambios pulsando «Continuar»

Ahora podremos volver a acceder al panel de administración de WordPress. Si el problema de las páginas en blanco continúa, lo más probable es que los archivos «functions.php» o «wp-config» estén mal formados.

Más información (en inglés):
How to deactivate all plugins when not able to access the administrative menus?

Qué es WordPress multisite, cómo crearlo y qué usos tiene

Obtenido del Blog Oficial de ENRIQUE J. ROS – 22 noviembre 2016.

WordPress es un CMS flexible que, aunque nació como solución para blogs, actualmente cuenta con funcionalidades y capacidades que le hacen capaz de adaptarse a multitud de necesidades. Una de esas capacidades es la de crear un multisite.

Posiblemente quien gestione una web corporativa o una tienda online no haya oído hablar nunca de WordPress multisite, pero lo cierto es que es útil en una gran cantidad de situaciones y hasta es posible que, sin saberlo, lo necesites.

Qué es WordPress multisite

WordPress multisite o WordPress multisitio es una capacidad nativa de este CMS (es decir, no hay que instalar nada especial, sólo activarla) que permite gestionar una red de webs desde una sola instalación de WordPress.

Sí, efectivamente, es una forma de tener varias webs en un sólo WordPress. En principio son webs independientes: cada una tiene su escritorio de administración, su configuración independiente, su biblioteca de medios… Sin embargo, hay algunas particularidades.

Características de un multisite con WordPress

Para empezar, la activación de un multisite crea un nuevo rol de usuario: el de superadministrador o administrador de la red, un usuario que tiene privilegios para configurar la red, añadir, eliminar y editar sitios (es decir, webs), instalar o desinstalar themes y plugins… Es, en una palabra, el que tiene el poder de hacer y deshacer en la red de sitios.

El superadministrador puede cambiar fácilmente de un escritorio a otro (y al de administración de la red) mediante un nuevo menú que aparece arriba a la izquierda (entre  y ), Mis sitios, que enlaza de un sitio a otro. De la misma manera, un usuario que tenga cuenta en más de uno de los sitios del multisite también podrá cambiar de uno a otro mediante ese menú.

Escritorio de un superadministrador en WordPress multisite


Escritorio de un superadministrador en WordPress multisite

Una web perteneciente a un multisitio no puede instalar sus propios plugins o plantillas: es el superadministrador el que debe instalarlos. Los plugins estarán disponibles entonces para su activación en cualquiera de estos sitios, mientras que los themes pueden habilitarse de forma individual.

Así un plugin o un theme sólo se tendrá que actualizar una vez, aplicándose la actualización sobre todas las webs del multisite que lo utilicen o lo tengan activo.

¿Te suena todo esto? Efectivamente, WordPress.com no es más que un WordPress multisite.

Qué usos tiene WordPress multisite

A estas horas quizá estés pensando que eso es algo demasiado técnico y que, desde luego, queda muy lejos de nada que tú puedas necesitar nunca. Sin embargo, déjame que te plantee alguna de sus múltiples utilidades.

La primera y más obvia, siguiendo el ejemplo de WordPress.com, es la de una red de blogs, es decir, un grupo de blogs (o de webs de cualquier tipo) en general, controlados por una persona o por un grupo reducido de ellas sin necesidad de volverse loco yendo de un panel de administración a otro para realizar cualquier tarea de mantenimiento.

Pero hay otras utilidades. Por ejemplo, una web corporativa multilingüe en la que cada idioma está hospedado en su propio dominio (www.miweb.es para el español, www.miweb.com para el inglés, www.miweb.fr para el francés, etcétera), todas ellas en un multisite y con las traducciones gestionadas por Multilingual Press.

Ésa es, con diferencia la mejor, más eficiente y más optimizada (también para el SEO) forma de crear y gestionar una web multiidioma. Por desgracia no es válida para comercios electrónicos, ya que habría que crear un ecommerce independiente en cada una de las webs. Sin embargo, para blogs o webs corporativas es lo mejor.

Por supuesto, un multisite es también muy útil en este sentido para grupos de empresas, o empresas formadas por varias divisiones o ramas de negocio, de forma que todas las webs del grupo puedan ser gestionadas por una sola persona desde una única instalación.

Y ya, por paralelismo, si tú (aún no siendo un grupo de empresas  ) tienes varias webs, ¿por qué no tenerlas todas en un multisite? No sólo tendrás la administración de todas ellas centralizada en un sólo lugar sino que, además, sólo tendrás que pagar un hosting…

El multisite es especialmente útil también para todos aquellos a los que les gusta probar nuevos proyectos. Si sólo quieres saber si una idea funcionará, tendrá audiencia o mercado, o simplemente no tiene futuro, no es necesario contratar un hosting para crear la web: basta con establecer un nuevo site en el multisite. Si no funciona, se borra y a otra cosa.

Fuente: Enrique J. Ros
https://www.enriquejros.com/wordpress-multisite/

Migrar WordPress de servidor remoto

Obtenido del Blog Oficial de WP PRÁCTICO.

Hola, en este artículo vas a aprender cómo migrar WordPress de un servidor remoto a local. De esta forma podrás hacer todas las pruebas sin miedo a destrozar tu web.

Supongamos que quieres modificar el aspecto de tu blog, probar plugins nuevos, comprobar si al actualizar un plugin o plantilla todo sigue funcionando correctamente… pero sin arriesgarte a dejar tu web inopertiva o en modo mantenimiento.

Para evitar eso, lo ideal es hacer las pruebas en un servidor local como Xamp o utilizar la opción de staging si tu hosting te lo permite.

Creo que te será más fácil si sigues los pasos del videotutorial que he preparado.

Aquí tienes todos los pasos detallados en formato texto.

El primer paso para migrar WordPress a local es exportar la base de datos

Tienes acceder al phpMyAdmin de tu hosting y seleccionar la base de datos de tu instalación de WordPress.

Después entra en la pestaña de Export. En principio no tienes que tocar nada, solo asegúrate de que el formato sea SQL. 

exportar base de datos sql

En caso de que tengas varias instalaciones en una sola base de datos selecciona en Export Method -> Custom y marca solo las tablas de la instalación de WordPress que quieres pasar a local. Fíjate en el prefijo de las tablas para distinguirlas.

Copia todos los ficheros y carpetas a local

Esto no tiene ninguna complicación es hacer un copia y pega de toda la vida jeje.

Es mejor que previamente crees una carpeta en tu servidor local donde copiar todo el contenido. En mi caso he creado una que se llama weblocal. Ahora traslada todas la carpetas y ficheros de tu sitio web a la carpeta (que has creado antes) de tu servidor local.

Es algo bastante sencillo de hacer mediante FTP con un programa como FileZilla.

Crear una base de datos en el servidor local e importa los datos

Ahora que has copiado todos los archivos y tienes la base de datos exportada lo que hay que hacer es crear una nueva base de datos en el servidor local. Para después importar las tablas del tu sitio web.

Entra a phpMyAdmin de tu servidor local y crea una nueva base de datos con el nombre que quieras ( yo he creado una con el nombre weblocal)y con codificación UTF8.

localhost crear una base de datos en localhost

Ahora tienes una base de datos vacía. Para rellenarla con la información de tu web ve a Import y selecciona la base de datos que has exportado antes e importala.

Si todo ha salido correctamente te aparecerán todas las tablas de instalación de WordPress.

Cambia los datos de acceso a la base de datos en wp-config.php

Si intentas acceder ahora a tu web desde localhost te saldrá un error diciendo que no se ha podido realizar la conexión con la base de datos.

Eso es porque la base de datos que has creado en el servidor local no tiene el mismo nombre ni el mismo usuario. Para corregir eso tienes que modificar el archivo wp-config.php de tu instalación local de la siguiente forma:

DB_NAME: escribe el nombre de la base de datos que has creado antes.

DB_USER: si no has creado un usuario para la base de datos puedes usar el usuario por defecto llamado “root” sin contraseña que se crea por defecto.

DB_PASSWORD: la contraseña que le has puesto al usuario de la base de datos. Si has usado el usuario root  deja este campo vacío.

modifcar wpconfig
En ejemplo de cómo quedaría el archivo wp-config.php

Con estos tres cambios seria suficiente.

Si lo has hecho correctamente al acceder a tu web no debería de salir el error de conexion con la base de datos.

Modifica el siteurl en la base de datos

Al migrar WordPress de servidor local a localhost la url del sitio cambia. De forma que si intentas acceder al login te redirigirá la web “real”. Hay que corregir eso.

Entra a phpMyAdmin y selecciona la tabla wp-options (recuerda que el prefijo puede ser diferente). Edita la fila de siteurl y sustituye la url a la url de tu sitio en el servidor local. En mi caso es: http://localhost/weblocal 

modificar tabla wp_options

En la url sustituye weblocal por el nombre de la carpeta donde tengas guardados todos los ficheros de tu sitio web.

Últimos ajustes en el backend de WordPress

Ya queda poco.

Accede al panel de administración de tu web en local y ve a Ajustes -> Generales. Recuerda que los datos de acceso son los mismo que los de tu web en producción.

Cambia la url de Dirección del sitio a la url de tu web en el servidor local.

Ajustes generales WordPress

Por último ve a Ajustes -> Enlaces Permanentes y simplemente haz clic en guardar para que se actualice la estructura de los enlaces.

Ahora entra en tu blog y comprueba de que todo funciona correctamente. Si es así, puedes empezar a hacer todas las pruebas y modificaciones que quieras en tu blog en local.

Puede que te interese crear un tema hijo de tu plantilla si le vas a dar bastante caña al aspecto de la web.


Como ves migrar WordPress de un servidor remoto a local es bastante sencillo. Y también muy útil para no arriesgar la salud de tu web en producción.

Cambiar su tema de WordPress desde la base de datos

Obtenido del Blog One.com.

Normalmente puede gestionar sus temas de WordPress desde el panel de control en wp-admin. En algunos casos no es posible, por ejemplo cuando obtiene una pantalla en blanco tras actualizar y no puede iniciar sesión.

Puede solventarlo cambiando el tema activo por el tema predeterminado de la base de datos. Una vez hecho, inicie sesión otra vez en wp-admin y gestione su sitio desde allí.

Un tema predeterminado es el tema que estaba activo cuando instaló por primera vez WordPress, por ejemplo, el tema twentysixteen.


Paso 1 – Abra su base de datos en phpMyAdmin

Consulte la guía \nRead our guide on Cómo acceder a su base de datos si no sabe cómo hacerlo.


Paso 2 – Haga clic en wp_options

En el menú a su izquierda, haga clic en wp_options para abrir la tabla de opciones.

Nota: La tabla puede tener diferentes prefijos, en este ejemplo es www_. Si ha utilizado la instalacion de 1- clic el prefijo es por lo general la ubicación de su sitio WordPress.

Click wp-options in phpMyAdmin

Paso 3 – Encuentre el tema en la tabla

Encuentre las filas template y stylesheet. Normalmente se ubican en la página 2 en la tabla de opciones.

Change template and stylesheet

Paso 4 – Sustituya el tema

  1. Haga clic en el campo option_value para ver el template
  2. Sustituya el tema actual con un tema predeterminado, como twentysixteen.
  3. Pulse Intro para guardar los cambios.
  4. Haga lo mismo para stylesheet.
Changed template WordPress

Paso 5 – ¡Eso es todo!

El tema ha sido cambiado, su sitio web vuelve a ser accesible y puede iniciar sesión en su panel de control de WordPress.

Actualizar la conexión de la base de datos de WordPress

Obtenido del Blog One.com.

En ocasiones es preciso actualizar los datos de conexión de la base de datos en WordPress. Por ejemplo, después de actualizar la contraseña de base de datos o cuando se recibe el siguiente mensaje de error:

Error establishing a database connection


Paso 1 – Abrir File Manager (Administrador de archivos)

  1. Inicie sesión en el panel de control de One.com.
  2. Haga clic en File Manager, que se encuentra en la sección Archivos y seguridad.
Open File Manager

Paso 2 – Abrir wp-config.php

El archivo wp-config.php se encuentra en el directorio donde se instaló WordPress.
Haga clic en el archivo wp-config para abrirlo en el editor.

Open wp-config.php

Paso 3 – Localizar los datos de inicio de sesión

Los datos de inicio de sesión se suelen encontrar cerca de la línea 20 del archivo wp-config.
En este ejemplo, los datos son los siguientes:

define('DB_NAME', 'one_example_support'); define('DB_USER', 'one_example_support'); define('DB_PASSWORD', '********'); define('DB_HOST', 'one-example.support.mysql.service.one.com');

Find details in wp-config.php

Paso 4 – Actualizar los datos

En el siguiente ejemplo, debe sustituir update_here con los datos actualizados.
Puede encontrar los detalles de la conexión actual en el Panel de control de One.com bajo PHP & MariaDB.

define('DB_NAME', 'update_here'); define('DB_USER', 'update_here'); define('DB_PASSWORD', update_here'); define('DB_HOST', 'update_here');

Haga clic en Guardar en la esquina superior izquierda de la pantalla.

Edit details in wp-config,php
Cambiar contraseña de WordPress desde la base de datos

Obtenido del Blog One.com.

Normalmente usted puede restablecer la contraseña de WordPress en el panel de administrador o solicitar una nueva a través de correo electrónico. En caso de no tener acceso ni a su correo electrónico ni al panel de WordPress, usted puede cambiar su contraseña directamente en la base de datos.


Paso 1 – Ingrese a su base de datos en phpMyAdmin

Lea nuestra guía sobre cómo acceder a su base de datos si necesita algo de ayuda.


Paso 2 – Abra la tabla de usuarios

  1. Haga clic en la la tabla de usuraios en el menú de la izquierda. La tabla puede tener diferentes prefijos, en este ejemplo es www_.
  2. Busque el usuario para el que desea cambiar la contraseña y haga clic en Editar.
Open the table called wp-users

Paso 3 – Introduzca una contraseña nueva

  1. Junto a user_pass seleccione MD5 en el menú desplegable debajo de Function.
  2. En Value cambie la contraseña cifrada actual por la nueva contraseña. Puede escribir texto normal, que se cifrará después de guardar.
  3. Haga clic en Continuar para guardar los cambios
Type your new WordPress password

Paso 4 – Listo. ¡Usted ha terminado!

Su nueva contraseña se ha guardado y cifrado. Puede utilizarla para acceder a WordPress.

WordPress password changed
Errores 404 en WordPress en enlaces internos ¿solución?

Obtenido del Blog Oficial de WebEmpresa, publicación original por Luis Méndez Alejo  –  7 Enero 2017.

Este escenario es más común de lo que imaginas, sobre todo en proyectos nuevos con WordPress, cuando se instala en un Hosting, como instalación principal o adicional, y al navegar por enlaces internos de menús, post, etc., aterrizas en un error 404.

Los errores 404 en WordPress deben ser corregidos en el momento en que se presentan, por razones de uso de tu sitio web y además porque afectan al posicionamiento de tu dominio ¡y a Google no le gustan!

Si no quieres que uno o 200 enlaces internos dejen de funcionar por un error o incorrecta configuración, y tu posicionamiento acabe siendo el perjudicado, revisa los puntos que te explico a continuación para evitar estos errores.

Este artículo no pretende ser un tratado sobre los errores 404, sus causas y la forma en que deben ser corregidos todos y cada uno de los posibles casos, pero si te va a servir para solucionar un error bastante común que le sucede a muchos usuarios que se inician en WordPress y se tropiezan nada más empezar con este tipo de errores.

Errores 404 en WordPress en enlaces internos. Aprende a detectarlos y corregirlos en pocos minutos en tu web.

 ¿Que es un error 404?

Cuando en tu sitio web hay páginas que no son accesibles porque no cargan o la url que se solicita no existe o es incorrecta, se produce un error 404 que muestra a los usuarios un aviso más o menos como este.

Aviso 404

Haz clic en la imagen para ampliarla  

 ¿Que causa errores 404 en WordPress?

Básicamente enlaces no alcanzados, porque son incorrectos, han cambiado su estructura, slug o enlace permanente, ya no existen, o las reglas de reescritura son incorrectas y los enlaces permanentes están mal configurados.

  • Archivo .htaccess inexistente, vacío o sin reglas de reescritura.
  • Enlaces permanentes mal configurados (no amigables).

No todos los errores 404 están provocados por redirecciones incorrectas o urls que no alcanzan su destino por ser incorrectas o haber cambiado. Muchos errores 404 están simplemente relacionados con enlaces internos y una ausente o mala configuración de WordPress y .htaccess.

Plugins mal programados, cambios en las Taxonomías de WordPress o post personalizados (slug o enlace permanente modificado tras un indexado) provocan fácilmente errores 404 corrompiendo la matriz de los enlaces.

 ¿Cómo solucionar los errores 404 en WordPress?

Los sitios creados con WordPress pueden complicar el proceso de resolución de errores 404 al ser un sistema de gestión de contenidos que procesa su propia matriz de reescritura interna como parte de su función de gestión de enlaces permanentes.

Para poder corregir un error 404 primero hay que determinar si está causado por WordPress o por el servidor. web.

  • Por el servidor: Archivo .htaccess inexistente o erróneo.
  • Por el servidor: Permisos incorrectos de archivos y/o carpetas.
  • Por WordPress: Enlaces permanentes mal configurados.

Revisemos a continuación estos dos puntos, el archivo .htaccess y los enlaces permanentes y veamos cómo puedes configurarlos de forma correcta.

 Archivo .htaccess correcto para evitar errores 404

El archivo .htaccess de cada instalación de WordPress juega un papel determinante en el funcionamiento de los enlaces, su comportamiento y cómo son interpretados por el navegador.

Para que WordPress funcione correctamente deben existir una reglas de reescritura declaradas en dicho archivo. Básicamente, además de otros códigos, reglas o directrices, .htaccess debe incluir lo más abajo posible del archivo la siguientes reglas:

    # 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

Además de estas puede haber otras, propias, añadidas por el usuario, o incorporadas por determinados plugins de seguridad, SEO, etc.

El archivo htaccess debe tener permisos 644 y comenzar por un punto, que le otorga su característica de «archivo oculto».

Archivo htaccess

Haz clic en la imagen para ampliarla  

¿No encuentras el archivo .htaccess y tampoco te deja crearlo? no te preocupes, consulta este artículo.

Lectura recomendada: 
.htaccess en cPanel ¿dónde está el archivo?

 Configuración de los enlaces permanentes en WordPress

Los enlaces permanentes en WordPress ayudan a interpretar y mostrar las urls internas (todos los enlaces que componen tu web) de forma adecuada en base a la configuración aplicada.

Las opciones disponibles para enlaces permanentes son:

  • Simple: http://dominio.com/?p=123
  • Día y nombre: http://dominio.com/2017/06/04/pagina-ejemplo/
  • Mes y nombre: http://dominio.com/2017/06/pagina-ejemplo/
  • Numérico: http://dominio.com/archivos/123
  • Nombre de la entrada: http://dominio.com/pagina-ejemplo/
  • Estructura personalizada: http://dominio.com//%postname%/

Luego hay posibilidad de añadir estructuras personalizadas para etiquetas y categorías, pero no es el caso que nos ocupa.

Por defecto cuando instalas WordPress viene configurada como Simple la estructura de enlaces permanentes.

Enlaces permanentes - Simple

Haz clic en la imagen para ampliarla  

La configuración recomendada y más adecuada, principalmente para evitar los errores 404 es que los enlaces permanentes estén configurados como Nombre de la entrada.

Enlaces permanentes - Nombre de la entrada

Haz clic en la imagen para ampliarla  

De esta forma generarás urls amigables en tu sitio web, lo bots de indexado te querrán mucho más, a los usuarios les serán más amigables y fáciles de recordar ciertas urls y evitaras esos temidos errores 404.

 Proceso resumido:

  1. Inicia sesión en tu panel de WordPress (dashboard).
  2. En el menú de la izquierda haz clic en Ajustes, Enlaces Permanentes.
  3. Selecciona la configuración predeterminada: Simple y guarda los cambios.
  4. Cambia los ajustes de nuevo a la configuración: Nombre de la entrada.
  5. Guarda la configuración.
  6. Limpia la caché de tu web (si usas algún plugin de caching).
  7. Limpia la caché de tu navegador.

Esto debería regenerar la estructura de enlaces de tu web y que estos funcionasen, fuesen navegables y no se muestren errores 404 al cargar enlaces internos de tu sitio.

 Otros factores que pueden generar errores 404

Tener el archivo .htaccess correctamente generado y los enlaces permanentes bien configurados resolverán el 90% de los casos en los que podría producirse un error 404, pero hay otros factores que pueden contribuir a que aparezcan este tipo de errores.

  • Redirecciones 301 incorrectas.
  • Cambio del dominio que gestiona el sitio web (enlaces internos que conservan el anterior dominio).
  • URLs indexadas en los motores de búsqueda que ya no existen o han cambiado.
  • Configuración incorrecta de SSL (https).

Son algunos de los escenarios típicos que adicionalmente contribuyen a que tu sitio web pueda presentar errores 404.

Si quieres saber como combatir estos errores 404, principalmente los causados por redirecciones incorrectas, dominios que han cambiado o urls indexadas que ya no existen o han cambiado su estructura ¡lee este artículo!

Lectura recomendada: 
Redirection, como crear redirecciones 301 en WordPress

 Conclusiones

Hay diferentes formas de solucionar los errores 404, pero las básicas y más comunes las resuelves configurando correctamente el archivo .htaccess y los enlaces permanentes, para el resto de casos tendrás que aplicar redirecciones 301 o analizar cuál es la causa que provoca estos errores.

También es importante que tengas bien configurada la página de errores 404 donde aterrizarán los visitantes en caso de tropezarse «por descuido tuyo» con uno de esos errores.

Lectura recomendada: 
Páginas de error ¿cómo personalizarlas?

No olvides que dispones de otros tutoriales sobre errores 404 y redirecciones 301 en este Blog que pueden serte útil consultar.

WordPress es un gestor de contenidos dinámicos fiable y muy estable, pero nada en el mundo digital es 100% perfecto. 

Amamos lo que hacemos
WordPress