Caso Colchonerías González: PrestaShop 1.7 se queda colgado al editar productos con muchas combinaciones

Caso real: colchoneriasgonzalez.com — Colchonerías González, tienda PrestaShop de colchones, canapés y descanso en Madrid.

El cliente nos contactó porque, al editar productos en el Back Office de PrestaShop, el panel se quedaba colgado casi siempre. Su sospecha era clara: productos con demasiadas combinaciones (medidas, colores, tapizados, etc.).

Tras revisar el caso en PrestaShop 1.7.8.3 con PHP 7.4.33 (PHP-FPM en Plesk/Linux), confirmamos que tenía razón. El formulario de edición de producto se saturaba con cientos de combinaciones, y el servidor descartaba parte de los datos POST sin mostrar un error útil.

En este caso de éxito documentamos el diagnóstico real, las dos causas raíz y la solución que aplicamos: subir max_input_vars, suavizar la carga AJAX de combinaciones y limpiar basura en base de datos — sin tocar el catálogo de cara al cliente ni la tienda en vivo.

Síntomas en el Back Office

• Al abrir Catálogo → Productos → Editar producto, el BO se congela o tarda muchísimo.
• El bloqueo se nota especialmente al entrar en la pestaña Combinaciones.
• Al guardar el producto, a veces parece que “no termina” o se queda colgado.
• Ocurre más en productos con muchas variaciones (tallas, medidas, colores, tapizados, etc.).
• En productos con pocas combinaciones el problema casi no aparece.

[CAPTURA: pantalla del Back Office congelada al abrir la pestaña Combinaciones de un producto con muchas variaciones]

Datos reales del catálogo analizado

No era un caso teórico. En el catálogo encontramos productos realmente pesados:

• Producto más pesado: 297 combinaciones (ejemplo: base tapizada).
• Otros productos: 192, 96, 85 y 81 combinaciones.
• Total aproximado en tienda: miles de combinaciones en el catálogo.
• Además: 1064 combinaciones huérfanas con id_product = 0 (basura en BD).

Entorno técnico

• PrestaShop: 1.7.8.3
• PHP web: 7.4.33 (SAPI: fpm-fcgi)
• Hosting: Plesk en Linux
• Panel admin: /admin500 (ruta típica /adminXXX)
• memory_limit: 1024M (ya era alto; no era el cuello de botella principal)
• max_execution_time / max_input_time: 1024 (también altos)

El problema principal no era la memoria, sino la combinación de max_input_vars bajo + el peso del formulario/JS de combinaciones en el Back Office.

Diagnóstico: dos causas trabajando a la vez

Causa 1: max_input_vars demasiado bajo

En el PHP-FPM del dominio el valor activo era:

max_input_vars = 12000

En PrestaShop 1.7 el formulario de producto envía muchos campos por cada combinación. Una estimación práctica:

• Unas 20–40 variables por combinación.
• 297 combinaciones × 40 ≈ 11.880 campos solo de combinaciones.
• Más los campos del producto: SEO, precio, descripción, transporte, etc.

Resultado: se supera max_input_vars. PHP descarta variables POST en silencio (sin un error claro en pantalla). El Back Office parece colgado, o guarda mal / incompleto.

Dónde estaba el valor realmente activo en este caso (Plesk):

/opt/plesk/php/7.4/etc/php-fpm.d/colchoneriasgonzalez.com.conf
php_value[max_input_vars] = 12000

Importante: aunque cambies el php.ini del dominio en la interfaz, FPM puede seguir forzando 12000. Hay que tocar la config PHP-FPM del dominio (mejor con php_admin_value) y reiniciar plesk-php74-fpm.

[CAPTURA: phpinfo o probe mostrando max_input_vars = 12000 antes del cambio]

Causa 2: carga AJAX demasiado agresiva en el Back Office

PrestaShop 1.7.8 carga las combinaciones del producto por AJAX en lotes. El archivo implicado:

/adminXXX/themes/new-theme/public/product_page.bundle.js
(en el proyecto: admin500/themes/new-theme/public/product_page.bundle.js)

El loader original pedía combinaciones en batches de 50:

slice(u,u+50)
(u+=50)

Cada lote inyecta mucho HTML en el DOM. Con 200–300 combinaciones, el navegador se bloquea al renderizar la pestaña Combinaciones.

Solución aplicada (paso a paso)

