Clonación y wp-config apuntando al staging · WordPin 016

La inmobiliaria llevaba meses trabajando con un entorno de staging para probar una renovación visual de las fichas de propiedades. El proceso se hizo como tantas otras veces: clonar el entorno de pruebas, ajustar el diseño nuevo y mover los cambios a producción cuando el cliente dio el visto bueno. El lanzamiento salió sin sobresaltos. El dominio resolvía con normalidad, el certificado seguía activo y las primeras páginas cargaban sin ningún aviso extraño.

El problema apareció dos días después, cuando varios agentes comerciales empezaron a reportar algo raro: propiedades que ya estaban vendidas seguían apareciendo como disponibles, y otras recién publicadas no se veían por ningún lado. La web respondía, el dominio era el correcto, pero los datos no cuadraban con lo que el equipo manejaba internamente. En ese momento no sospechaba todavía del wp-config; era solo un archivo más de la lista de cosas que miraría si la caché no daba respuestas.

Lo raro era que el fallo no afectaba a todo por igual. Algunas fichas mostraban información reciente y otras parecían ancladas en una versión anterior del catálogo. Si el dominio era el de producción, ¿de dónde estaba saliendo esa mezcla de datos? Esto no encajaba, y antes de tocar nada quise entender qué estaba alimentando realmente esas páginas.

El rastro que llevaba hasta el wp-config equivocado

Antes de pensar en el wp-config fui a lo obvio. Toda migración reciente deja huellas de caché, y un plugin de este tipo puede servir contenido anterior al cambio sin que nadie lo note. Purgué la caché de página, probé en una ventana de incógnito y añadí un parámetro a la URL para comprobar si alguna capa intermedia estaba sirviendo una versión antigua. El resultado fue idéntico en los tres casos: las propiedades vendidas seguían figurando como activas. Las comprobaciones no habían cambiado el resultado, así que seguí investigando.

Sin cambios tras las comprobaciones de caché, miré la propagación del dominio. Después de una clonación es habitual que el DNS tarde en completarse, y durante ese margen el navegador puede alternar entre el servidor antiguo y el nuevo según qué resolución le llegue. Comprobé los registros A, que ya apuntaban de forma estable a la IP de producción, y lancé una petición directa contra esa IP forzando la cabecera Host, para confirmar que esa máquina respondía a las peticiones del dominio.

curl -I -H "Host: inmobiliariaejemplo.com" http://IP.PRODUCCION
HTTP/1.1 200 OK
Server: Apache
X-Powered-By: PHP/8.1

Los registros A estables junto con esa respuesta directa confirmaban que el servidor de producción era el que atendía las peticiones del dominio. El DNS tampoco era el culpable. Dos sospechosos razonables que había investigado, aunque las comprobaciones todavía no explicaban el origen del problema.

Un panel correcto, un escaparate distinto

Como las comprobaciones de caché y DNS no habían resuelto el problema, seguí investigando qué estaba ocurriendo dentro de WordPress. Usé WP-CLI para contar cuántas propiedades había publicadas en el sitio.

wp post list --post_type=propiedad --post_status=publish --format=count
42

El número no coincidía con el que manejaba el equipo comercial, que tenía registradas 67 fichas activas en su propio control interno. Aquella diferencia no demostraba todavía dónde estaba el problema, pero sí indicaba que los datos consultados desde WordPress no cuadraban con los del negocio.

Entré a revisar algunos IDs concretos saltándome los enlaces amigables, con la URL directa por parámetro, por si el fallo venía de las rewrite_rules tras la clonación. Las fichas cargaban, pero correspondían a propiedades que en el entorno de staging sí existían y que el equipo comercial no reconocía como reales. El síntoma parecía venir de un sitio, pero los datos salían de otro. Esto no encajaba. Si el dominio y el servidor eran correctos, el único punto que quedaba por revisar era el archivo que decide con qué base de datos habla WordPress: el wp-config.php.

El archivo que seguía hablando con el entorno antiguo

Abrí el wp-config.php por cPanel y comparé sus constantes de conexión con las credenciales que constaban en el panel de hosting para la base de datos de producción. Ahí apareció la discrepancia: el valor de DB_NAME no coincidía con el nombre de la base de datos de producción, sino con el de la base de datos del entorno de staging, que seguía activa en el mismo servidor.

La prueba que delató al wp-config heredado

Para confirmar qué base de datos tenía configurada WordPress, consulté directamente la constante DB_NAME mediante WP-CLI:

wp config get DB_NAME
staging_inmobiliaria

La respuesta coincidía con lo que había visto en el archivo. El dominio era el de producción, el servidor era el correcto, pero el wp-config seguía apuntando a la base de datos del entorno de pruebas. Eso explicaba por qué el recuento de WP-CLI no coincidía con el catálogo real: todo el sitio, panel de administración incluido, estaba trabajando contra una fotografía antigua del negocio, tomada antes de que se dieran de alta nuevas propiedades y se marcaran otras como vendidas.

El impacto no era solo visual. Cualquier cambio que alguien hiciera desde el panel en producción —actualizar un precio, publicar una propiedad nueva— se estaba guardando en la base de datos de staging, no en la de producción, dejando esos cambios huérfanos del entorno real. A nivel de SEO, el sitio indexable mostraba disponibilidad y precios que no correspondían a la realidad, lo que afectaba tanto a la confianza del usuario como a la coherencia de los datos estructurados de cada ficha.

Los falsos positivos no eran descabellados: una caché que retiene contenido antiguo y un DNS que tarda en propagar son patrones habituales tras una clonación. Pero ninguno de los dos explicaba que el propio WP-CLI, consultando directamente a WordPress, devolviera un nombre de base de datos que no era el de producción. La prueba confirmada era esa respuesta del wp-config, no una suposición sobre dónde podía estar fallando la entrega del contenido.

Corregir la conexión al staging sin alterar los datos de producción

La vía más rápida habría sido sobrescribir el wp-config.php entero con una plantilla limpia generada desde cero. Parecía razonable, pero ese archivo también contenía otras constantes propias del entorno —claves de seguridad, prefijo de tablas, configuración de memoria— que sí eran correctas y no tenían relación con el fallo. Reescribirlo por completo habría significado arriesgar esos valores sin necesidad, solo para corregir cuatro líneas concretas.

Tocar las constantes sin arrastrar el entorno antiguo

Opté por editar únicamente las constantes de conexión —DB_NAME, DB_USER, DB_PASSWORD y DB_HOST— sustituyéndolas por las credenciales reales de producción, confirmadas antes en la sección de Database setup del panel de hosting. Antes de guardar el cambio en el archivo activo hice una copia del wp-config.php original y probé las nuevas credenciales en una copia local, porque un wp-config mal editado no avisa con elegancia: deja una pantalla en blanco o un error de conexión directo.

define( 'DB_NAME', 'produccion_inmobiliaria' );
define( 'DB_USER', 'prod_user' );
define( 'DB_PASSWORD', 'contraseña_de_produccion' );
define( 'DB_HOST', 'localhost' );

Tras subir el archivo corregido, validé la conexión antes de dar el wp-config por bueno:

wp db check
Success: Database checked.

wp config get DB_NAME
produccion_inmobiliaria

Con la conexión confirmada, volví a contar las propiedades publicadas y esta vez el número coincidía con el que manejaba el equipo comercial. También revisé que el entorno de staging quedara aislado: cambié sus credenciales de acceso y comprobé que la herramienta de staging utilizada en la clonación no mantuviera ninguna sincronización programada entre ambos entornos, para que un futuro clonado no repitiera el mismo error.