J2Store integra el comercio electrónico dentro de Joomla en lugar de concentrar todos los valores comerciales en un único objeto Product independiente. Los artículos de Joomla pueden actuar como Products, mientras que las Categories, alias, menús, usuarios, niveles de acceso, medios, módulos y plantillas de Joomla proporcionan gran parte del contexto de contenido y de la tienda online. J2Store añade después las relaciones de precio, SKU, stock, tipo de Product, opciones, Customers, proceso de compra y Orders que convierten el artículo en un elemento vendible.
J2Store es ahora un proyecto discontinuado cuyo repositorio está archivado, y J2Commerce es su sucesor activo. Este hecho de ciclo de vida no elimina el modelo de datos de las tiendas J2Store existentes. Hace todavía más importante interpretar correctamente el origen: los registros antiguos, aplicaciones, plugins, sobrescrituras y tablas personalizadas deben entenderse como evidencia empresarial heredada, no como estructuras que se supone que coincidirán con un destino actual.
La relación entre artículo y Product
La relación que define J2Store es la conexión entre un artículo de Joomla y sus datos comerciales. El artículo aporta la identidad de contenido; J2Store aporta la identidad de venta. Una migración que los separe puede producir Products duplicados, registros comerciales huérfanos o páginas de artículos que dejan de comportarse como Products.
| Función de negocio | Capa de Joomla | Capa de J2Store |
|---|---|---|
| Título y contenido detallado del Product | Título del artículo, cuerpo, metadatos, idioma y estado de publicación | El registro comercial hace referencia al elemento vendible |
| Agrupación de contenido | Category de Joomla, etiquetas y contexto de menú | Las listas de Products, filtros o lógica de aplicaciones pueden utilizar esa agrupación |
| Identidad comercial | Responsabilidad limitada del CMS | Tipo de Product, SKU, precio, impuestos, stock, peso y dimensiones |
| Elección del comprador | Se muestra mediante el artículo o la salida de la plantilla | Opciones, variantes, campos personalizados o registros pertenecientes a aplicaciones |
| Cuenta del comprador | Usuario y grupos de usuarios de Joomla | Customer, direcciones, campos del proceso de compra y Orders |
| URL de la tienda online | Alias, Category, elemento de menú, enrutador e idioma | El estado del Product determina si están disponibles los controles de compra |
El ID del artículo y la relación con el Product de J2Store deben tratarse como una única identidad lógica durante la migración. Conservar ambas tablas pero perder el vínculo no significa conservar la relación.
Tipos de Product, opciones y registros comerciales especializados
Las instalaciones de J2Store pueden representar modelos de venta simples, variables, configurables, descargables, virtuales, por suscripción, reservas, pagos parciales y otros patrones especializados. Algunos provienen de tipos de Product principales; otros dependen de aplicaciones o plugins. Las etiquetas visibles en la tienda no muestran necesariamente toda la estructura subyacente.
Antes de trasladarlo, un Product de origen debe dividirse en significados distintos:
| Elemento de origen | Posible responsable en J2Store | Pregunta para la migración |
|---|---|---|
| Nombre, descripción y medios integrados | Artículo de Joomla | ¿Qué contenido pertenece a la página canónica del Product? |
| SKU, precio, stock y peso | Product o registro de variante de J2Store | ¿El valor se comparte o pertenece a una elección concreta del comprador? |
| Talla, color, material o grabado | Opción, variante, contenido del artículo o registro de aplicación | ¿Cambia el SKU, el stock, el precio, el procesamiento del pedido o únicamente la presentación? |
| Archivo digital | Product descargable o relación de aplicación | ¿Qué estado de compra y Order concede el acceso? |
| Plan de suscripción | Product, plan, renovación y registros de acceso pertenecientes a una aplicación | ¿Qué relaciones recurrentes y de cuenta deben continuar? |
| Franja de reserva | Calendario, recurso, capacidad y registros de reserva pertenecientes a una aplicación | ¿Qué registro representa el servicio vendible y cuál representa la reserva? |
| Depósito o cuota | Registros del plan de pagos y saldos | ¿Cómo se conectan el total original, el importe pagado, el saldo restante y el estado? |
Una opción de Product no debe trasladarse basándose únicamente en su nombre. Un valor como "talla" puede ser una variante con stock propio, un modificador de precio, una dimensión descriptiva o un factor de envío. La estructura de destino debe seguir la función empresarial real.
Los registros especializados requieren especial atención porque las extensiones de J2Store pueden almacenar sus datos fuera de las tablas habituales de Products y Orders. Un Product de suscripción sin sus registros de plan y derechos de acceso se convierte en un Product ordinario de compra única. Un Product de reserva sin sus datos de reserva se convierte simplemente en una página que describe un servicio.
Categories, menús, módulos y rutas
La estructura de catálogo de J2Store depende en gran medida de Joomla. Una Category de origen puede tener varios significados posibles en el destino: clasificación de artículos, navegación del comprador, agrupación dinámica, entrada para filtros, límite de acceso o contexto de una página de destino.
| Estructura de origen | Relación con J2Store/Joomla | Significado que debe conservarse |
|---|---|---|
| Category de Product | Category de Joomla asignada a artículos de Product | Clasificación y navegación basada en Categories |
| Colección o departamento | Category, etiqueta, consulta de módulo, elemento de menú o regla de aplicación | La lógica de agrupación y la ruta de descubrimiento |
| Marca o fabricante | Campo de Product, etiqueta, Category, página de contenido o extensión | Presentación, filtro, ruta e identidad externa |
| Products destacados | Configuración de módulo o consulta de aplicación | La regla de selección, no una lista estática copiada |
| Catálogo restringido | Nivel de acceso, grupo de usuarios o extensión de Joomla | Qué usuarios pueden ver o comprar los Products |
| Página de campaña | Artículo de Joomla, elemento de menú, módulos y enlaces a Products | La composición del contenido y la ruta canónica |
El contexto de menú de Joomla influye en el enrutamiento. El mismo artículo puede aparecer mediante diferentes rutas de menú, rutas de Category o alias. La migración debe identificar el destino preferido del Product y diferenciarlo de las rutas alternativas que necesiten redirección o retirada.
Los módulos y las sobrescrituras de plantillas no son registros de Product. Pueden determinar qué Products aparecen, qué campos son visibles y cómo se muestran las opciones o los precios. Debe documentarse su dependencia de los identificadores migrados, pero su lógica de presentación sigue siendo una estructura separada del destino.
Customers, usuarios de Joomla y contexto de cuenta
Los datos de Customer en J2Store pueden abarcar usuarios de Joomla, grupos de usuarios, registros de Customer, direcciones, campos del proceso de compra y Orders históricos. Un correo electrónico de Customer no basta para reconstruir la relación de cuenta.
Un Customer registrado puede tener:
- un ID de usuario de Joomla y un estado de inicio de sesión;
- pertenencia a grupos de usuarios de Joomla;
- una o varias direcciones de facturación y envío;
- valores reutilizables de perfil o impuestos;
- campos personalizados de registro o del proceso de compra;
- Orders vinculados al usuario o al correo electrónico;
- registros de membresía, suscripción, recompensas o acceso pertenecientes a aplicaciones.
Un Order de invitado puede contener los mismos campos de contacto y dirección sin que exista un usuario persistente de Joomla. Crear una cuenta registrada para cada invitado histórico puede alterar el significado de la identidad y generar cuentas duplicadas o inaccesibles.
| Valor de Customer | Responsabilidad adecuada | Motivo |
|---|---|---|
| Nombre de inicio de sesión, correo electrónico y estado habilitado | Usuario de Joomla | Controla la identidad persistente de autenticación |
| Papel del grupo de usuarios | Relación con grupo de usuarios de Joomla | Puede controlar acceso, precios o funcionamiento de extensiones |
| Dirección reutilizable | Registro de Customer/dirección de J2Store | Pertenece al ciclo de vida del Customer |
| Instantánea de facturación y envío de invitado | Order histórico | Pertenece a una única transacción |
| Identificación fiscal o datos de empresa | Campo de Customer, dirección u Order según el uso | La responsabilidad depende de si el valor es reutilizable |
| Consentimiento de marketing o estado de membresía | Perfil de Joomla, extensión o sistema externo | Requiere identificar el sistema que consume el dato |
La gestión de contraseñas debe tratarse como un problema de identidad, no como un campo genérico de Customer. Que las credenciales sigan siendo utilizables depende de los modelos de autenticación de origen y destino y de la relación conservada con el usuario de Joomla.
Orders como evidencia histórica
Los Orders de J2Store conservan más que un total de cabecera. Pueden incluir instantáneas de Products y opciones, SKU, cantidades, precios unitarios, descuentos, cupones, impuestos, envíos, etiquetas de pago, direcciones, valores personalizados del proceso de compra, notas, estados y referencias pertenecientes a extensiones.
El Order histórico debe seguir siendo interpretable aunque el Product original cambie o una extensión deje de estar activa. Para ello, los valores capturados deben permanecer asociados al Order en lugar de reconstruirse únicamente a partir del catálogo actual.
| Relación del Order | Significado que debe conservarse |
|---|---|
| Order con Customer o invitado | Quién realizó el Order y si existía una cuenta persistente |
| Order con línea de pedido | Qué se compró, incluidas las opciones seleccionadas y el nombre/SKU registrado |
| Línea con precio y descuento | Cómo se formó el subtotal histórico |
| Order con impuestos y envío | Qué importes y etiquetas explican el total |
| Order con registro de pago | Método de pago histórico y referencia del proveedor cuando se conserven |
| Order con historial de estados | Interpretación operativa de la transacción a lo largo del tiempo |
| Order con registro de aplicación | Contexto de suscripción, reserva, acceso a archivos, cuotas o procesamiento del pedido |
Las etiquetas históricas de pago y envío no recrean el funcionamiento actual de una pasarela o transportista. Pertenecen al Order como evidencia. La configuración activa del proceso de compra pertenece al entorno de destino.
Relaciones de contenido, idioma, medios y SEO
Las páginas de Product de J2Store heredan las funciones de contenido de Joomla. Los artículos de Product pueden contener descripciones formateadas, medios integrados, campos personalizados, metadatos, alias, asignaciones de idioma, configuraciones de acceso y plugins de contenido. Una exportación de Products de origen puede no distinguir qué valores son contenido del Product y cuáles los genera una plantilla o extensión.
El modelo de destino debe clasificar los medios según su función:
- imagen integrada en el artículo;
- imagen principal del Product;
- imagen de galería del Product;
- imagen específica de una opción;
- archivo descargable;
- recurso de una página de destino o módulo.
Las relaciones de idioma también van más allá del texto traducido. Los sitios Joomla multilingües pueden utilizar artículos, Categories, menús, módulos y alias separados, además de asociaciones de idioma. El conjunto de traducciones debe permanecer conectado tanto en la capa de contenido como en la comercial.
La continuidad SEO depende de la relación entre alias de artículos, rutas de Categories, elementos de menú, funcionamiento del enrutador, metadatos y cualquier extensión de canonicals o redirecciones. Una URL de origen no debe convertirse automáticamente en un campo de alias si su ruta fue generada por una relación de menú o Category. El destino necesita un responsable canónico y una ruta de redirección definida para alternativas valiosas.
Aplicaciones, plugins, tablas personalizadas y sistemas externos
Las tiendas J2Store heredadas suelen estar determinadas por aplicaciones y plugins. Las extensiones de suscripciones, reservas, pagos parciales, recompensas, paquetes de Products, cargas de archivos, campos de proceso de compra, pagos, envíos, impuestos, informes e integraciones pueden crear registros fuera del modelo básico Product-Customer-Order.
| Dependencia | Registros ocultos o distribuidos | Requisito para la migración |
|---|---|---|
| Aplicación de suscripción o membresía | Planes, referencias de facturación, renovaciones, estados de acceso y grupos de usuarios | Conservar la relación entre Product, Customer, plan y derecho de acceso |
| Aplicación de reservas | Recursos, fechas, capacidad, reservas y asistentes | Diferenciar el Product vendible de la instancia reservada |
| Aplicación de pagos parciales | Planes de pago, cuotas, saldos y vínculos con transacciones | Mantener coherente la relación financiera |
| Campos personalizados del proceso de compra | Valores de Customer, valores de dirección, metadatos de Order y entradas de líneas | Asignar cada campo a su verdadero responsable durante el ciclo de vida |
| Plugin de pago o envío | Configuración, referencias de proveedor, etiquetas de método y estados personalizados | Separar la configuración activa de la evidencia histórica de Orders |
| Integración con ERP, CRM, contabilidad o almacén | IDs externos, estado de sincronización y tablas de correspondencia | Conservar claves duraderas e identificar la responsabilidad sobre la correspondencia |
| Sobrescritura de plantilla o módulo | Reglas de presentación y supuestos sobre identificadores | Reconstruir la presentación en función de los registros trasladados |
El estado archivado de J2Store significa que algunas extensiones heredadas pueden no tener un equivalente activo. La pregunta sobre el modelo de datos sigue siendo objetiva: ¿qué registros contienen significado empresarial y dónde vivirá ese significado después de la migración? Los registros sin un consumidor en el destino deben archivarse o retirarse deliberadamente en lugar de copiarse como residuos técnicos opacos.
Linaje de registros heredados y responsabilidad del archivo
Las migraciones desde J2Store suelen necesitar dos destinos: un modelo operativo y un archivo histórico. No todas las tablas heredadas deben convertirse en objetos activos del destino, pero los registros que explican Orders, derechos de acceso, evidencia fiscal o historial de sistemas externos pueden necesitar conservación a largo plazo.
La decisión debe basarse en el linaje empresarial, no en la antigüedad de la tabla. Un ID antiguo de Product puede haber dejado de servir para la tienda, pero seguir conectando líneas históricas de Orders con exportaciones contables. Un registro de aplicación puede dejar de impulsar funcionamiento activo y aun así explicar un periodo de membresía o un saldo pendiente. Un alias duplicado puede no ser necesario como contenido activo, pero seguir requiriendo una redirección.
| Registro heredado | Uso operativo en el destino | Uso en archivo |
|---|---|---|
| Identificadores de Product y artículo | Reconectar el elemento vendible actual y su contenido | Rastrear antiguas líneas de Orders o referencias externas |
| Configuración archivada de extensiones | Normalmente se sustituye por configuración actual | Explicar cómo se generaron transacciones históricas |
| Instancias de suscripción, reserva o pago | Continuar solo cuando exista un responsable compatible en el destino | Conservar historial contractual o transaccional cuando sea necesario |
| Campos personalizados obsoletos | Mantener solo cuando un proceso actual los utilice | Guardarlos en una exportación documentada cuando sean necesarios para interpretar el historial |
| Rutas y alias antiguos | Redirigir destinos valiosos | Conservar un registro de rutas para auditoría y resolución de problemas |
Esta separación evita que el destino activo se convierta en una copia de una implementación abandonada sin perder la evidencia que el personal, Customers o sistemas externos puedan necesitar. El archivo debe seguir siendo consultable y estar relacionado con identificadores empresariales estables, en lugar de quedar como un volcado de base de datos sin documentación.
Cómo cambian estas diferencias el alcance de la migración
El alcance de J2Store debe separar la transferencia de registros de la reconstrucción de relaciones y el tratamiento de dependencias heredadas.
| Tratamiento | Ejemplos | Implicación para el alcance |
|---|---|---|
| Transferencia directa de registros | Products, Customers, Orders, Categories, contenido y medios estándar | Correspondencia de campos con el responsable compatible en el destino |
| Reconstrucción de relaciones | Artículo con Product, usuario con Customer, Product con opción, Order con registros de aplicaciones | Reconstruir la conexión mediante identificadores estables |
| Configuración del destino | Menús, módulos, plantillas, impuestos, pagos, envíos, acceso e idiomas | Asignar a la capa de implementación del destino |
| Traslado de extensiones heredadas | Suscripciones, reservas, pagos parciales, proceso de compra personalizado e informes | Definir un destino actual o conservarlos como archivo histórico |
| Continuidad de sistemas externos | IDs de ERP, CRM, contabilidad, procesamiento de pedidos y marketplace | Conservar identificadores duraderos y la responsabilidad sobre su correspondencia |
| Retirada intencionada | Extensiones abandonadas, rutas duplicadas, campos obsoletos y contenido no utilizado | Excluir mediante una decisión empresarial documentada |
Un modelo de migración coherente asigna a cada valor conservado un destino autorizado. No utiliza el esquema antiguo de J2Store como diseño del destino únicamente porque la base de datos de origen lo contenga.
Conclusión
Las diferencias del modelo de datos de J2Store proceden de la forma en que el comercio electrónico se superpone a artículos, usuarios, Categories, menús, alias, módulos y plantillas de Joomla. El significado de Product se divide entre registros de contenido y comerciales. El significado de Customer puede abarcar la identidad de Joomla y las direcciones u Orders de J2Store. Los modelos de venta especializados suelen depender de tablas pertenecientes a aplicaciones, y los Orders históricos deben seguir siendo comprensibles aunque esas aplicaciones ya no estén activas.
Dado que J2Store es ahora una plataforma heredada, la migración debe conservar el significado empresarial sin reproducir estructuras técnicas obsoletas. El modelo de destino más sólido vuelve a conectar la identidad del artículo y del Product, asigna los valores de Customer y Order al responsable correcto durante su ciclo de vida, traslada explícitamente los datos de extensiones y retira los registros que ya no tienen un consumidor válido.
Preguntas frecuentes
¿Por qué los artículos de Joomla son fundamentales para el modelo de datos de J2Store?
J2Store utiliza artículos de Joomla como base de contenido de los Products. Por tanto, el contenido del artículo, Category, alias, idioma, acceso y estado de publicación pueden ser inseparables del precio, SKU, stock, opciones y registros de compra de J2Store.
¿J2Store sigue siendo la continuación activa de la plataforma?
No. El desarrollo de J2Store se ha discontinuado y su repositorio está archivado. J2Commerce es el sucesor activo. Los datos existentes de J2Store siguen siendo evidencia válida del origen, pero deben trasladarse a la estructura de destino elegida en lugar de suponerse que continuarán funcionando sin cambios.
¿Las opciones de J2Store equivalen a variantes en todas las plataformas?
No. Una elección de origen puede ser un SKU con stock propio, un modificador de precio, un campo de personalización, una especificación o un registro de extensión. La estructura de destino debe seguir lo que esa elección cambia en el funcionamiento de Product y Order.
¿Cómo deben representarse los Customers invitados?
Mantenga los datos de contacto y dirección del invitado asociados al Order histórico salvo que existiera una cuenta persistente real. Crear usuarios artificiales de Joomla puede alterar el significado de la identidad y duplicar historiales de Customer.
¿Los Orders históricos restauran el funcionamiento activo de pagos, envíos o impuestos?
No. Los Orders históricos conservan las etiquetas, importes, estados y referencias registradas. El funcionamiento activo del proceso de compra pertenece a la configuración de pagos, envíos, impuestos y monedas del destino.
¿Qué debe hacerse con los datos de una extensión J2Store abandonada?
Determine si los registros siguen teniendo utilidad empresarial, legal u operativa. Trasládelos a un responsable actual cuando exista; de lo contrario, conserve un archivo o retírelos deliberadamente en lugar de insertar campos opacos en registros de destino sin relación.