A) Subir max_input_vars a 100000 en PHP-FPM

En el pool FPM del dominio cambiamos:

# Antes
php_value[max_input_vars] = 12000

# Después (más robusto: no se sobreescribe fácilmente)
php_admin_value[max_input_vars] = 100000

También actualizamos, si aplica:

/var/www/vhosts/system/[dominio]/etc/php.ini
max_input_vars = 100000

Reinicio del servicio FPM:

systemctl restart plesk-php74-fpm

Verificación con un probe PHP temporal en admin:

ini_get('max_input_vars'); // debe devolver 100000

Nota Plesk: a veces “PHP Settings” del dominio sigue mostrando 12000 aunque FPM ya esté en 100000. Recomendación: poner también 100000 en la UI de Plesk para que no se pierda en regeneraciones de configuración.

B) Reducir el tamaño de lote AJAX de combinaciones (50 → 15)

Archivo editado:

admin500/themes/new-theme/public/product_page.bundle.js

Cambios:

• a.slice(u,u+50) → a.slice(u,u+15)
• (u+=50) → (u+=15)

Efecto: la carga es más gradual y el navegador se bloquea mucho menos al abrir productos con muchas combinaciones. Tras editar, haz hard refresh del Back Office (Ctrl+F5).

[CAPTURA: diff o búsqueda en product_page.bundle.js mostrando el batch 15]

C) Limpiar combinaciones huérfanas

Había 1064 filas en ps_product_attribute con id_product = 0. Las eliminamos de forma segura, junto con las tablas relacionadas asociadas:

• ps_product_attribute
• ps_product_attribute_combination
• ps_product_attribute_shop
• ps_stock_available

Esto no arregla solo el freeze, pero limpia basura y evita ruido o consultas inútiles en el catálogo.

Archivos y configuración tocados

1. /opt/plesk/php/7.4/etc/php-fpm.d/[dominio].conf — max_input_vars de 12000 a 100000 (php_admin_value)
2. /var/www/vhosts/system/[dominio]/etc/php.ini — max_input_vars = 100000
3. /adminXXX/themes/new-theme/public/product_page.bundle.js — batch de combinaciones 50 → 15
4. Base de datos PrestaShop — limpieza de combinaciones huérfanas id_product = 0

Cómo comprobar que está resuelto

1. Crear un probe PHP temporal y confirmar: max_input_vars = 100000.
2. En el Back Office, hard refresh (Ctrl+F5).
3. Abrir un producto con muchas combinaciones (100+).
4. Comprobar que la pestaña Combinaciones carga sin congelar tanto el navegador.
5. Editar un campo y Guardar: debe completar sin quedarse colgado.
6. Revisar que no se pierden datos de combinaciones al guardar.

[CAPTURA: producto con muchas combinaciones abierto y guardado correctamente tras el arreglo]

Consejos preventivos

• No generes combinaciones innecesarias: cada variación multiplica campos del formulario.
• En tiendas con muchas tallas/medidas/colores, vigila max_input_vars desde el principio.
• Tras cambios de PHP en Plesk, reinicia PHP-FPM y verifica con ini_get, no solo con la UI.
• Si tocas product_page.bundle.js, documenta el cambio: una actualización de PrestaShop puede sobrescribirlo.
• Revisa periódicamente combinaciones huérfanas (id_product = 0).

Aviso importante: haz backup completo (archivos + base de datos) antes de tocar la configuración PHP-FPM o el JavaScript del Back Office. Un valor mal aplicado o un JS corrupto puede dejar el panel inaccesible hasta restaurar.

Conclusión

Cuando PrestaShop 1.7 se queda colgado al editar o guardar productos con muchas combinaciones, no suele ser “la caché” ni un virus. En este caso real convivían dos problemas: max_input_vars = 12000 insuficiente para un producto con 297 combinaciones, y una carga AJAX en lotes de 50 que saturaba el navegador.

Subir max_input_vars a 100000 en PHP-FPM, bajar el batch de combinaciones de 50 a 15 en product_page.bundle.js y limpiar 1064 combinaciones huérfanas devolvió un Back Office usable.

Si tu tienda PrestaShop se bloquea al editar productos con muchas variaciones, puedo revisar el entorno (PHP-FPM, formulario de producto y catálogo) y dejarte el Back Office estable.

Soporte técnico PrestaShop · Contactar · WhatsApp