La validación de una migración hacia Joomla debe demostrar que los registros migrados siguen formando páginas, rutas, permisos, relaciones de idioma y procesos pertenecientes a extensiones que realmente pueden utilizarse. Un Article puede existir mientras su Category, Menu Item, Access Level, asociación de idioma, contexto de Modules, estilo de Template o alias produce un resultado público equivocado. Un User puede existir mientras los Groups y Viewing Access Levels asignados permiten ver demasiado o demasiado poco contenido.
Joomla también separa los registros del CMS core de los registros pertenecientes a componentes y extensiones. Products comerciales, Customers, Orders, formularios, directorios, reservas, membresías y estructuras de page builders pueden utilizar infraestructura de Joomla y seguir perteneciendo a su componente. La validación debe seguir a esos responsables en lugar de tratar cada fila como un Article o un User.
Defina la evidencia y las decisiones de lanzamiento para Joomla
Utilice un único estado de decisión para cada área material de evidencia:
- Pass: la evidencia representativa y de excepciones demuestra el resultado previsto en contenido, rutas, acceso, idiomas, composición de páginas o extensiones de Joomla.
- Watch: el resultado es utilizable, pero queda una corrección documentada que no bloquea, una tarea de configuración del destino, un ajuste manual de presentación o una diferencia aceptada.
- Block: el problema afecta materialmente al acceso público, contenido restringido, continuidad multilingüe, rutas importantes, registros de extensiones, historial comercial, cumplimiento o alcance de migración acordado.
| Área de evidencia | Qué debe demostrar Joomla | Condición habitual de Block |
|---|---|---|
| Contenido del núcleo | Articles y Categories conservan contenido, estado, jerarquía, idioma, acceso, metadatos y capacidad de edición. | Falta un Article prioritario, está asignado incorrectamente o no puede acceder a él su público previsto. |
| Menús y rutas | Menu Items, aliases, relaciones padre-hijo, páginas de inicio, vistas de componentes y redirecciones llevan a destinos aprobados. | Una ruta de alto valor resuelve un elemento, idioma o contexto de acceso incorrecto. |
| Identidad y ACL | Users, Groups, permisos, Viewing Access Levels y registros restringidos coinciden con la política prevista. | Users no autorizados pueden ver o editar contenido restringido, o Users necesarios pierden acceso. |
| Multilingüe | Idiomas, asociaciones, estructuras de menús y contenido específico de idiomas permanecen conectados. | No puede completarse un recorrido prioritario en un idioma. |
| Composición de página | Modules, posiciones, estilos de Template, sobrescrituras y salida de componentes sostienen las páginas prioritarias. | Una página crítica para el lanzamiento no puede comprenderse o utilizarse. |
| Alcance de extensiones | Registros pertenecientes a componentes y salidas de migración no estándar permanecen conectados con sus responsables. | Faltan registros críticos de extensiones o comercio, o quedan desconectados. |
Una decisión sobre Joomla debe identificar el Article, Category, Menu Item, vista de componente, idioma, Access Level, estilo de Template, posición de Module o registro de extensión revisado. Un Pass a nivel del sitio no puede ocultar un fallo aislado en un idioma o en un público restringido.
Utilice pruebas representativas para demostrar las relaciones de Joomla
Las pruebas representativas deben incluir registros que expongan el modelo de página de Joomla:
- un Article con Category, autor, metadatos, estado, acceso, idioma y medios;
- Categories anidadas utilizadas por layouts de lista o blog;
- un Menu Item directo a un Article y un Menu Item de Category Blog o Category List;
- una jerarquía de menús con aliases, elementos superiores, acceso, idioma y un elemento de inicio predeterminado;
- un Article o vista de componente restringidos vinculados a un Access Level no público;
- Users representativos de varios User Groups;
- Articles, Categories, menús y asociaciones multilingües cuando se utilicen;
- una página compuesta por salida de componente, Modules, estilo de Template y funcionamiento de sobrescrituras;
- un registro de cada extensión importante o componente comercial incluido en el alcance;
- rutas prioritarias, redirecciones, medios y Custom Fields.
El resultado de una prueba representativa es Block cuando revela un supuesto estructural que una ejecución más amplia de la migración repetiría. Algunos ejemplos son Articles asignados a la Category equivocada, aliases de menús que crean rutas duplicadas o incorrectas, Users con el Access Level equivocado, asociaciones multilingües perdidas o registros de extensiones desconectados del componente responsable.
La prueba representativa demuestra el modelo de relaciones y el método de evidencia. No necesita demostrar todo el volumen, pero debe ser suficientemente amplia para que los responsables de contenido, acceso, idiomas, presentación y extensiones puedan reproducir la revisión.
Valide Articles, Categories, Tags, Fields y contenido del núcleo
Los Articles de Joomla deben conservar título, alias, contenido, estructura intro/full text cuando corresponda, estado, condición de featured, autor, fechas, Category, idioma, Access Level, Tags, Custom Fields, metadatos, imágenes y enlaces. Categories tiene su propia jerarquía, acceso, idioma, metadatos y layouts públicos.
| Evidencia del núcleo | Pass | Watch | Block |
|---|---|---|---|
| Article | Contenido, estado, autor, Category, idioma, acceso, metadatos y medios son coherentes. | Queda un ajuste menor de formato o metadatos opcionales. | Falta un Article prioritario, no puede accederse a él o está asignado al contexto equivocado. |
| Category | Jerarquía, idioma, acceso, descripción, metadatos y pertenencia de Articles son correctos. | Queda una limpieza de orden de baja prioridad. | Una familia de contenido prioritaria no puede encontrarse o queda expuesta incorrectamente. |
| Tag | Los términos y asignaciones permiten la exploración prevista entre Categories. | Queda una normalización no crítica. | Una clasificación o filtro necesario no puede utilizarse. |
| Custom Field | Grupo, tipo, valor, contexto de presentación y Template o extensión consumidora son correctos. | Queda un refinamiento opcional de presentación. | Se pierde un campo necesario para la operación o la parte pública. |
| Medio | Las imágenes y archivos se resuelven desde Articles, Categories, Fields y Modules. | Pies de imagen secundarios o tamaños necesitan ajuste. | Falta un medio prioritario o apunta al registro equivocado. |
Categories y menús de Joomla no son la misma jerarquía. Una Category puede obtener Pass mientras su Menu Item público falta o está mal configurado. A la inversa, un Menu Item puede cargar una página aunque la Category subyacente incluya los Articles equivocados. Valide por separado las estructuras de datos y de rutas.
Incluya ejemplos archivados, no publicados, featured, programados y restringidos por acceso cuando existan esos estados. Los administradores deben poder filtrar y editar los registros en las vistas de gestión previstas, mientras los visitantes solo deben ver los registros destinados a su idioma y contexto de acceso. Esto evita que una muestra de página pública oculte defectos administrativos o del ciclo de vida.
Valide menús, aliases, rutas, redirecciones y contexto de inicio
Las rutas de Joomla dependen en gran medida de Menu Items. Un Menu Item puede apuntar a un Article, Category Blog, Category List, vista de componente, URL externa u otra ruta. También puede controlar alias, jerarquía superior, idioma, acceso, estado de inicio predeterminado, estilo de Template y parámetros de layout.
| Evidencia de ruta | Comprobación necesaria |
|---|---|
| Elemento directo a Article | El Article previsto se abre mediante el alias, idioma, acceso y contexto de Template aprobados. |
| Category Blog o List | La Category y el alcance de subcategories correctos producen los Articles y el orden previstos. |
| Vista de componente | El Menu Item apunta al componente, vista y contexto de registro correctos. |
| Menú padre-hijo | Jerarquía, orden, etiquetas, acceso y estados activos permiten la navegación prevista. |
| Elemento de inicio | Existe el elemento predeterminado correcto para cada idioma y contexto de sitio aplicable. |
| Redirección | Las rutas antiguas de alto valor llegan a rutas aprobadas de Joomla sin bucles ni destinos en el idioma equivocado. |
| Enlace interno | Enlaces de Articles, Modules, Fields y extensiones ya no dependen de aliases o IDs obsoletos del origen. |
Una ruta no debe obtener Pass simplemente porque devuelve una página. La página debe mostrar la salida de componente, contexto de Article o Category, idioma, regla de acceso, metadatos, Modules y estilo de Template previstos.
Pruebe las rutas desde más de un punto de entrada: URL directa, navegación de menú, enlace interno desde Article, enlace de Module, selector de idioma y resultado de búsqueda cuando corresponda. Joomla puede generar Itemid y contexto de Modules diferentes para el mismo registro de componente, por lo que la evidencia debe confirmar que la ruta aprobada también carga la composición de página y los metadatos previstos.
Valide Users, Groups, permisos y Viewing Access Levels
La autorización de Joomla combina Users, User Groups jerárquicos, permisos de acciones y Viewing Access Levels. La validación debe distinguir lo que un User puede hacer del contenido que puede ver.
| Evidencia ACL | Pass | Watch | Block |
|---|---|---|---|
| Identidad de User | Estado de cuenta, nombre de usuario o correo, campos de perfil e ID externo necesario son correctos. | Queda una limpieza menor del perfil. | Users necesarios no pueden acceder al sitio o se duplican incorrectamente. |
| Pertenencia a Groups | Users representativos pertenecen a los Groups previstos y se comprende la jerarquía heredada. | Queda una limpieza no crítica de Groups. | Un User recibe autoridad heredada incorrecta. |
| Permisos de componente | Users pueden crear, editar, publicar, eliminar, configurar o administrar solo según lo previsto. | Queda un refinamiento documentado que no bloquea. | Es posible una administración no autorizada o el personal necesario no puede operar. |
| Viewing Access | Articles, Menu Items, Categories, Modules y registros de componentes son visibles únicamente para los Groups aprobados. | Queda un ajuste de visibilidad de baja prioridad. | El contenido restringido queda expuesto o se oculta contenido necesario. |
| Perfil de extensión | Registros de comercio, membresía, directorio u otros componentes siguen vinculados al User de Joomla previsto. | Queda una limpieza opcional de metadatos históricos. | La identidad o derecho de la aplicación queda desconectado. |
Utilice Users con Groups superpuestos y Users que dependen de pertenencia heredada. Copiar una etiqueta de rol no demuestra permisos equivalentes. La evidencia debe mostrar las acciones y la visibilidad realmente disponibles para el User.
Registre evidencia positiva y negativa. Un User que debe editar un Article tiene que poder hacerlo, mientras otro User similar que no pertenezca al Group autorizado debe recibir denegación. Repita el mismo patrón para la visualización en la parte pública. Esta evidencia emparejada es más fiable que inspeccionar solamente asignaciones de Groups, porque permisos heredados y asignaciones de Access Levels pueden producir resultados inesperados.
Valide contenido multilingüe y asociaciones
Los sitios Joomla multilingües necesitan evidencia consciente del idioma para contenido, Categories, menús, Modules, elementos de inicio, aliases y asociaciones. Un Article traducido puede existir y aun así el selector de idioma, el Menu Item asociado o la página de inicio específica del idioma puede llevar a otro lugar.
| Evidencia multilingüe | Comprobación necesaria |
|---|---|
| Asignación de idioma | Cada registro prioritario utiliza el idioma previsto o el alcance aprobado para todos los idiomas. |
| Asociaciones de Articles y Categories | Los registros equivalentes entre idiomas están conectados correctamente. |
| Estructura de menús | Cada idioma expone el árbol de menús y el elemento de inicio predeterminado previstos. |
| Asignación de Modules | Modules específicos de idioma aparecen únicamente en el contexto previsto. |
| Alias y ruta | Las rutas por idioma no colisionan y los enlaces llegan a la traducción correcta. |
| Acceso y metadatos | Acceso, títulos, descripciones e intención canónica por idioma permanecen coherentes. |
Un conjunto de idiomas debe probarse como un recorrido completo del visitante, no como registros traducidos aislados. Incluya página de inicio, navegación, Article o ruta de componente prioritaria, cambio de idioma y ruta de regreso. Una asociación ausente puede ser Watch para contenido de poco valor, pero se convierte en Block cuando rompe un recorrido necesario de cliente, legal o comercial.
El conjunto de evidencias debe incluir registros sin traducción y registros asignados deliberadamente a todos los idiomas. Estos casos no deben tratarse como equivalentes. Un Article de baja prioridad sin traducción puede quedar como Watch, mientras una traducción legal, de cuenta o comercial ausente puede bloquear el lanzamiento del idioma afectado. Documente el fallback o la exclusión previstos en lugar de asumir que el idioma predeterminado es aceptable.
Valide Modules, Templates, sobrescrituras y composición de página
Una página Joomla puede combinar una vista de componente con varios Modules asignados por posición, Menu Item, idioma, Access Level y estado de publicación. Los estilos de Template y sobrescrituras de layout pueden cambiar cómo se presenta el mismo contenido. La validación debe identificar qué partes proceden de registros migrados y cuáles corresponden a implementación de la tienda de destino.
| Evidencia de composición de página | Pass | Watch | Block |
|---|---|---|---|
| Salida del componente | El Article, Category o vista de extensión principal muestra los registros previstos. | Queda un ajuste menor de layout. | La página muestra el componente o contexto de registro equivocado. |
| Asignación de Module | Los Modules necesarios aparecen en posición, menú, idioma y contexto de acceso correctos. | Queda una limpieza de posición no crítica. | Falta un Module necesario para navegación, inicio de sesión, legal o comercio. |
| Estilo de Template | El estilo previsto se aplica al Menu Item o área del sitio correspondiente. | Queda pulido visual. | La página se vuelve inutilizable u oculta contenido crítico. |
| Sobrescritura | La salida de destino admite los datos y la acción necesarios. | Hay una sustitución documentada pendiente. | Una vista crítica pierde campos o interacción porque la sobrescritura anterior ya no se aplica. |
| Page builder | El contenido incluido puede editarse y produce un resultado público aprobado. | Queda refinamiento manual. | Una página prioritaria está vacía, rota o atrapada en datos de extensión inutilizables. |
La validación no debe prometer una reconstrucción completa de Templates salvo que esté incluida en el alcance. Debe demostrar que las páginas prioritarias tienen un resultado aprobado y utilizable, y que los defectos de migración están separados de las tareas de implementación del destino.
Utilice páginas prioritarias con distintos Menu Items, Access Levels, idiomas y estilos de Template. Un Module puede estar publicado y aun así fallar porque su asignación a menú, posición, idioma o regla de acceso es incorrecta. Cuando no se conserva una sobrescritura, la evidencia debe mostrar la presentación aprobada en el destino y confirmar que los campos y acciones necesarios siguen disponibles.
Valide por separado los registros pertenecientes a extensiones y comercio
Las extensiones de Joomla pueden ser responsables de Products, Customers, Orders, suscripciones, reservas, formularios, eventos, directorios, membresías, descargas, datos de page builders y referencias a sistemas externos. Estos registros pueden utilizar Users, Categories, Tags, Fields o Menu Items del núcleo y seguir conservando sus propias tablas y reglas.
| Área de extensión | Evidencia necesaria | Señal para la decisión de lanzamiento |
|---|---|---|
| Componente comercial | Estructura de Products, Categories, opciones, precios, inventario, Customers, Orders, rutas y campos de extensión | Block cuando un Product prioritario o un Order histórico no puede interpretarse. |
| Extensión de membresía o acceso | Relación con User, plan, estado, fechas, contenido protegido e historial de pagos cuando esté incluido | Block cuando un derecho activo es incorrecto. |
| Componente de formularios | Definición del formulario, Fields, envíos cuando estén incluidos, enrutamiento y notificaciones | Block cuando un formulario necesario o historial acordado no puede utilizarse. |
| Componente de eventos, reservas o directorio | Registro principal, propiedad, fechas, ubicaciones, participantes y vista pública | Block cuando una obligación activa o ruta de descubrimiento es incorrecta. |
| Page builder | Registros de página, bloques, medios y contexto de edición | Watch o Block según importancia de la página y resultado aprobado. |
| Tabla personalizada o integración | Clave padre, ID externo, transformación y consumidor de destino | Block cuando un proceso acordado no puede leer el resultado. |
| Salida de migración aprobada | Resultado de mapeo, filtrado o configuración compatible adquirido | Comparar con el requisito seleccionado y el destino esperado en Joomla. |
| Salida de migración no estándar | Entidad, relación, transformación o identificador externo personalizados aprobados | Comparar con la evidencia de aceptación acordada. |
Los registros comerciales no deben validarse como Users o Articles ordinarios de Joomla. El componente responsable de Products, Customers y Orders determina la evidencia. Un User de Joomla puede estar relacionado con un Customer, pero el User por sí solo no demuestra historial comercial ni funcionamiento de la cuenta.
El responsable de la extensión debe participar en la decisión cuando los registros crean obligaciones activas o acceso restringido. Valide tanto el registro administrativo como el resultado público o de cara al User. Un Product, reserva, membresía o envío de formulario que aparezca en una tabla pero no pueda encontrarse, editarse o reconciliarse desde el componente de destino no debe obtener Pass.
Valide la ejecución amplia de la migración y las acciones posteriores
La ejecución amplia de la migración debe demostrar cobertura completa de contenido, estados, idiomas, acceso, menús, extensiones y excepciones. Reconcile totales por tipo de contenido, Category, idioma, estado, Access Level, User Group, menú y entidad de extensión incluida. Investigue exclusiones deliberadas, defectos del origen, aliases duplicados, medios huérfanos, asociaciones rotas y registros que necesitan implementación separada.
La actividad posterior requiere revalidación específica de la acción:
| Acción posterior | Evidencia de Joomla que debe repetirse |
|---|---|
| continuar con la configuración aceptada | Confirmar que nuevos Articles, Users, medios y registros de extensiones conservan las mismas Categories, idiomas, acceso, rutas y relaciones de campos. Volver a comprobar colisiones con cambios de la tienda de destino y aliases recién creados. |
| continuar con una configuración revisada | Revalidar cada selección modificada de tipo de datos, mapeo de Category o Fields, regla de User, regla de idioma, decisión de extensión, regla de ruta y filtro. |
| generar un resultado de migración nuevo y distinto | Tratar el resultado como independiente. Repetir la evidencia de contenido, ACL, multilingüe, composición de página, extensiones y decisión de lanzamiento. |
La revisión de volumen completo también debe comparar la distribución de registros, no solo los totales. Los recuentos por idioma, Access Level, Category, estado, User Group y tipo de extensión pueden revelar clasificaciones erróneas que un único total general oculta. Los registros de excepciones deben indicar si una diferencia es intencional, un defecto del origen, una decisión de reestructuración del destino o un problema de migración sin resolver.
Construya el registro de decisión de lanzamiento de Joomla
El registro final de evidencias debe identificar:
- el Article, Category, Menu Item, User Group, Access Level, idioma, Module, estilo de Template, componente o ruta probado;
- los identificadores de origen y destino utilizados para la reconciliación;
- el resultado esperado y la evidencia observada;
- la decisión Pass, Watch o Block;
- el responsable de la corrección o tarea de implementación del destino;
- si el problema afecta al lanzamiento, a actividad posterior de migración o a limpieza que no bloquea;
- la evidencia necesaria para cerrar el hallazgo.
Un Pass exige contenido prioritario utilizable, rutas correctas, acceso controlado, recorridos coherentes por idioma, composición de página aprobada y propiedad explícita de registros de extensiones. Un elemento Watch tiene un responsable identificado y no compromete esos resultados. Un Block permanece cuando contenido importante es inaccesible, datos restringidos quedan expuestos, falla un recorrido de idioma, no puede componerse una página crítica o una salida acordada de una extensión no puede utilizarse.
Conclusión
La validación de Joomla debe demostrar las relaciones entre Articles, Categories, menús, aliases, rutas, Users, Groups, permisos, Access Levels, idiomas, Modules, Templates y registros de extensiones. La presencia de registros no demuestra que el sitio funcione dentro del contexto previsto de página, público, idioma o componente.
Las pruebas representativas demuestran el modelo de relaciones. La ejecución amplia de la migración demuestra que el alcance está completo y que las excepciones se controlan. Las acciones posteriores requieren revalidación focalizada o completa según la acción seleccionada. La aprobación para lanzamiento depende de evidencia reproducible y decisiones explícitas Pass, Watch o Block.
Preguntas frecuentes
¿Por qué se validan por separado Categories y menús de Joomla?
Categories organiza el contenido, mientras Menu Items define rutas públicas, layouts, jerarquía, acceso, idioma y contexto de Template. Uno puede ser correcto mientras el otro lleva a los visitantes al resultado equivocado.
¿Cómo debe validarse el control de acceso de Joomla?
Utilice Users representativos de cada Group relevante y pruebe tanto las acciones permitidas como el acceso de visualización. Los nombres de Groups por sí solos no demuestran permisos heredados ni los Access Levels asociados a Articles, menús, Modules y registros de componentes.
¿Qué hace que la validación multilingüe de Joomla esté completa?
Valide asignaciones de idioma, Articles y Categories asociados, menús y elementos de inicio específicos de idioma, Modules, aliases, metadatos y un recorrido completo del visitante mediante el selector de idioma.
¿Deben comprobarse los registros de extensiones como Articles o Users de Joomla?
No. Valídelos a través del componente responsable de sus Fields, relaciones, rutas y procesos. Articles y Users del núcleo pueden participar, pero no sustituyen a la entidad de la extensión.
¿Cómo deben afectar las diferencias de Templates o page builders a las decisiones de lanzamiento?
Clasifique si el problema corresponde a contenido migrado, implementación de destino o una salida personalizada acordada. Utilice Watch para trabajos identificados que no bloquean y Block cuando una página prioritaria no puede utilizarse o mantenerse.
¿Qué debe revalidarse después de actividad posterior de migración en Joomla?
Vuelva a comprobar Articles, Categories, menús, aliases, Users, acceso, idiomas, medios, registros de extensiones, redirecciones y colisiones con cambios de la tienda de destino. Una configuración nueva o una nueva migración requiere evidencia más amplia que continuar con la configuración sin cambios.