Joomla no representa un sitio web como una única colección de páginas y tampoco ofrece un esquema comercial universal. Su modelo de datos separa registros de contenido, árboles de Categories, rutas de menús, módulos, asignaciones de plantillas, usuarios, controles de acceso, idiomas, medios, campos personalizados y entidades pertenecientes a extensiones. Por eso, una página que parece sencilla en el navegador puede depender de varios registros con responsabilidades diferentes.
Cuando Joomla es la plataforma de destino, la planificación debe trasladar relaciones, no limitarse a copiar campos de texto. Un Article puede contener el contenido principal, mientras un Menu Item determina la ruta pública, una Category aporta contexto organizativo, un Access Level controla la visibilidad, un Module aporta contenido complementario y una extensión controla el proceso empresarial detrás de la página. Conservar únicamente el cuerpo visible puede dejar registros que existen en el destino, pero que ya no conservan el mismo significado de navegación, permisos, idioma o aplicación.
Joomla separa contenido, enrutamiento, presentación y datos de aplicaciones
Joomla core proporciona estructuras reutilizables, pero cada una tiene una responsabilidad distinta. Articles y otros registros de componentes contienen contenido. Categories agrupa registros dentro del componente que las controla. Menus crea navegación ordenada y relaciones de rutas. Modules coloca contenido reutilizable alrededor de una página. Templates y sobrescrituras determinan la presentación. Users, groups y access levels controlan identidad y visibilidad. Components, plugins y código personalizado añaden registros específicos de aplicaciones.
| Capa de Joomla | Significado principal | Consecuencia para la migración |
|---|---|---|
| Articles y registros de componentes | Contenido editable o registros pertenecientes a una aplicación | El destino debe identificar al responsable real del registro en lugar de tratar cada página visible como un Article. |
| Categories | Agrupación jerárquica dentro de un componente concreto | Una Category de contenido y una Category comercial pueden tener etiquetas similares y pertenecer a particiones de datos diferentes. |
| Menus y Menu Items | Navegación, ruta, alias, idioma, acceso y contexto de página | Las URL públicas y puntos de entrada pueden depender de relaciones de Menu Items y no solo de títulos de Articles. |
| Modules | Bloques reutilizables asignados a posiciones y páginas | El contenido complementario puede necesitar su propio registro de destino y relación de ubicación. |
| Templates y sobrescrituras | Diseño y salida renderizada | Son recursos de presentación, no sustitutos del contenido migrado ni de datos de aplicaciones. |
| Users, groups y access levels | Identidad, permisos y visibilidad | Una cuenta Joomla no puede interpretarse automáticamente como Customer comercial o segmento empresarial. |
| Components, plugins y tablas personalizadas | Funcionamiento y registros específicos de dominio | Comercio, membresías, formularios, directorios, descargas e integraciones necesitan interpretación según su responsable. |
Este modelo por capas es la diferencia central de Joomla en una migración. El mismo campo de origen puede convertirse en contenido del núcleo, un parámetro de Menu Item, un campo personalizado, un registro de componente, una relación de usuario o un requisito de implementación del destino según la función que desempeñe.
Articles, Categories y Menu Items contienen relaciones diferentes
Un Article es un registro de contenido. Una Category agrupa registros pertenecientes al mismo componente de Joomla. Un Menu Item es un registro de navegación y enrutamiento que puede apuntar a un Article, una vista de Category, un componente de terceros, un enlace del sistema u otro destino. Estos objetos pueden describir una misma página pública, pero no son intercambiables.
Las Categories de Joomla son conscientes del componente al que pertenecen. El árbol de Categories utilizado por el contenido principal está separado de las particiones de Categories utilizadas por otros componentes compatibles con Categories de Joomla. Esto importa cuando la plataforma de origen posee una taxonomía universal. Una "Category" del origen puede necesitar convertirse en Category de contenido, Category de una extensión comercial, etiqueta, rama de menú o varios registros coordinados.
Los Menu Items contienen información estructural que los registros de contenido no contienen. Sus alias pueden formar rutas URL; las relaciones padre-hijo crean árboles de menús; idioma y acceso determinan disponibilidad; las referencias de componentes identifican la vista que se abre; y asignaciones de estilos de plantilla pueden cambiar la presentación de una ruta concreta.
| Concepto de origen | Posible representación en Joomla | Significado que debe permanecer explícito |
|---|---|---|
| Página editorial | Article más uno o varios Menu Items | El Article controla el contenido; el Menu Item controla el punto de entrada navegable y el contexto de ruta. |
| Página de destino de una Category de Products | Category comercial más Menu Item de Joomla | La agrupación comercial y la navegación pública siguen siendo relaciones separadas. |
| Sección de biblioteca de recursos | Category, Articles etiquetados, Menu Item y Modules | Clasificación, contenido, ruta y presentaciones complementarias pueden tener responsables diferentes. |
| Alias de URL directa | Alias de Menu Item, salida del enrutador del componente o registro de redirección | La ruta pública no puede deducirse de forma segura únicamente del título. |
| Página de destino oculta | Registro publicado sin entrada visible de menú, o Menu Item oculto | Visibilidad en navegación no equivale a estado de publicación ni disponibilidad de URL. |
Por tanto, el modelo de destino debe conservar tanto la identidad del registro como la identidad de la ruta. Fusionarlas demasiado pronto puede romper alias, rutas padre, puntos de entrada por idioma, breadcrumbs, funcionamiento del acceso o enlaces desde otros contenidos.
Modules, Templates y sobrescrituras no son cuerpos de página
Joomla compone las páginas con más elementos que la salida principal del componente. Modules puede aportar navegación, banners, formularios, búsqueda, acceso a cuentas, cambio de idioma, contenido relacionado, HTML personalizado o bloques específicos de extensiones. Su significado depende del tipo de módulo, posición, estado de publicación, idioma, acceso y asignación a Menu Items.
Una plataforma de origen puede almacenar todo el contenido de una página en un único registro de diseño, mientras Joomla divide el resultado entre un Article o vista de componente y varios Modules. También puede ocurrir lo contrario: una página Joomla compuesta por múltiples Modules puede necesitar convertirse en una página estructurada única en otra plataforma de destino. El modelo de migración debe decidir si un Module sigue siendo un bloque reutilizable, se integra en el contenido, se corresponde con un widget de destino o forma parte de una implementación de diseño separada.
Templates y sobrescrituras de diseño constituyen otro límite de responsabilidad. Un estilo de Template puede asignarse mediante Menu Items y una sobrescritura puede cambiar cómo se presenta un componente o módulo sin modificar el registro subyacente. Los datos de Product, Article, Customer u Order pueden seguir siendo migrables aunque la salida anterior no pueda reproducirse como datos.
| Objeto de presentación de Joomla | Qué controla | Qué no controla |
|---|---|---|
| Module | Registro de presentación reutilizable y contexto de asignación | El registro empresarial principal mostrado por un componente |
| Posición de Module | Identificador de ubicación esperado por una Template | El contenido almacenado dentro del Module |
| Estilo de Template | Configuración visual y de diseño para rutas seleccionadas | Significado de Article, Product, Customer u Order |
| Sobrescritura de diseño | Lógica de presentación modificada | Un registro portátil de destino por defecto |
| Module de HTML personalizado | Contenido reutilizable fuera de un Article | La ruta completa de la página o el funcionamiento de una aplicación |
Mantener estos límites explícitos evita confundir recursos de presentación con contenido ausente y evita que los registros empresariales queden ocultos dentro de una discusión sobre reconstrucción visual.
Users, groups, access levels y Customers son conceptos separados
Un Joomla User es principalmente una identidad que puede iniciar sesión en el sitio o en la administración. La cuenta puede contener nombre de usuario, correo electrónico, estado, preferencias, pertenencia a grupos y contexto de permisos. El control de acceso de Joomla separa después lo que un usuario puede ver de las acciones que puede realizar.
Este modelo no equivale a un modelo de Customer comercial. Una extensión de comercio puede conectar sus registros de Customer, direcciones, grupos de compradores, suscripciones, membresías u Orders con un ID de Joomla User, pero esos registros siguen perteneciendo a la extensión. Un Joomla User registrado puede no haber comprado nunca, mientras un Order de invitado puede contener datos del comprador sin una cuenta Joomla persistente.
| Registro relacionado con identidad | Significado en Joomla | Desajuste habitual con el modelo de origen |
|---|---|---|
| User | Identidad de inicio de sesión y atributos principales de cuenta | Se trata como perfil completo de Customer aunque los datos comerciales vivan en otro lugar |
| User group | Agrupación de permisos utilizada por Joomla ACL | Se confunde con segmento de marketing, grupo de precios o empresa B2B |
| Viewing Access Level | Define qué grupos pueden ver un elemento | Se simplifica a público/privado y se pierden reglas de visibilidad por capas |
| Permisos de administrador | Acciones que puede realizar un usuario en un componente | Se confunden con el estado de una cuenta en la tienda |
| Customer de extensión | Registro de comprador o miembro vinculado a Joomla User cuando corresponde | Se pierde cuando solo se trasladan las tablas principales de Users |
| Comprador invitado | Datos históricos del comprador almacenados con un Order | Se fuerza incorrectamente a una cuenta persistente de Joomla User |
La relación en el destino debe conservar la distinción entre identidad, autorización, perfil de comprador, dirección, organización y propiedad de transacciones históricas. Fusionar estos conceptos puede exponer contenido restringido, eliminar accesos legítimos, duplicar Customers o separar Orders de la identidad histórica correcta.
Campos personalizados, etiquetas, medios y metadatos añaden significado estructurado
Los campos personalizados de Joomla pueden adjuntar valores estructurados a tipos de registros compatibles como Articles, Users o Contacts. Su función empresarial varía ampliamente: etiquetas editoriales, especificaciones técnicas, datos de directorio, identificadores externos, atributos de miembros, claves de integración o contenido estructurado de páginas. La etiqueta del campo no determina por sí sola la representación de destino.
Tags aporta clasificación flexible entre Categories. Los registros y rutas de medios pueden utilizarse para imágenes integradas, galerías, descargas, documentos o recursos de extensiones. Los metadatos pueden existir en Articles, Categories, Menu Items o registros de extensiones y afectar snippets de búsqueda, compartición, indexación y decisiones de enrutamiento.
| Área de datos | Pregunta sobre la relación | Interpretación en el destino |
|---|---|---|
| Campo personalizado | ¿Qué componente y tipo de registro controlan el valor? | Correspondencia con campo nativo del destino, elemento de contenido estructurado, campo de extensión o relación con datos externos. |
| Tag | ¿Representa navegación, filtrado, lógica de contenido relacionado o anotación editorial? | Conservar únicamente la relación empresarial que realmente desempeña. |
| Recurso multimedia | ¿Qué registros reutilizan el recurso y la ruta está integrada en el contenido? | Mantener relaciones de adjunto y reutilización, no copiar archivos sin sus referencias. |
| Metadatos | ¿El valor pertenece a contenido, ruta, Category o componente? | Asociarlo al objeto de destino que controla la salida pública equivalente. |
| Identificador externo | ¿Qué sistema utiliza el valor como clave? | Mantener el identificador estable y asociado a la entidad correcta del destino. |
Una correspondencia de campos que ignore la responsabilidad del componente puede colocar un valor válido en el objeto incorrecto. El destino puede mostrar el valor y aun así perder filtrado, integración, acceso o funcionamiento de edición.
Los datos multilingües utilizan idiomas, asociaciones, rutas y soporte de extensiones
Joomla distingue entre traducción de interfaz e idioma del contenido. Los registros de contenido pueden tener asignaciones de idioma y las asociaciones multilingües conectan registros equivalentes entre idiomas. Las estructuras de menús, páginas predeterminadas, alias, Modules, Categories y registros de extensiones también pueden variar por idioma.
Una plataforma de origen que almacena traducciones como columnas de un único registro puede necesitar varios registros asociados en Joomla. Otro origen puede usar ya registros separados, pero carecer de asociaciones al estilo Joomla. Las extensiones pueden implementar campos multilingües mediante soporte de idiomas del núcleo, sus propias tablas o sistemas de traducción de terceros.
| Elemento multilingüe | Significado en el modelo de datos |
|---|---|
| Idioma del contenido | Identifica el idioma asignado a un registro de contenido o componente |
| Asociación de idioma | Conecta registros equivalentes sin convertirlos en un solo registro |
| Menu Item específico de idioma | Proporciona ruta y contexto de navegación para un idioma |
| Module específico de idioma | Proporciona contenido complementario en rutas de un idioma seleccionado |
| Registro de traducción de extensión | Almacena datos comerciales o de aplicación traducidos según el diseño de la extensión |
| Language override | Cambia texto de interfaz en lugar de migrar contenido empresarial |
El modelo de destino debe diferenciar contenido empresarial traducido de cadenas de interfaz y relaciones de rutas. Conservar texto sin asociaciones puede crear páginas aparentemente duplicadas que no están conectadas como equivalentes lingüísticos. Conservar asociaciones sin el contexto correspondiente de menús y Modules puede dejar una rama de idioma incompleta.
Las extensiones definen los límites del comercio electrónico y otras aplicaciones
Joomla core no define Products, carritos, Customers, Orders, suscripciones, eventos, directorios o registros de marketplace nativos. Estas entidades pertenecen a componentes instalados o aplicaciones personalizadas. Por tanto, dos sitios Joomla pueden mostrar tiendas similares mientras almacenan datos comerciales en tablas y relaciones totalmente diferentes.
La extensión responsable determina tipos de Product, estructura de Categories, funcionamiento de opciones o variantes, precios, stock, vínculo con Customers, líneas de Orders, historial de estados, referencias de pagos, referencias de envíos, campos personalizados e identificadores de integración. Plugins y Modules pueden añadir registros adicionales o cambiar la interpretación.
| Concepto comercial | Posición en Joomla core | Responsable real de los datos |
|---|---|---|
| Product y elección vendible | No existe un esquema universal de Product en core | Componente comercial y sus extensiones |
| Customer y dirección | Core User puede aportar únicamente identidad | Componente comercial, componente de membresía o aplicación personalizada |
| Order y línea de Order | No existe un esquema universal de Order en core | Componente comercial o sistema externo de Orders |
| Grupo de precios o regla B2B | No equivale por defecto a Joomla User groups | Extensión comercial, plugin de precios o sistema externo |
| Campo del proceso de compra | No es por defecto un campo de core User | Componente comercial, plugin de formularios o tabla personalizada |
| Referencia de pago y envío | Contexto histórico almacenado por el responsable comercial | Componente comercial más plugin de pasarela o transportista |
Por este motivo, "datos de Joomla" no es una definición suficiente de alcance. El inventario de migración debe identificar Components, plugins, Modules, tablas personalizadas y sistemas externos responsables de registros comercialmente importantes.
Las implementaciones personalizadas y los identificadores externos requieren un mapa de responsabilidad
Los sitios Joomla con una larga trayectoria suelen contener Components personalizados, tablas de extensiones modificadas, sobrescrituras de plantillas, plugins de eventos, tareas programadas, integraciones API y relaciones directas de base de datos. Algunos valores personalizados son solo de presentación; otros son claves empresariales autoritativas.
El mapa de responsabilidad más útil identifica el registro, su responsable de tabla o API, entidad principal, sistema externo que lo consume y objeto de destino que debe llevar el valor. Esto es especialmente importante para IDs de ERP, CRM, referencias documentales, estados de membresía, IDs de vendedores de marketplaces, claves de procesamiento de pedidos y marcas de tiempo de sincronización.
| Señal de responsabilidad | Por qué cambia la migración |
|---|---|
| Tabla personalizada con claves foráneas a Users o Articles principales | El registro empresarial puede desaparecer si solo se interpretan las tablas de Joomla core. |
| Campo creado por plugin o registro de evento | El valor puede depender del funcionamiento del plugin y no de un campo nativo del destino. |
| Identificador reutilizado por un sistema externo | Regenerar IDs puede romper reconciliación o sincronización. |
| Sobrescritura que lee columnas no estándar | La página visible puede depender de datos no expuestos en pantallas ordinarias del componente. |
| Varias extensiones utilizan el mismo User | La identidad debe seguir compartida mientras cada perfil perteneciente a extensión permanece separado. |
El destino no necesita reproducir todos los detalles de implementación de Joomla. Sí necesita una representación deliberada de cada relación que contenga significado empresarial, de acceso, contenido o integración.
Conclusión
Una migración de Joomla es fundamentalmente una traslación entre capas. Articles, Categories, Menu Items, Modules, Templates, Users, access levels, idiomas, campos personalizados, medios, extensiones y sistemas externos controlan partes distintas del significado del sitio.
Un modelo de destino coherente conserva estos límites de responsabilidad antes de decidir cómo se representarán los registros. Así mantiene el contenido conectado a las rutas, las identidades conectadas a los permisos, las traducciones conectadas a la estructura de idiomas, los registros comerciales conectados a la extensión que los controla y los identificadores externos conectados a los sistemas que dependen de ellos.
Preguntas frecuentes
¿Joomla proporciona un modelo nativo de Products y Orders?
No. Joomla core proporciona contenido, identidad, acceso, enrutamiento e infraestructura de extensiones, pero Products y Orders pertenecen a un componente comercial o aplicación personalizada. Su significado para la migración debe derivarse del esquema de ese responsable.
¿Las Categories de Joomla son lo mismo que los Menu Items?
No. Categories agrupa registros dentro de un componente, mientras que Menu Items crea navegación y relaciones de rutas. Una página pública de Category puede depender de ambos objetos, pero deben permanecer separados en el modelo de destino.
¿Puede cada Joomla User migrarse como Customer?
No. Un Joomla User es una identidad de inicio de sesión y sujeto de permisos. Customers comerciales, direcciones, membresías y Orders pueden ser registros separados pertenecientes a extensiones vinculados a esa identidad, y los compradores invitados pueden no tener ninguna cuenta Joomla User.
¿Cómo deben representarse Modules y sobrescrituras de Templates?
Los Modules deben clasificarse por su contenido reutilizable y relaciones de asignación. Templates y sobrescrituras pertenecen normalmente a la implementación de presentación, no a la migración de registros empresariales, aunque el contenido almacenado dentro de Modules personalizados debe seguir contabilizándose.
¿Qué hace que los datos multilingües de Joomla sean sensibles a las relaciones?
Las asignaciones de idioma, registros asociados, Menu Items específicos por idioma, Modules, alias y traducciones de extensiones pueden contribuir a una única experiencia lingüística. El texto traducido por sí solo no conserva esas relaciones.
¿Cuándo necesitan los datos personalizados de Joomla un diseño de destino separado?
Se necesita un diseño separado cuando valores importantes viven en tablas personalizadas, campos de extensiones, registros de plugins, sobrescrituras o integraciones externas sin una entidad estándar equivalente en el destino. El diseño debe conservar el significado empresarial y la responsabilidad en lugar de copiar ciegamente el patrón de almacenamiento del origen.