¿Cómo gestionar las actualizaciones de PHP sin colapsar tu tienda PrestaShop?

PHP no es “una versión más”: es la carretera por la que circula tu tienda 🚀

En una tienda PrestaShop, PHP interpreta buena parte de la lógica que permite mostrar productos, calcular impuestos, iniciar sesión, procesar pedidos, ejecutar módulos, enviar correos, gestionar transportistas y hablar con pasarelas de pago. Dicho de otra forma: PHP no es un adorno técnico. Es el suelo.

Cuando una versión de PHP queda fuera de soporte oficial, deja de recibir actualizaciones de seguridad. No significa que tu web vaya a arder al día siguiente, claro. Las tiendas rara vez se incendian con elegancia. Más bien empiezan con síntomas discretos: módulos que no actualizan, proveedores que exigen versiones superiores, errores en el back office, advertencias del hosting, incompatibilidades con librerías modernas, lentitud inexplicable. Una grieta aquí. Otra allá.

La paradoja es deliciosa, si uno tiene cierta paciencia: muchos negocios mantienen PHP antiguo “para no romper nada”, pero precisamente esa quietud acaba convirtiéndose en el mayor riesgo. La estabilidad de ayer puede ser la fragilidad de mañana. Como un puente medieval por el que ahora pasan camiones de reparto.

🔒 Seguridad

Las versiones de PHP sin soporte no reciben parches oficiales frente a vulnerabilidades nuevas. En comercio electrónico, donde se manejan datos personales, sesiones, direcciones y pagos, esto no es un detalle administrativo: es una obligación operativa.

⚡ Rendimiento

Las versiones modernas de PHP suelen ejecutar código con mayor eficiencia. En términos prácticos: menor consumo de CPU, mejor respuesta bajo carga y más margen para campañas, picos de tráfico y catálogos extensos.

🧩 Compatibilidad

Los módulos actuales, bibliotecas de terceros, SDK de pago, conectores ERP y herramientas de automatización tienden a abandonar versiones antiguas. El ecosistema avanza, aunque tu tienda quiera quedarse tomando café en 2018.

También conviene matizar algo: actualizar PHP no convierte por arte de magia una tienda lenta en una gacela. Si el tema está inflado, hay módulos duplicados, consultas SQL pesadas o imágenes gigantescas, PHP solo podrá ayudar hasta cierto punto. Un motor nuevo no arregla una rueda cuadrada. Pero sí reduce fricción, mejora la base y permite trabajar con herramientas actuales.

El problema no es actualizar PHP; el problema es actualizarlo a ciegas 🧨

La actualización de PHP en PrestaShop puede ser sencilla o puede convertirse en una pequeña novela negra. Todo depende de lo que haya en la tienda: versión de PrestaShop, tema, módulos, overrides, personalizaciones, integraciones externas, configuración del servidor y edad del proyecto. Hay tiendas limpias, casi monásticas. Y hay tiendas que son excavaciones arqueológicas: una capa de código de 2016, otra de un freelance desaparecido, otra de un módulo comprado en oferta, otra de “esto lo tocó alguien pero no sabemos quién”.

No lo digo con desprecio. Todos hemos visto proyectos así. En una ocasión encontré un módulo de transportista que seguía consultando una API ya retirada, pero funcionaba porque alguien había dejado una regla temporal en el servidor. Temporal, por supuesto, desde hacía cuatro años. La informática tiene esa forma tan suya de convertir el “luego lo revisamos” en patrimonio cultural.

Riesgos habituales al cambiar de versión de PHP

• Error 500 o pantalla blanca: normalmente causado por código incompatible, clases no encontradas, errores fatales o módulos obsoletos.
• Back office inaccesible: puede suceder si un módulo administrativo, override o dependencia rompe durante la carga.
• Checkout defectuoso: el peor de los escenarios comerciales: el cliente llega a pagar y la tienda decide filosofar.
• Problemas con pasarelas de pago: SDK antiguos de PayPal, Stripe, Redsys, bancos locales o métodos alternativos pueden requerir versiones concretas de PHP o extensiones específicas.
• Errores en envíos: módulos de transportistas y cálculo de tarifas suelen depender de APIs externas y librerías HTTP.
• Incompatibilidad con el tema: plantillas Smarty, hooks modificados o funciones antiguas pueden generar avisos o fallos.
• Cron jobs rotos: tareas programadas de importación, sincronización, emails o limpieza pueden usar rutas o binarios PHP antiguos.
• Diferencias entre CLI y servidor web: a veces la web usa PHP 8.1 y la consola sigue en 7.4. Parece una tontería. No lo es.

