Cómo hacer que WordPress funcione localmente y utilice rutas relativas para los enlaces

WordPress es uno de los mejores CMS que hay hoy en día en línea y que además es gratuito. En realidad es un increíble editor de contenidos. Sin embargo, una de las características de WordPress que en lo personal no me agrada mucho, y que no termino de entender el por qué no se ha solucionado, es la difícil tarea de no poder usar rutas relativas en vez de rutas absolutas.

En este artículo les explicaré cómo solucioné la forma de trabajar un sitio que estaba en línea de manera local, y además de cómo pude trabajar lo relativo al problema de los enlances e imágenes que eran afectados por la ruta (path).

Hace un par de semanas tuve que hacer un respaldo de un sitio en línea y trabajarlo en mi servidor local. Así que descargué todos los archivos y la base de datos del sitio web hecho en WordPress en la versión 4.2.2, es decir, la más reciente hasta junio de 2015. Una vez bajado el respaldo, para poder correr todo, lo primero que tuve que modificar fueron los archivos .htaccess y el wp-config.php para indicarles la nueva ruta. Cabe mencionar que yo trabajé los cambios del sitio en un folder al que llamé pm_abogados. A continuación muestro como quedó la configuración de estos archivos:

Y entre las líneas 17 y 34 de wp-config.php:

Una vez que hice estos cambios, pensé que eso sería suficiente para poder empezar a trabajar con las modificaciones, pero el sitio seguía sin funcionar correctamente a nivel local, por lo que procedí a modificar en la base de datos la tabla que se llama wp_options.

En las filas 1 y 2 de esta tabla, se cambia la liga original del sitio, como ejemplo utilizaré un dominio simulado que es http://www.mydomain.com y lo sustituyo en su lugar con la liga a nivel local que quedaría como http://localhost.

Si el sitio estuviera en un ruta diferente al root, se debe de especificar el path completo, por ejemplo, en mi caso quedó como http://localhost/pm_abogados/ como se puede ver en la siguiente imagen:

Una vez realizados estos cambios, prácticamente el sitio de WordPress había sido migrado a mi servidor local y todo parecía funcionar correctamente, así que me puse a realizar las modificaciones que pidió el cliente y fue aquí donde surgió otro problema: Todas las ligas de los contenidos apuntaban al dominio original y no al local.

Cuando se trata de un sitio relativamente pequeño, hacer las modificaciones manualmente no quita mucho tiempo, pero si se tratara de un sitio muy robusto y de mucho contenido y vinculación, esto podría convertirse en una verdadera pesadilla para el diseñador o el administrador del sitio.

Yo necesitaba cambiar la ruta del dominio por la ruta local en todo el contenido, pero no quería modificar manualmente cada ruta. En otras palabras, yo necesitaba que todo quedara así:

Así que después de un rato de analizar lo que debía de hacer, al final encontré una solución sencilla que consistió en correr la siguiente consulta en SQL a través de phpMyAdmin:

UPDATE `wp_posts` set `post_content`=REPLACE(`post_content`, 'www.mydomain.com/', 'localhost/pm_abogados/')

De esta forma, cada vez que entraba al contenido, veía que todo había sido reemplazado con lo que necesitaba, y fue entonces más fácil poder realizar las modificaciones a nivel local.

Cuando terminé de realizar los cambios, volví a reemplazar la ruta local por la del dominio con la consulta en SQL y subí la base de datos al servidor que está en línea. Los archivos .htaccess y wp-config, no los reemplacé con los locales ya que los que estaban previamente configurados en el servidor.

Aunque esto que acabo de escribir, es sumamente simple, a mí me llevó algo de tiempo poder descifrarlo y espero que estos tips les puedan servir de ayuda si están trabajando con WordPress y necesitan trabajar un sitio en línea de manera local, y jugar con todas las rutas de este CMS.

Y si crees que hay mejores soluciones, ¡Ayúdanos a compartirlas!

Es posible que hayan algunos plugins que nos ayuden a solucionar esto de una forma rápida, pero se decidió hacerlo así para no depender de un componente externo que el día de mañana, si el autor así lo decide, deje de actualizarlo y de darle soporte.