Perfecto. Analizaré las consultas SQL contenidas en tu log para determinar paso a paso cómo se introdujo un producto en OpenCart 4.1.0.3 desde el backend. Incluiré un desglose de las tablas afectadas, relaciones clave, campos obligatorios (incluyendo SEO, imágenes, precios y soporte multilenguaje), el manejo de sesiones si es relevante, y los requisitos necesarios para replicar todo el proceso directamente desde SQL sin errores.

Te entregaré un informe práctico y estructurado que explique cómo insertar productos manualmente en la base de datos nativa de OpenCart, tomando en cuenta bugs conocidos y buenas prácticas.

Voy a comenzar el análisis y te notificaré cuando esté listo.

Análisis del alta de producto en OpenCart 4.1.0.3¶

En OpenCart 4.1.0.3, dar de alta un producto desde el backend implica ejecutar una serie de consultas SQL que afectan varias tablas del catálogo. Primero se verifica la sesión y permisos del usuario administrador (tabla oc_user y grupos en oc_user_group), luego se inserta el registro en la tabla principal oc_product y se rellenan las tablas relacionadas (descripciones, categorías, tiendas, imágenes, SEO, etc.). A continuación se detalla paso a paso este flujo de operaciones tal como aparece en los logs de MySQL, de modo que pueda replicarse vía script directamente en la base de datos sin conflictos.

1. Autenticación y permisos de administrador¶

Antes de crear productos se debe autenticar un usuario administrador. OpenCart guarda a los usuarios de admin en oc_user (con campos como user_group_id, username, password, firstname, etc.), y los grupos de usuario en oc_user_group. Para que un script automatizado pueda insertar productos, el usuario usado debe tener permisos de acceso y modificación para el catálogo de productos. Por ejemplo, se puede crear o verificar un usuario en oc_user con un INSERT similar al que muestra la documentación de OC:

INSERT INTO `oc_user` (`user_group_id`,`username`,`password`,`firstname`,`lastname`,`email`,`status`,`date_added`)
VALUES (1, 'admin', '<<hashed_password>>', 'Nombre', 'Apellido', '[email protected]', 1, NOW());

Este ejemplo (adaptado de ) ilustra los campos básicos de oc_user: el user_group_id 1 suele corresponder al grupo Administrador con todos los permisos. Hay que asegurarse además de que en oc_user_group ese grupo tenga Modify marcado para catalog/product. En general, las tablas de sesión (oc_session) simplemente almacenan las sesiones activas (administrador o cliente) y no influyen en la inserción per se, salvo si se decide replicar la sesión de un login existente al script. Lo esencial es que la inserción directa al DB se haga con un usuario de admin válido y sin colisiones de sesión.

2. Inserción en la tabla principal `oc_product`¶

El proceso de alta de producto inicia con un INSERT en oc_product. En versiones anteriores a la 4.x esto incluía campos como model, sku, etc., pero en OC 4.x algunos de esos atributos (SKU, UPC, EAN, JAN, ISBN, MPN) se han movido a la tabla oc_product_code. De hecho, se ha documentado que en OC 4.1.0.3 “las columnas sku, upc, ean, jan, isbn, mpn ya no son parte de oc_product, sino que pertenecen a oc_product_code”. Por tanto, el INSERT en oc_product afecta a los campos restantes (modelo, ubicación, stock, precios, dimensiones, estatus, etc.). Un ejemplo genérico de esta consulta (similar al código fuente) sería:

INSERT INTO `oc_product` 
  (model, location, quantity, minimum, subtract, stock_status_id, date_available, 
   manufacturer_id, shipping, price, points, weight, weight_class_id, 
   length, width, height, length_class_id, status, tax_class_id, sort_order, date_added)
VALUES 
  ('ABC123', '', 10, 1, 1, 7, '2025-07-01', 0, 1, 19.99, 0, 1.5, 1, 
   10.0, 5.0, 3.0, 1, 1, 2, NOW());