⚠️ Regla de oro: nunca actualices PHP directamente en producción sin copia de seguridad, sin entorno de pruebas y sin plan de vuelta atrás. Cambiar PHP “solo un momento” en una tienda activa es como cambiarle las ruedas a un coche en marcha porque total, son cuatro tornillos.

Compatibilidad entre PrestaShop y PHP: el mapa antes del viaje 🗺️

Antes de tocar el selector de PHP en cPanel, Plesk, CloudLinux, Docker, RunCloud, GridPane, Laravel Forge o el panel que use tu proveedor, hay que responder a una pregunta simple: ¿qué versión de PHP soporta oficialmente mi versión de PrestaShop?

La respuesta cambia con el tiempo. Por eso conviene comprobar siempre la documentación oficial de PrestaShop y las notas de versión. Aun así, como referencia práctica, esta tabla resume escenarios comunes en muchas tiendas:

Nota técnica: PHP 7.4 dejó de recibir soporte oficial hace tiempo. PHP 8.0 también está fuera de soporte. Las ramas PHP 8.1, 8.2, 8.3 y posteriores tienen calendarios de mantenimiento publicados por el proyecto PHP en php.net. Revisa siempre fechas actuales, porque el calendario de soporte no espera a que termines la campaña de Navidad.

Aquí aparece una tensión muy frecuente: el hosting exige actualizar PHP por seguridad, mientras la tienda depende de un módulo antiguo que solo respira en PHP 7.4. Entre la seguridad y la compatibilidad, entre el futuro y el pasado, el comerciante queda en medio con un catálogo lleno y poco tiempo para poesía. Pero la salida no es ignorar el aviso del hosting. La salida es trazar una ruta.

📌 Consejo profesional: distingue entre “la tienda carga” y “la tienda es compatible”. Una home page que se ve bien no demuestra nada. Hay que probar búsqueda, filtros, carrito, cupones, impuestos, transportistas, pagos, emails, facturas, devoluciones, multitienda, idiomas y tareas cron.

Auditoría previa: mirar debajo de la alfombra antes de invitar al elefante 🔍

Una actualización de PHP bien gestionada empieza con inventario. Es menos emocionante que pulsar botones, sí, pero también menos propenso a destruir ventas. El objetivo es saber qué tienes, qué depende de qué y qué puede romperse.

1. Identifica versiones exactas

• Versión completa de PrestaShop, no solo “1.7” o “8”. Necesitas el número exacto: por ejemplo, 1.7.8.10 o 8.1.x.
• Versión actual de PHP en el servidor web.
• Versión de PHP en línea de comandos, ejecutando php -v si tienes acceso SSH.
• Versión de MySQL o MariaDB.
• Versión del servidor web: Apache, Nginx, LiteSpeed u otro.
• Memoria PHP disponible, límite de ejecución, extensiones activas y configuración de OPcache.

En PrestaShop puedes revisar parte de esta información desde el back office, en parámetros avanzados e información del sistema. En hosting gestionado, el panel suele mostrar la versión PHP por dominio. En servidores propios, tendrás que consultar configuración de pools PHP-FPM, vhosts o contenedores.

2. Lista módulos instalados y clasifícalos

No todos los módulos tienen el mismo peso. Algunos son decorativos; otros sostienen el negocio como columnas invisibles. Clasifícalos:

Un módulo desactivado no siempre es inofensivo. Algunos mantienen overrides, tablas, hooks o archivos cargados indirectamente. La tienda moderna está llena de fantasmas educados: no hacen ruido hasta que cambias PHP.

3. Revisa overrides y personalizaciones

En PrestaShop, los overrides permiten modificar clases del núcleo. Son útiles, sí, pero también pueden convertirse en minas antipersona durante actualizaciones. Revisa especialmente:

• /override/classes/
• /override/controllers/
• Plantillas modificadas del tema en /themes/tu-tema/
• Módulos con carpetas override
• Código a medida dentro de módulos “custom”

Si encuentras funciones antiguas, constructores con el mismo nombre que la clase, uso de propiedades dinámicas, incompatibilidades con tipos estrictos, dependencias abandonadas o llamadas a métodos retirados, no las ignores. PHP moderno es menos tolerante con ciertas licencias poéticas del pasado.

