Cambias productos por SQL y el back-office no se entera

En mayo de 2024 salió dos veces en el grupo el mismo problema con otra cara. Un compañero quería activar la alerta de stock bajo en todos los productos de su 8.1 y lanzó en phpMyAdmin un UPDATE sobre ps_product. Otro quería cambiar la categoría principal de varios productos con id_category_default. Las consultas fueron bien, y en el back-office no cambió nada. La respuesta del grupo, en una línea: mira ps_product_shop.

Por qué pasa

PrestaShop está preparado para multitienda aunque tengas una sola tienda. Muchos datos del producto se guardan dos veces: en ps_product y en ps_product_shop, una fila por tienda. Cuando PrestaShop carga un producto para una tienda, los valores de ps_product_shop mandan sobre los de ps_product.

Están en las dos tablas, entre otros: el precio, el precio de coste, si está activo, la visibilidad, la categoría por defecto, si se puede pedir, la condición y los campos de alerta de stock bajo (low_stock_alert y low_stock_threshold). Si cambias solo ps_product, lo que lee la tienda sigue igual.

Cómo hacerlo bien

Antes de nada, copia de seguridad de la base de datos. Después, actualiza las dos tablas a la vez. Para la alerta de stock bajo en todo el catálogo:

UPDATE ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
SET p.low_stock_alert = 1,
    p.low_stock_threshold = 2,
    ps.low_stock_alert = 1,
    ps.low_stock_threshold = 2;

Para cambiar la categoría principal hay una tabla más. La categoría por defecto tiene que ser también una de las categorías asociadas al producto, que viven en ps_category_product:

UPDATE ps_product SET id_category_default = 75 WHERE id_product = 123;
UPDATE ps_product_shop SET id_category_default = 75 WHERE id_product = 123;
INSERT IGNORE INTO ps_category_product (id_category, id_product, position)
VALUES (75, 123, 0);

Cambia ps_ por tu prefijo y, al terminar, vacía la caché desde Parámetros avanzados → Rendimiento. Si usas un buscador o un menú con caché propia, vacíala también.

Un aviso de otro hilo: el Gestor SQL del back-office (Parámetros avanzados → Base de datos) solo admite consultas de lectura. Los UPDATE hay que lanzarlos en phpMyAdmin o por consola.

Productos importados por SQL que no salen en la tienda

El caso extremo lo contó otro miembro: tras pasar de 1.6 a 8 metió clientes, pedidos y productos a mano en la base de datos. Los productos salían en el back-office, pero no en la tienda; las categorías, ni en un sitio ni en otro. Las preguntas que le hicieron dan la lista de lo que suele faltar:

• ¿Están asociados a la tienda? Sin fila en ps_product_shop (y en ps_category_shop para las categorías), para la tienda no existen.
• ¿Tienen los textos de cada idioma? ps_product_lang y ps_category_lang llevan una fila por idioma y por tienda.
• ¿Tienen permisos las categorías? ps_category_group dice qué grupos de clientes ven cada categoría. Sin filas, nadie la ve.
• ¿Tienen stock? Cada producto necesita su fila en ps_stock_available.
• ¿Se arregla al abrirlo y guardarlo? Gustavo lo propuso como prueba: si al guardar un producto desde el back-office aparece en la tienda, es que faltaban filas que PrestaShop crea al guardar.

Cuándo no usar SQL

Para crear o borrar productos, mejor la API o el importador CSV. Un compañero contó que borró unos mil productos con la API, por id, con «limpieza perfecta». Otro, que al borrarlos por base de datos le quedaban restos, y acabó moviéndolos a una categoría por SQL y borrándolos desde el back-office. La razón: al borrar o crear con las clases de PrestaShop se tocan todas las tablas relacionadas (imágenes, combinaciones, stock, precios específicos, índice de búsqueda) y saltan los hooks que otros módulos esperan.

El SQL directo queda para cambios masivos y simples sobre campos que conoces, con copia de seguridad y comprobando antes en una tienda de pruebas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación