La validación de WordPress debe demostrar que el sitio migrado sigue siendo gestionable como entorno de contenido y aplicaciones. Una CMS Page puede existir en la base de datos y, aun así, tener incorrectos su jerarquía padre, imagen destacada, enlace de menú, campos personalizados, plantilla de página o ruta pública. Un tipo de contenido personalizado puede conservar títulos y cuerpos mientras pierde la taxonomía, el contrato de metadatos, los permisos, el archivo o el funcionamiento del plugin que hacía útiles sus registros.
Por tanto, el conjunto de evidencias debe seguir la propiedad en WordPress. Core Posts, CMS Pages, archivos adjuntos, taxonomías, términos, usuarios, roles, comentarios, metadatos, menús y opciones requieren pruebas distintas. Los tipos de contenido propiedad de plugins, tablas personalizadas, datos de constructores, membresías, formularios, eventos, directorios, cursos o identificadores externos deben verificarse mediante la aplicación que los consume. Los totales de registros respaldan la reconciliación, pero no pueden aprobar por sí solos el lanzamiento.
Definir las pruebas de WordPress y las decisiones de lanzamiento
Cada hallazgo material debe terminar en uno de estos estados de decisión:
- Pass: la evidencia representativa y de excepciones demuestra que el registro migrado es editable, localizable, está correctamente relacionado y puede utilizarse mediante su propietario previsto en WordPress.
- Watch: el resultado es utilizable, pero queda una corrección documentada no bloqueante, una tarea de configuración del destino, un ajuste manual de presentación o una diferencia aceptada de la plataforma.
- Block: el problema afecta materialmente al acceso al contenido, los permisos de las cuentas, las rutas públicas, la visibilidad en búsquedas, el funcionamiento de la aplicación, el cumplimiento o el alcance de migración acordado.
| Área de evidencia | Prueba en WordPress | Condición típica de Block |
|---|---|---|
| Contenido del núcleo | Posts y CMS Pages conservan contenido, estado, autor, fechas, jerarquía, medios, metadatos y ruta prevista. | Falta una página prioritaria, no es accesible o ya no puede editarse mediante el flujo previsto. |
| Contenido estructurado | Tipos de contenido personalizados, taxonomías, términos, metadatos y archivos conservan el modelo de aplicación. | Un tipo de registro material se reduce a contenido genérico o pierde campos y clasificaciones necesarios. |
| Identidad y acceso | Usuarios, roles, capacidades, autoría, membresías y contenido restringido coinciden con la propiedad prevista. | Usuarios no autorizados pueden acceder a registros restringidos o usuarios necesarios pierden acceso. |
| Presentación | Bloques, plantillas, estructuras de constructores, menús y referencias de medios respaldan el resultado público previsto. | Una ruta crítica para el lanzamiento resulta inutilizable aunque su texto exista. |
| Alcance de plugins | Los registros de plugins y tablas personalizadas tienen un propietario explícito en el destino y una salida utilizable. | Un flujo de plugin crítico para el negocio pierde registros, relaciones o identificadores. |
| URL y SEO | Permalinks, archivos, metadatos, enlaces internos y redirecciones conservan rutas prioritarias de descubrimiento. | Una ruta de alto valor falla sin un destino aprobado. |
El registro de decisión debe identificar el tipo de contenido, taxonomía, plugin, ruta, rol de usuario o contexto Multisite exactos que se revisaron. Una decisión general como “el contenido de WordPress ha pasado” es demasiado amplia cuando una misma instalación puede contener varias aplicaciones independientes.
Utilizar pruebas representativas para comprobar el verdadero modelo de contenido
Las pruebas representativas deben exponer las relaciones que hacen particular al sitio WordPress. Seleccione muestras como:
- un Blog Post normal con Categories, etiquetas, autor, imagen destacada, comentarios y un permalink sensible al SEO;
- una CMS Page con jerarquía padre, ubicación en menú, plantilla asignada, medios insertados y enlaces internos;
- registros de cada tipo de contenido personalizado importante;
- taxonomías personalizadas jerárquicas y planas con asignaciones de términos representativas;
- metadatos que almacenen valores literales, referencias a archivos adjuntos, relaciones con posts, referencias a términos, referencias a usuarios o estado serializado de plugins;
- galerías multimedia, archivos descargables y adjuntos reutilizados;
- usuarios con diferentes roles, capacidades, autoría o perfiles propiedad de plugins;
- páginas dependientes de constructores, shortcodes, bloques reutilizables o plantillas;
- una ruta de cada archivo o endpoint de plugin importante;
- registros propiedad de plugins o tablas personalizadas incluidos en el alcance.
El resultado de una prueba representativa es Block cuando revela una suposición estructural que una ejecución más amplia de la migración repetiría. Entre los ejemplos se incluyen tipos de contenido personalizados convertidos en CMS Pages, antiguos ID numéricos copiados en lugar de traducidos a nuevas referencias de registros, términos de taxonomía convertidos en etiquetas desconectadas o un perfil de membresía que llega sin el usuario de WordPress y las relaciones con contenido protegido que necesita.
No se espera que una prueba de migración representativa demuestre la integridad del volumen. Debe demostrar que la evidencia seleccionada representa el modelo WordPress real y que los administradores pueden reproducir la revisión tanto en el dashboard como en el sitio público.
Validar Core Posts, CMS Pages, Categories, etiquetas y menús
La validación del contenido del núcleo debe comprobar el registro completo, no solo el título y el cuerpo. Estado de publicación, autor, fechas, extractos, medios destacados, comentarios, jerarquía, protección por contraseña, estado sticky, revisiones cuando estén incluidas y comportamiento de rutas pueden cambiar cómo WordPress trata el registro.
| Evidencia de contenido del núcleo | Pass | Watch | Block |
|---|---|---|---|
| Blog Post | Contenido, autor, fechas, Categories, etiquetas, imagen destacada, estado y permalink son coherentes. | Una taxonomía de baja prioridad o un detalle de presentación requiere limpieza. | El historial editorial o una ruta prioritaria de publicación es materialmente incorrecta. |
| CMS Page | Contenido, jerarquía padre, contexto de plantilla, enlace de menú y ruta pública son correctos. | Queda un ajuste menor de orden de menú o plantilla. | Una página prioritaria queda huérfana, privada o enrutada incorrectamente. |
| Category o etiqueta | Identidad del término, jerarquía cuando corresponda, registros asignados, metadatos y comportamiento de archivo son correctos. | La presentación opcional del archivo necesita un ajuste. | Una clasificación prioritaria no puede consultarse o expone registros no relacionados. |
| Elemento de menú | Destino, jerarquía, etiqueta, acceso y estado activo son correctos. | Queda un ordenamiento no crítico. | Una ruta principal del visitante lleva al destino equivocado o a una ruta inactiva. |
| Comentario | Contenido padre, autor, fecha, estado, jerarquía de respuestas y significado de moderación siguen siendo comprensibles. | Queda una limpieza de moderación de bajo valor. | Se pierde una relación necesaria de debate o reseña. |
Categories y menús necesitan pruebas separadas. Una Category puede existir y clasificar Posts correctamente mientras el menú sigue apuntando a una ruta obsoleta. A la inversa, un menú puede cargar una ruta mientras el archivo asociado contiene registros incorrectos. La decisión de lanzamiento debe reflejar ambas estructuras de forma independiente.
Multisite exige evidencia consciente del sitio. Posts, CMS Pages, términos, opciones, menús y muchos registros de plugins pertenecen a un sitio de la red, mientras que los usuarios pueden participar en varios sitios. Un registro encontrado en el sitio equivocado no es una migración correcta aunque su contenido esté intacto.
Validar tipos de contenido personalizados, taxonomías y contratos de metadatos
Los tipos de contenido personalizados definen registros específicos de aplicaciones, como eventos, recursos, personal, propiedades, cursos, listados o casos de estudio. Su validación debe cubrir el tipo registrado, la interfaz de edición, las capacidades, las taxonomías, los metadatos, las rutas públicas, los archivos y la plantilla o plugin consumidor.
| Registro estructurado | Evidencia necesaria |
|---|---|
| Tipo de contenido personalizado | El registro aparece bajo el tipo previsto, admite los campos de editor necesarios y se representa mediante las rutas individual y de archivo previstas. |
| Taxonomía personalizada | Los términos permanecen en el vocabulario correcto, conservan la jerarquía cuando sea necesaria y clasifican los tipos de contenido previstos. |
| Relación entre posts | Las referencias apuntan a los registros correctos del destino y no a antiguos ID del origen. |
| Referencia de medios | Los ID y URL de archivos adjuntos resuelven el archivo migrado y conservan el contexto de galería o imagen destacada. |
| Referencia de usuario | Las relaciones de autor, propietario, instructor, vendedor, revisor o responsable apuntan al usuario previsto. |
| Metadatos serializados o estructurados | El plugin propietario o sistema de campos puede interpretar los datos sin truncamiento silencioso ni referencias rotas. |
| Definición de campo | Etiquetas, tipos de campo, valores permitidos, repetidores, grupos y relaciones condicionales siguen siendo utilizables cuando están dentro del alcance. |
Un valor puede mostrarse correctamente y, aun así, fallar estructuralmente. Por ejemplo, un campo de relación del origen puede mostrar el título de un Product como texto, pero la aplicación de destino puede requerir una referencia a un objeto post para permitir filtrado y actualizaciones. Ese resultado es Block cuando la relación impulsa un flujo crítico para el lanzamiento; no se aprueba solo porque aparezca el título.
La validación también debe distinguir los datos públicos de los administrativos. Un ID externo de CRM puede no mostrarse nunca en el sitio público y aun así ser crítico para el lanzamiento cuando la sincronización, los informes o la reconciliación dependen de él.
Validar medios, bloques, constructores, plantillas y representación pública
La presentación de WordPress puede combinar registros de archivos adjuntos, marcado de bloques, shortcodes, bloques reutilizables, patrones, partes de plantilla, metadatos de constructores, opciones del tema, menús, widgets y salida de plugins. El objetivo de validación no es una reproducción píxel por píxel salvo que esté explícitamente incluida en el alcance. El objetivo es contenido utilizable con propiedad y referencias correctas y un resultado de presentación aprobado.
| Evidencia de presentación | Pass | Watch | Block |
|---|---|---|---|
| Medios | Los archivos se abren, los metadatos de adjuntos son coherentes y las imágenes destacadas o galerías hacen referencia a los registros correctos. | Pies de foto, orden o tamaños secundarios necesitan limpieza. | Falta un medio prioritario o está vinculado al contenido equivocado. |
| Bloques del núcleo | La estructura de bloques sigue siendo editable y se representa sin referencias rotas. | Quedan diferencias menores de espaciado o tema. | El contenido se convierte en marcado inválido o pierde datos insertados esenciales. |
| Shortcodes | El plugin propietario o su sustituto representa el contenido previsto. | Queda una sustitución manual documentada. | Una página prioritaria muestra texto de shortcode sin procesar o pierde funcionalidad necesaria. |
| Constructor de páginas | El contenido importante es editable en el constructor previsto o tiene un resultado de reconstrucción aprobado. | Queda un refinamiento de diseño no crítico. | Una página crítica para el lanzamiento queda vacía, rota o atrapada en metadatos inutilizables. |
| Contexto de plantilla o tema | Se aplican la plantilla del registro y el contexto de navegación correctos. | Queda pulido visual fuera del alcance de la migración. | Los visitantes no pueden usar la página o los administradores no pueden mantenerla. |
El informe de evidencia debe clasificar si un problema de presentación pertenece al contenido migrado, a la configuración del tema de destino, a la compatibilidad del constructor, a una reconstrucción manual o a un resultado de migración no estándar acordado. Esta asignación evita confundir las correcciones de contenido con la implementación completa del sitio.
Incluya evidencia tanto del lado del editor como del visitante. Los editores deben poder localizar el registro, comprender sus componentes reutilizables, sustituir medios y actualizar la página sin depender de antiguos ID del origen. La evidencia del visitante debe cubrir representación responsive, recursos insertados, secciones interactivas y cualquier contexto de inicio de sesión o plugin que cambie la presentación. Esto separa una variación cosmética de una estructura que ya no puede mantenerse.
Validar usuarios, roles, capacidades y perfiles propiedad de plugins
Un usuario de WordPress es una identidad de inicio de sesión, no un perfil empresarial universal. El mismo usuario también puede ser propietario de Posts, pertenecer a un plan de membresía, representar a un alumno, gestionar una cuenta de vendedor o disponer de un perfil específico de plugin. La validación debe demostrar tanto la identidad del núcleo como las relaciones de aplicación incluidas en el alcance.
| Evidencia de identidad | Prueba necesaria |
|---|---|
| Usuario del núcleo | Identidad de nombre de usuario o correo, nombre visible, estado de cuenta y campos de perfil necesarios son correctos. |
| Rol y capacidad | El usuario puede realizar las acciones previstas y se le impiden acciones no autorizadas. |
| Autoría | Los Posts prioritarios y registros personalizados siguen asignados al autor o propietario previsto. |
| Contenido restringido | Las relaciones de grupo de usuarios, membresía o acceso exponen únicamente los registros previstos. |
| Perfil de plugin | Los registros de membresía, aprendizaje, directorio, vendedor, donante o comunidad permanecen conectados con el usuario correcto. |
| Límite de autenticación | Las expectativas de contraseña, inicio de sesión único o multifactor tienen un resultado de acceso de cuenta aprobado. |
Utilice usuarios representativos de cada rol material, incluidos usuarios con roles o relaciones de plugins superpuestos. Un nombre de rol puede parecer correcto mientras sus capacidades difieren. Un registro de usuario puede existir mientras su membresía o progreso de curso está desconectado. Estos resultados requieren evidencia y decisiones separadas.
La evidencia de cuentas también debe cubrir usuarios deshabilitados o inactivos, correos duplicados, nombres de usuario modificados y cuentas que deben conservar autoría sin recibir acceso de inicio de sesión. Cuando un plugin crea su propio perfil o registro de organización, verifique la dirección de la relación: el usuario de WordPress debe apuntar al registro de aplicación previsto y la aplicación debe devolver la misma identidad cuando los administradores la revisen.
Validar registros de plugins, tablas personalizadas y límites de comercio
Los plugins pueden almacenar registros mediante tipos de contenido personalizados, metadatos, opciones, comentarios, eventos programados o tablas dedicadas. La validación debe seguir al propietario real en lugar de asumir que todo registro es contenido ordinario de WordPress.
| Área propiedad de plugin | Evidencia que debe recopilarse | Señal para la decisión de lanzamiento |
|---|---|---|
| Formularios | Definición del formulario, campos, enrutamiento, envíos cuando estén incluidos, notificaciones y referencias externas | Block cuando un formulario necesario o el historial de envíos acordado resulta inutilizable. |
| Membresías | Planes, relaciones con usuarios, estado, reglas de acceso y contenido protegido | Block cuando miembros activos reciben acceso incorrecto. |
| Sistemas de aprendizaje | Cursos, lecciones, inscripciones, progreso, intentos y certificados | Block cuando el historial o acceso del alumno no puede reconciliarse. |
| Eventos o reservas | Eventos, sesiones, recursos, asistentes, reservas y fechas | Block cuando obligaciones o reservas programadas son incorrectas. |
| Directorios o marketplaces | Listados, propietarios, taxonomías, ubicaciones, reclamaciones, vendedores o pagos | Block cuando la propiedad o el descubrimiento público es materialmente incorrecto. |
| Plugin de redirecciones o SEO | Metadatos, valores canónicos, campos de schema y reglas de redirección | Block cuando se pierden rutas prioritarias o señales de búsqueda. |
| Plugin de comercio | Products, Customers, Orders, pagos, envíos, impuestos, inventario y extensiones | Validar según la función de la plataforma de comercio correspondiente, no como contenido central de WordPress. |
Los resultados de migración aprobados y acordados deben validarse contra el requisito compatible seleccionado y el campo o registro de destino esperado. Los resultados de migración no estándar deben validarse contra la transformación, relación, tabla personalizada o requisito de ID externo aprobados. Ninguno de ellos demuestra que un plugin, tema o integración no relacionados hayan sido completamente implementados salvo que ese trabajo esté explícitamente incluido.
Para cada dominio de plugin incluido, elija al menos un registro ordinario, uno excepcional y uno con muchas relaciones. La evidencia debe mostrar no solo que los valores se transfirieron, sino que la aplicación de destino puede consultarlos, editarlos y mostrarlos mediante sus interfaces compatibles. Los registros conservados únicamente como archivo deben etiquetarse claramente para no confundirse con datos activos de la aplicación.
Validar la integridad de una ejecución más amplia y las acciones posteriores
La evidencia de una ejecución más amplia debe ampliar la estructura representativa hacia la cobertura completa del alcance y de las excepciones. Reconcilie totales por tipo de registro y estado y, después, investigue las diferencias en lugar de tratar recuentos iguales como único objetivo. Incluya adjuntos huérfanos, slugs duplicados, registros no publicados, autores ausentes, términos sin asignar, relaciones rotas, alcance Multisite y registros de plugins excluidos o gestionados por separado.
La actividad posterior exige una revalidación específica para cada acción:
| Acción posterior | Evidencia de WordPress que debe repetirse |
|---|---|
| continuar con la configuración aceptada | Confirmar que los registros nuevos o modificados siguen utilizando los mismos tipos de contenido, taxonomías, definiciones de campos, alcance del sitio, reglas de rutas y relaciones de plugins. Volver a comprobar colisiones con ediciones ya realizadas en la tienda de destino. |
| continuar con una configuración revisada | Revalidar cada mapeo modificado, selección de tipos de datos, regla de campos, destino de taxonomía, regla de medios y decisión de tratamiento de plugins. La aprobación anterior no cubre la configuración modificada. |
| producir un resultado de migración nuevo y distinto | Tratar el nuevo resultado como un conjunto de evidencia independiente. Repetir la revisión estructural, de identidad, rutas, plugins y decisión de lanzamiento en lugar de heredar el resultado anterior. |
Crear el registro de decisión de lanzamiento de WordPress
El informe final debe ser reproducible y basarse en propietarios. Registre:
- el tipo de contenido, taxonomía, rol de usuario, plugin, sitio o ruta comprobados;
- los identificadores de origen y destino necesarios para la reconciliación;
- el resultado esperado y la evidencia observada;
- la decisión Pass, Watch o Block;
- el responsable de cualquier corrección o tarea de configuración del destino;
- si el hallazgo afecta al lanzamiento, a una actividad de migración posterior o únicamente a limpieza no bloqueante;
- la evidencia necesaria para cerrar el hallazgo.
Un Pass exige que el contenido prioritario y los registros de aplicación sean comprensibles, editables, localizables, respeten los permisos y estén conectados con las rutas públicas o flujos de plugins previstos. Un elemento Watch tiene un responsable identificado y no compromete esos resultados. Un Block permanece cuando el sitio publicaría rutas prioritarias rotas, expondría contenido restringido, perdería registros de aplicaciones o impediría a los administradores mantener contenido esencial.
Conclusión
La validación de WordPress debe seguir la propiedad y no la similitud entre tablas. Core Posts, CMS Pages, archivos adjuntos, términos, usuarios, comentarios, metadatos, menús, tipos de contenido personalizados, registros de plugins, rutas y estructuras de presentación pueden compartir infraestructura y, aun así, exigir evidencias diferentes.
Las pruebas representativas demuestran el modelo de contenido y aplicaciones. Una ejecución más amplia demuestra la integridad del alcance y el tratamiento de excepciones. Las acciones de migración posteriores exigen revalidación específica de los registros y configuraciones modificados. El lanzamiento solo se aprueba cuando la evidencia demuestra contenido utilizable, acceso correcto, rutas fiables, relaciones de plugins mantenibles y decisiones Pass, Watch o Block explícitas.
Preguntas frecuentes
¿Es suficiente comprobar el número de registros de WordPress después de la migración?
No. Los recuentos no pueden demostrar que los registros utilicen el tipo de contenido, la taxonomía, el contrato de metadatos, el alcance de sitio, la relación de usuario, el propietario de plugin, la ruta o la estructura de presentación correctos. Ayudan a reconciliar, pero deben combinarse con evidencia de funcionamiento y relaciones.
¿Por qué deben validarse los tipos de contenido personalizados por separado de las CMS Pages?
Los tipos de contenido personalizados pueden tener taxonomías, metadatos, capacidades, archivos, comportamiento REST, plantillas y consumidores de plugins diferentes. Reducirlos a CMS Pages puede conservar el texto visible y eliminar el modelo de aplicación.
¿Cómo debe clasificarse el contenido de un constructor de páginas?
Valide el contenido, las referencias, la superficie de edición y el resultado público necesario. Un resultado puede obtener Pass cuando el contenido es utilizable mediante el constructor previsto o mediante una reconstrucción aprobada. Debe obtener Block cuando una página prioritaria queda vacía, rota o deja de ser mantenible.
¿Deben validarse los registros de plugins como contenido ordinario de WordPress?
No. Valídelos mediante el plugin o la aplicación de sustitución que sea propietaria de sus campos, relaciones, permisos y flujos de trabajo. La mera existencia en el núcleo de WordPress no demuestra funcionamiento de membresías, cursos, reservas, formularios, directorios o comercio.
¿Qué debe volver a comprobarse después de una acción de migración posterior?
Vuelva a comprobar registros nuevos y modificados, reglas de mapeo, asignaciones de taxonomías, referencias, propiedad de usuarios, medios, rutas, relaciones de plugins y colisiones con ediciones de la tienda de destino. En WordPress, una configuración modificada o una migración distinta requieren una evidencia más amplia de tipos de contenido, taxonomías, usuarios, medios, rutas y plugins que una continuación sin cambios.
¿Cuándo debe un hallazgo de WordPress bloquear el lanzamiento?
Use Block cuando un problema material impida a administradores o visitantes utilizar contenido prioritario, exponga registros restringidos, rompa una ruta de alto valor, desconecte datos de plugins críticos para el negocio o incumpla el resultado de migración acordado.