Staging: el ensayo general antes de abrir la tienda 🧪

Un entorno de staging es una copia funcional de tu tienda donde puedes probar cambios sin afectar a clientes reales. No es un lujo de grandes empresas. Es el cinturón de seguridad. Nadie presume de él, pero todos agradecen llevarlo cuando aparece la curva.

El staging ideal debe replicar producción lo máximo posible: misma versión de PrestaShop, mismos módulos, mismo tema, misma base de datos anonimizada si es posible, configuración similar del servidor y, por supuesto, la versión PHP que quieres probar.

Cómo crear un staging fiable

• Copia archivos y base de datos desde producción.
• Cambia el dominio a un subdominio privado, por ejemplo staging.tutienda.com.
• Protege el entorno con contraseña HTTP o restricción IP.
• Desactiva indexación en robots y añade cabeceras noindex si procede.
• Configura emails para que no se envíen a clientes reales.
• Desactiva integraciones que puedan modificar stock real, pedidos reales o campañas reales.
• Usa claves sandbox para pasarelas de pago cuando sea posible.
• Verifica que el staging no comparte caché, sesiones o carpetas temporales con producción.

🚫 Cuidado con el staging mal clonado: una copia de pruebas que envía emails reales, sincroniza stock real o genera pedidos en el ERP no es un entorno seguro. Es una broma pesada con interfaz administrativa.

Si tu hosting permite cambiar PHP por dominio o subdominio, perfecto. Si usas Docker, puedes levantar contenedores con diferentes versiones de PHP. Si trabajas con servidor propio, configura un pool PHP-FPM separado. Lo importante es que el cambio se pruebe lejos de la caja registradora.

# Ejemplos útiles en servidor con acceso SSH
php -v
php -m
php -i | grep memory_limit
php -i | grep opcache.enable

No basta con saber que PHP 8.1 está disponible. Hay que saber si están activas las extensiones necesarias. PrestaShop suele requerir o beneficiarse de extensiones como curl, dom, fileinfo, gd o imagick, intl, json, mbstring, openssl, pdo_mysql, simplexml, zip y soporte adecuado para XML. La lista exacta puede variar según versión y módulos.

Módulos, tema y overrides: donde suele vivir el dragón 🐉

En la mayoría de tiendas PrestaShop, el núcleo no es el principal culpable. El núcleo, si está actualizado y dentro de compatibilidad oficial, suele comportarse. Los problemas aparecen en módulos no mantenidos, temas antiguos, overrides heredados y desarrollos a medida. Es decir: en esa parte del proyecto donde la historia comercial se encuentra con la sedimentación geológica.

Señales de alarma en un módulo PrestaShop

• No se actualiza desde hace años.
• El desarrollador ya no existe o no responde.
• No declara compatibilidad con tu versión de PrestaShop.
• No menciona compatibilidad con PHP 8.x.
• Usa librerías antiguas incluidas manualmente en lugar de Composer.
• Genera avisos en modo debug incluso antes de actualizar PHP.
• Modifica el checkout, pagos, transportistas o proceso de pedido sin documentación clara.

Con PHP 8 se hicieron más estrictos ciertos comportamientos: errores que antes eran simples avisos pueden transformarse en errores fatales; firmas de métodos incompatibles se castigan con menos indulgencia; algunos patrones antiguos empiezan a crujir. PHP dejó de mirar hacia otro lado con la paciencia de un funcionario cansado.

Activa el modo debug, pero con cabeza

En staging, activa el modo debug para detectar errores:

# En PrestaShop, puede activarse desde el back office
# Parámetros avanzados > Rendimiento > Modo debug

# También puede revisarse en:
config/defines.inc.php

En producción, el modo debug debe permanecer desactivado salvo intervención puntual muy controlada. Mostrar trazas de error al público puede revelar rutas internas, nombres de módulos, estructura de archivos o detalles sensibles. La transparencia está muy bien en la política pública; en los errores PHP, bastante menos.

Pruebas específicas para módulos críticos

PHP actualizado, tienda rápida: promesa razonable, no milagro de feria ⚡