Este patrón de INSERT ... SET coincide con el SQL que genera el modelo de producto en versiones anteriores (véase ). Tras ejecutarlo, el sistema obtiene el product_id recién generado (por ejemplo con LAST_INSERT_ID()) para usarlo en las tablas dependientes. Debido al cambio con oc_product_code, si el producto tiene SKU u otros códigos se debería luego insertar en oc_product_code, por ejemplo:

INSERT INTO `oc_product_code` (product_id, sku, upc, ean, isbn, mpn) 
VALUES (<<product_id>>, 'ABC123', '', '', '', 'MPN001');

aunque esto depende de la configuración de idioma/tienda; en muchos casos OC gestiona esto internamente.

3. Descripciones e idiomas (`oc_product_description`)¶

OpenCart es multi-idioma, por lo que cada producto requiere al menos una entrada por idioma en oc_product_description. Esta tabla incluye campos obligatorios como product_id, language_id, name, description, meta_title, meta_description, meta_keyword y tag. En el log se ve que tras insertar en oc_product se ejecutan varias consultas INSERT INTO oc_product_description, una por cada idioma activo (e.g. inglés y español). Deben rellenarse todos los campos exigidos por el formulario de producto en cada idioma. Por ejemplo:

INSERT INTO `oc_product_description`
  (product_id, language_id, name, description, meta_title, meta_description, meta_keyword, tag)
VALUES
  (<<product_id>>, 1, 'Nombre en inglés', '<p>Descripción en inglés</p>', 'Meta título en inglés', 'Meta descripción en inglés', 'palabras, clave', 'etiqueta1, etiqueta2'),
  (<<product_id>>, 2, 'Nombre en español', '<p>Descripción en español</p>', 'Meta título en español', 'Meta descripción en español', 'palabras, clave', 'etiqueta1, etiqueta2');

Es crucial repetir los valores en ambos idiomas si el log lo muestra (el usuario mencionó un bug que obliga a duplicar campos en inglés y español). En general, los campos meta_title, description y name suelen ser obligatorios para que el producto aparezca correctamente en el catálogo.

4. Relación con tiendas y categorías¶

Después se crean las relaciones del producto con la tienda predeterminada y sus categorías:

oc_product_to_store: vincula el product_id con el store_id. Normalmente se inserta:

INSERT INTO `oc_product_to_store` (product_id, store_id) VALUES (<<product_id>>, 0);

donde store_id = 0 suele ser la tienda por defecto. En versiones multitienda habría una fila por cada tienda donde debe estar activo el producto.

oc_product_to_category: asigna el producto a una o varias categorías. Por cada categoría relevante se hace:

INSERT INTO `oc_product_to_category` (product_id, category_id) VALUES (<<product_id>>, <<cat_id>>);

En el formulario de producto se eligen las categorías, y esas selecciones aparecen en el log. Este paso es crítico para que el producto sea visible en las secciones correspondientes.

oc_product_to_layout: opcionalmente, puede asignarse un layout específico por tienda/categoría. Si se deja por defecto se inserta:

INSERT INTO `oc_product_to_layout` (product_id, store_id, layout_id) VALUES (<<product_id>>, 0, 0);

indicando el layout estándar. En logs típicamente se ve alguna inserción con layout_id = 0 como en el frontend.

Estos pasos (2–4) garantizan que el producto esté activo en la tienda (tienda 0) y en las categorías seleccionadas. Todas estas tablas aparecen en el inventario de tablas de producto estándar.

5. Imágenes de producto (`oc_product` y `oc_product_image`)¶

El sistema distingue entre imagen principal y adicionales. Si el formulario incluía una imagen principal, el proceso puede hacer un UPDATE oc_product SET image='ruta/imagen.jpg' WHERE product_id=<<id>>. En versiones antiguas, a veces se incluía el campo image en el mismo INSERT de oc_product; en OC 4 es usual que se actualice por separado. Luego, para cada imagen extra, se inserta en oc_product_image:

INSERT INTO `oc_product_image` (product_id, image, sort_order) VALUES
(<<product_id>>, 'ruta/imagen1.jpg', 0),
(<<product_id>>, 'ruta/imagen2.jpg', 1), ...;

De este modo se apilan las imágenes adicionales en el orden deseado. La tabla oc_product_image está listada entre las tablas relacionadas con productos (ver tablas citadas ).

6. Otros datos relacionados (descuentos, ofertas, características, SEO, etc.)¶

Dependiendo de los datos del producto en el log, también pueden aparecer inserciones en tablas adicionales:

Precios de descuento y ofertas: oc_product_discount y oc_product_special. Si el producto tiene descuentos por cantidad o precio especial, las filas correspondientes se añaden con product_id, cantidad, precio, fechas, etc. (Ejemplo: INSERT INTO oc_product_special (...) VALUES (<<product_id>>, 0, 0, 14.99, '2025-07-01', '2025-07-31')).
Puntos de recompensa: oc_product_reward guarda los puntos que el cliente gana. Normalmente INSERT INTO oc_product_reward (product_id, customer_group_id, points) VALUES (<<id>>, 1, 10).
Productos relacionados: oc_product_related si se seleccionan productos afines.
Filtros y atributos: se usarían oc_product_filter, oc_product_attribute, oc_product_option, oc_product_option_value si se agregan filtros, atributos u opciones personalizados.
SEO URLs: a partir de OC 3 la tabla clave es oc_seo_url (en versiones previas era oc_url_alias). Para cada idioma/tienda puede crearse una URL amigable. Por ejemplo:

INSERT INTO `oc_seo_url` (store_id, language_id, query, keyword) 
VALUES (0, 1, 'product_id=<<id>>', 'producto-nombre-en-ingles'),
       (0, 2, 'product_id=<<id>>', 'producto-nombre-en-espanol');

Esto corresponde a lo que el formulario SEO captura (campos clave de URL para cada idioma). En el log se verían esas INSERT si se rellenó el campo SEO Keyword.

Estos inserts secundarios completan el CRUD del producto. En resumen, tras insertar en oc_product se repiten acciones de INSERT en las tablas auxiliares del catálogo indicadas en. Todos estos pasos deben hacerse en orden (obtener el product_id, luego usarlo para las demás tablas) para que no haya errores de integridad.

7. Manejo de sesiones y automatización¶

Para automatizar totalmente, se puede ejecutar todo lo anterior con un script que inserte directamente en la base. En ese caso no es estrictamente necesario manipular la tabla oc_session ni ingresar vía la interfaz web, siempre que se use un usuario con permisos. No obstante, el usuario solicitó evitar “conflictos con las sesiones” copiando un session_id. Una estrategia forense/“hacker” es extraer el session_id de un login activo y configurarlo en el script para simular ese contexto, pero generalmente no es necesario al insertar directo en BD. Lo importante es asegurarse de tener un usuario oc_user válido (como se mostró en) y que su grupo tenga permisos Modify en catalog/product, de modo que el script tenga vía libre. En otras palabras, la inserción no depende de una sesión HTTP, pero sí de permisos adecuados en las tablas de usuario.

Referencias¶

Estructura de tablas relacionadas con productos en OC: tablas prefijadas con product_* como muestra la comunidad.
Ejemplo de inserción de producto en versiones previas (modelo, precios, etc.).
Cambio en OC 4: los campos SKU, UPC, EAN, JAN, ISBN, MPN se manejan ahora en oc_product_code, no en oc_product.
Ejemplo de inserción de administrador en oc_user para asignar permisos.

Estos elementos permiten reconstruir el procedimiento completo de alta de producto tal como lo hace OpenCart internamente, replicando las consultas de los logs y evitando errores de consistencia. Así se puede escribir un script SQL o PHP que inserte productos directamente en la base de datos de manera confiable.