WordPress guarda URL absolutas en decenas de tablas de la base de datos, por lo que un cambio de dominio o el paso a SSL deja direcciones antiguas repartidas por entradas, opciones y ajustes de plugins: una búsqueda y reemplazo es la forma de limpiarlas con seguridad. Esta guía explica las dos formas admitidas de hacerlo en KPanel, por qué un tercer método muy habitual daña los datos y cómo verificar el resultado.
Cuándo la necesita
- Al pasar de
http://ahttps://después de activar SSL. - Al cambiar de dominio, por ejemplo de
old-brand.co.nzanew-brand.co.nz. - Después de enviar staging a producción, cuando el nombre de host de staging sigue grabado en la base de datos.
- Al retirar un antiguo servidor de recursos y redirigir todas las URL de imágenes a la vez.
- Para corregir de forma masiva una errata en muchas entradas, como un número de teléfono antiguo o el nombre de un producto descatalogado.
Una búsqueda y reemplazo reescribe filas en todas las tablas a la vez y no hay forma de deshacerlo fila por fila. Haga una copia de seguridad antes de empezar, siempre, incluso para un cambio que parezca trivial. KPanel crea una automáticamente cuando utiliza las herramientas integradas que se describen a continuación, pero si ejecuta el comando usted mismo, la responsabilidad es suya. Consulte Realizar una copia de seguridad.
Por qué no puede limitarse a ejecutar un REPLACE de SQL
Este es el error más dañino que se puede cometer al trabajar con la base de datos de WordPress, así que conviene entenderlo antes de elegir un método.
WordPress guarda los ajustes de plugins, las opciones de temas y los datos de widgets como cadenas serializadas de PHP. Una cadena serializada registra la longitud de cada valor que contiene, así:
a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}
Ese s:26 indica que la URL tiene 26 caracteres. Si sustituye http:// por https:// con un simple REPLACE() de SQL, el texto pasa a tener 27 caracteres mientras la longitud almacenada sigue indicando 26. PHP se niega entonces a deserializar la opción completa, y el ajuste vuelve a quedar vacío sin avisar. Los ajustes del personalizador del tema desaparecen, los sliders pierden sus diapositivas y las licencias de los plugins se dan de baja solas.
La búsqueda y reemplazo de WP-CLI que ejecuta KPanel deserializa cada valor, hace el reemplazo dentro de él y lo vuelve a serializar con las longitudes corregidas. Por eso es el único método que se documenta aquí.
Nunca ejecute UPDATE wp_options SET option_value = REPLACE(...) ni su equivalente en phpMyAdmin contra una base de datos de WordPress. Parece que ha funcionado, informa de filas afectadas y destruye sin avisar todos los ajustes serializados que ha tocado. No hay más reparación posible que restaurar una copia de seguridad.
Método 1: la tarjeta Buscar y reemplazar
Es la opción adecuada para casi todo el mundo. Está disponible en todos los planes de WordPress.
- Inicie sesión en KPanel y haga clic en Sitios web en la barra lateral izquierda.
- Haga clic en el sitio.
- Abra la pestaña WordPress y luego la sección Acciones rápidas.
- Busque la tarjeta Buscar y reemplazar y haga clic en Configurar.
- Introduzca el texto existente en Buscar (valor antiguo).
- Introduzca el texto nuevo en Reemplazar por.
- Deje marcada la casilla Simulación (solo vista previa, sin cambios) y haga clic en Vista previa.
La simulación indica cuántos reemplazos se harían y desglosa el recuento por tabla y columna, para que pueda ver exactamente dónde se aplicaría el cambio antes de confirmarlo.
Cuando la vista previa sea correcta:
- Desmarque Simulación.
- Haga clic en Ejecutar.
- Confirme el cuadro de diálogo.
Antes de que empiece el reemplazo se realiza automáticamente una copia de seguridad completa, y la ejecución abarca todas las tablas, incluidas las creadas por plugins.
Busque la cadena más específica posible. Reemplazar old-domain.co.nz también reescribe mail.old-domain.co.nz y staging.old-domain.co.nz, y rara vez es eso lo que quiere. Incluir el esquema, como en https://old-domain.co.nz, mantiene la coincidencia acotada.
Método 2: WP-CLI desde la consola
La consola le ofrece el mismo motor con más control sobre las opciones. Es una de las secciones que aparecen en los planes gestionados; en otros planes, la barra de pestañas muestra en su lugar un enlace +8 en Managed.
Abra el sitio, luego WordPress y luego Consola. La línea de comandos ya empieza por wp, así que escriba solo el resto del comando.
Primero, la vista previa:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run
Después, la ejecución real:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables
La consola no hace una copia de seguridad por usted. La copia de seguridad automática previa a la ejecución solo se realiza cuando utiliza la tarjeta Buscar y reemplazar del método 1. Si ejecuta el comando aquí, haga antes usted mismo una copia de seguridad desde la página Copias de seguridad del sitio.
Opciones útiles:
| Opción | Qué hace |
|---|---|
--all-tables | Incluye las tablas personalizadas creadas por plugins, no solo las tablas principales de WordPress |
--dry-run | Informa de lo que cambiaría y no escribe nada |
--precise | Usa PHP en lugar de SQL para el reemplazo. Es más lento, pero gestiona estructuras serializadas complicadas |
--skip-columns=guid | No modifica los GUID de las entradas (vea más abajo) |
--report-changed-only | Limita la salida a las tablas que realmente cambiaron |
Una nota sobre los GUID
Cada entrada de WordPress tiene una columna guid. Aunque parece una URL, es un identificador, no un enlace, y los lectores de feeds lo usan para saber si ya han visto un elemento. Reescribirlo puede hacer que todas las entradas de su feed vuelvan a aparecer como nuevas.
Reescriba los GUID cuando cambie de dominio de forma permanente y empiece de cero. Omítalos con --skip-columns=guid cuando solo esté pasando de HTTP a HTTPS en el mismo dominio.
Cambio de dominio: utilice en su lugar la tarjeta de URL del sitio
Si el objetivo es trasladar el sitio a un dominio nuevo, no empiece con una búsqueda y reemplazo. La tarjeta Cambiar URL del sitio, en la misma sección Acciones rápidas, actualiza las opciones siteurl y home y ejecuta el reemplazo en todas las tablas en una sola operación, en el orden correcto. Hacerlo al revés puede dejar a WordPress sin poder cargar su propio panel de administración.
Después del reemplazo
Recorra esta lista antes de darlo por terminado.
- Vacíe la caché. En la sección Acciones rápidas, ejecute Vaciar caché. Si el sitio utiliza la caché de página completa, púrguela desde WordPress y luego Caché.
- Vacíe las reglas de reescritura. Ejecute Vaciar reescrituras en la misma sección, o abra Ajustes y luego Enlaces permanentes en wp-admin y haga clic en Guardar cambios sin modificar nada.
- Purgue la CDN si el sitio la utiliza, desde Rendimiento y luego Kapsule CDN. Consulte Purgar la caché de Kapsule CDN.
- Cargue el sitio en una ventana privada para que la caché de su navegador no le confunda.
- Compruebe el candado. Si el candado falta o muestra una advertencia después del paso a SSL, significa que han quedado URL sin cambiar: Solucionar advertencias de contenido mixto.
- Revise las páginas más delicadas. Los sliders de la página de inicio, el logotipo de la cabecera, cualquier página creada con un maquetador visual y el proceso de pago de una tienda. Ahí están las URL que se guardan en opciones serializadas.
- Vacíe cualquier plugin de caché desde su propia pantalla de ajustes.
Solución de problemas
La simulación indica cero reemplazos. La cadena no está en la base de datos exactamente en esa forma. Compruebe si hay una barra final, un prefijo www. o el esquema. Pruebe primero a buscar solo el nombre de host sin más para confirmar que está ahí.
Las imágenes no se ven después de un cambio de dominio. Las URL de los medios están en wp_posts y wp_postmeta y --all-tables las incluye, pero una CDN o un plugin de optimización de imágenes puede guardar en caché sus propias copias reescritas. Purgue la CDN y la caché del plugin y vuelva a cargar la página.
Los ajustes desaparecieron después del reemplazo. Es el problema de la serialización, y significa que el cambio se hizo con SQL directo en lugar de con las herramientas que se describen aquí. Restaure la copia de seguridad realizada antes de la ejecución: Restauración a partir de una copia de seguridad.
Las URL de staging vuelven a aparecer. Algo las está volviendo a introducir, normalmente un envío programado o una opción en caché. Revise el flujo de trabajo en Uso de staging: enviar y traer cambios y asegúrese de que Reescribir URL esté marcado al hacer el envío.