Actualizar PHP puede mejorar el rendimiento, especialmente si vienes de versiones antiguas. PHP 7 supuso en su día un salto enorme frente a PHP 5 en consumo de recursos y velocidad de ejecución. PHP 8 añadió optimizaciones, mejoras del motor y nuevas capacidades del lenguaje. Pero en PrestaShop, la velocidad real depende de un sistema completo: base de datos, caché, tema, imágenes, módulos, consultas, servidor y tráfico.

Conviene evitar dos fantasías opuestas. La primera: “actualizar PHP lo arregla todo”. No. La segunda: “si la tienda ya funciona, da igual la versión”. Tampoco. Entre el milagro y la negligencia está la ingeniería, que es menos sexy pero paga mejor las facturas.

Parámetros PHP importantes para PrestaShop

OPcache: el bibliotecario que recuerda dónde está cada libro

OPcache almacena bytecode PHP precompilado para no interpretar los mismos archivos una y otra vez. En una tienda con cientos o miles de archivos PHP, es una diferencia notable. Sin OPcache, el servidor repite trabajo como quien vuelve a leer el manual de instrucciones cada vez que quiere encender la cafetera.

; Ejemplo orientativo de OPcache en producción
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

En despliegues avanzados, puede ajustarse validate_timestamps y limpiar OPcache durante releases. En hosting compartido, quizá no tengas tanto control. Aun así, revisar que OPcache esté activo es una de esas pequeñas acciones que separan una tienda afinada de una carreta con WiFi.

Plan paso a paso para actualizar PHP en PrestaShop sin romper ventas 🛠️

La actualización correcta no empieza el día del cambio. Empieza antes, con documentación, pruebas y una idea muy clara de cómo volver atrás si algo falla. El rollback no es pesimismo; es educación técnica.

Paso 1: Define la versión objetivo

No actualices “a la última” por reflejo. Actualiza a la versión más moderna que sea compatible con tu versión de PrestaShop, módulos y hosting. Si tu tienda está en PrestaShop 1.7.8, quizá PHP 7.4 sea el techo razonable mientras planificas migración a PrestaShop 8. Si ya estás en PrestaShop 8, PHP 8.1 puede ser una opción habitual, siempre validando documentación oficial y módulos.

Paso 2: Actualiza PrestaShop dentro de su rama

Antes de cambiar PHP, instala la última subversión estable compatible de tu rama. No es lo mismo una tienda en 1.7.8.0 que en 1.7.8.10. Las subversiones suelen corregir errores, mejorar compatibilidad y cerrar vulnerabilidades. Lo mismo aplica a PrestaShop 8.x.

Paso 3: Actualiza módulos y tema

Actualiza módulos oficiales, pasarelas de pago, transportistas, conectores y tema. Revisa changelogs. Un changelog aburrido puede contener una línea que te salve la semana: “compatibility with PHP 8.1”. La literatura técnica también tiene sus momentos de suspense.

Paso 4: Crea copia de seguridad verificable

Una copia de seguridad que nunca se ha probado es una promesa, no una copia. Antes de tocar PHP:

• Exporta base de datos completa.
• Copia archivos del proyecto, incluyendo img, modules, themes, override y configuración.
• Guarda versión de PHP actual y configuración relevante.
• Verifica que puedes restaurar en un entorno alternativo.
• Documenta credenciales, rutas, cron jobs y dependencias externas.

Paso 5: Prueba el cambio en staging

Cambia PHP solo en staging y limpia cachés. En PrestaShop, borra caché desde el back office o manualmente si es necesario. Después recorre la tienda como cliente, administrador y sistema automático.

# Rutas habituales de caché según versión
var/cache/
cache/smarty/cache/
cache/smarty/compile/

Paso 6: Revisa logs con paciencia forense

Los logs son aburridos hasta que te dicen exactamente qué módulo está hundiendo el barco. Revisa:

• Logs de PrestaShop.
• Logs de PHP-FPM.
• Logs de Apache, Nginx o LiteSpeed.
• Logs del hosting.
• Logs de módulos críticos.
• Consola del navegador para errores JavaScript relacionados con checkout o back office.

Paso 7: Ejecuta pruebas funcionales completas

No pruebes solo la home. La home es una actriz disciplinada; siempre intenta verse bien. Prueba lo que genera dinero y lo que sostiene la operación:

• Registro y login de cliente.
• Búsqueda interna, filtros y categorías.
• Ficha de producto, combinaciones, descuentos y stock.
• Carrito, cupones, gastos de envío e impuestos.
• Checkout como invitado y como usuario registrado.
• Pagos con cada método disponible.
• Confirmación de pedido y cambio de estado.
• Generación de factura, albarán y emails.
• Back office: productos, pedidos, clientes, módulos, traducciones.
• Importación/exportación CSV.
• Cron jobs e integraciones externas.
• Multitienda e idiomas si existen.

Paso 8: Planifica la ventana de mantenimiento

Elige una franja de bajo tráfico. Revisa analítica, historial de ventas, campañas activas y horarios de soporte. Evita actualizar antes de Black Friday, rebajas, lanzamientos, campañas de email o fines de semana sin equipo técnico disponible. La valentía está muy sobrevalorada cuando hay facturación de por medio.

Paso 9: Ejecuta el cambio en producción

Cuando staging está validado:

1. Activa modo mantenimiento si la intervención puede afectar sesiones o checkout.
2. Realiza backup final de producción.
3. Cambia versión PHP en hosting o servidor.
4. Verifica extensiones PHP.
5. Limpia cachés de PrestaShop y OPcache si procede.
6. Ejecuta pruebas críticas inmediatamente.
7. Monitoriza logs, pedidos, errores 500, consumo CPU y memoria.
8. Desactiva mantenimiento cuando todo esté estable.

Paso 10: Mantén vigilancia posterior

Las primeras horas importan. Algunos problemas solo aparecen con tráfico real, métodos de pago concretos, países específicos o combinaciones raras. La realidad siempre tiene más imaginación que el checklist.

Errores frecuentes tras actualizar PHP y cómo abordarlos 🧯

Error 500 inmediato

Suele indicar error fatal. Activa debug en staging, revisa logs y localiza archivo exacto. Si el error menciona un módulo, desactívalo temporalmente desde base de datos o renombrando su carpeta en entorno controlado. En producción, si la tienda está caída y no hay solución rápida, aplica rollback.

Back office inaccesible

Puede deberse a caché corrupta, módulo administrativo incompatible, override o error en Symfony en versiones modernas. Limpia var/cache, revisa permisos y logs. Comprueba si el problema ocurre solo en una sección del back office o desde el login.

El front carga, pero el checkout falla

Prioridad máxima. Revisa módulos de pago, transportistas, impuestos, cupones y tema. Comprueba errores AJAX en consola del navegador y respuestas de red. Muchos checkouts modernos dependen de llamadas asíncronas: por fuera parece un botón; por dentro es una pequeña ciudad.

Advertencias o deprecated notices

En staging, sirven para anticipar problemas. En producción, no deben mostrarse al usuario. Algunos avisos no rompen funcionamiento inmediato, pero conviene corregirlos porque anuncian incompatibilidades futuras. Son como esas goteras pequeñas que uno ignora hasta que el techo aprende a llover.

Problemas con imágenes o miniaturas

Verifica extensiones gd o imagick, permisos de carpetas y regeneración de miniaturas. Algunas configuraciones PHP nuevas pueden cambiar límites de memoria o tratamiento de archivos.

Cron jobs que dejan de ejecutarse

Revisa la ruta al binario PHP. En muchos servidores existen varias versiones:

/usr/bin/php
/usr/local/bin/php
/opt/alt/php81/usr/bin/php
/opt/plesk/php/8.1/bin/php

Si el cron sigue apuntando a PHP antiguo, puedes tener una tienda que en web va por una época y en tareas programadas por otra. Una especie de viaje temporal, pero sin la parte divertida.

Hosting PrestaShop: cuando el servidor también opina 🖥️

El hosting no es un escenario neutro. Influye en la versión PHP disponible, extensiones, límites, caché, aislamiento, logs y capacidad de rollback. Un buen proveedor para PrestaShop debería permitir seleccionar versión PHP por dominio, consultar logs con claridad, activar OPcache, ajustar parámetros razonables y restaurar backups sin convertirlo en una ceremonia bizantina.

Preguntas que deberías hacer a tu proveedor

• ¿Qué versiones de PHP están disponibles y hasta cuándo?
• ¿Se puede cambiar PHP por dominio o subdominio?
• ¿Hay entorno de staging incluido?
• ¿Qué extensiones PHP están activas?
• ¿Puedo modificar memory_limit, max_input_vars y OPcache?
• ¿Cómo se accede a logs de PHP y servidor?
• ¿Qué política de backups y restauración existe?
• ¿Usan PHP-FPM, LiteSpeed, Apache con mod_php u otra arquitectura?
• ¿Hay protección WAF, antivirus, aislamiento de cuentas y monitorización?

Si el proveedor no puede responder, responde tarde o considera que “PrestaShop es como WordPress pero con carrito”, quizá conviene mirar alrededor. No por dramatismo. Por supervivencia.

Actualizar PHP también es una decisión de seguridad 🔐

Una tienda online es una promesa de confianza. El cliente entrega datos personales, dirección, historial de compra y, aunque el pago se procese externamente, espera que todo funcione con seriedad. Usar PHP obsoleto no implica automáticamente una brecha, pero reduce tu margen defensivo.

Además de actualizar PHP, revisa:

• PrestaShop actualizado dentro de rama soportada.
• Módulos actualizados y descargados de fuentes confiables.
• Permisos correctos de archivos y carpetas.
• Back office protegido con URL no trivial y autenticación fuerte.
• Usuarios administrativos mínimos y con contraseñas robustas.
• Certificado SSL válido y redirección HTTPS completa.
• Cabeceras de seguridad cuando sea posible.
• Copias de seguridad externas.
• Monitorización de cambios en archivos.
• WAF o protección a nivel de servidor/CDN.

Seguridad y rendimiento suelen presentarse como mundos separados, pero en comercio electrónico se abrazan constantemente. Una tienda lenta pierde ventas; una tienda vulnerable pierde confianza. Lo primero duele en la caja. Lo segundo, en la reputación.

Checklist final para actualizar PHP en PrestaShop sin sobresaltos ✅

Usa esta lista antes de producción. Si alguna respuesta importante es “no lo sé”, aún no es momento de pulsar el botón.

• He identificado la versión exacta de PrestaShop.
• He comprobado compatibilidad oficial con la versión PHP objetivo.
• He actualizado PrestaShop a la última subversión segura de su rama.
• He actualizado módulos críticos y tema.
• He revisado overrides y código a medida.
• He creado un entorno de staging protegido.
• He probado la actualización PHP en staging.
• He verificado extensiones PHP necesarias.
• He revisado logs con modo debug en entorno seguro.
• He probado checkout, pagos, transportistas, emails y back office.
• He validado cron jobs e integraciones externas.
• He realizado backup completo de archivos y base de datos.
• He comprobado que el backup se puede restaurar.
• He definido una ventana de mantenimiento con bajo tráfico.
• He preparado un plan de rollback.
• He avisado al equipo implicado: soporte, marketing, operaciones y desarrollo.
• He monitorizado errores, pedidos y rendimiento después del cambio.

No conviertas cada actualización en una tragedia griega 📅

La mejor forma de gestionar actualizaciones de PHP en PrestaShop es no tratarlas como emergencias. Si solo piensas en PHP cuando el hosting amenaza con retirarlo, ya vas tarde. No irremediablemente tarde, pero sí tarde de esa manera incómoda en la que uno llega a la estación justo para ver cómo el tren se aleja con una tranquilidad ofensiva.

Lo recomendable es establecer una rutina:

• Revisión trimestral de versiones de PrestaShop, módulos, tema y PHP.
• Auditoría semestral de módulos obsoletos, overrides y rendimiento.
• Pruebas periódicas de backups y restauración.
• Plan anual de compatibilidad con próximas versiones de PHP.
• Documentación viva de integraciones, personalizaciones y tareas programadas.

Una tienda sana no es la que nunca cambia. Es la que puede cambiar sin romperse. La diferencia es enorme: la primera vive congelada, como insecto en ámbar; la segunda respira, evoluciona y soporta el invierno.

Actualizar PHP en PrestaShop no tiene por qué colapsar tu negocio. Exige método, sí. Exige respeto por los detalles. Exige aceptar que una tienda online no es una página bonita con botones de compra, sino un organismo complejo donde servidor, código, módulos, base de datos y clientes se rozan a cada segundo. Si lo tratas como un organismo, lo mantienes. Si lo tratas como una piedra, un día se parte.

Y quizá esa sea la enseñanza menos técnica y más útil: la estabilidad no consiste en no tocar nada, sino en tocar lo necesario con inteligencia. PHP cambia, PrestaShop cambia, los módulos cambian, los ataques cambian, los clientes cambian. La tienda que sobrevive no es la más inmóvil. Es la mejor preparada.