Cómo elegir, instalar y probar módulos de PrestaShop

Qué haríamos

Definiríamos el resultado comercial que falta, revisaríamos los ajustes nativos y los módulos que ya tienes y compararíamos un módulo nuevo solo si siguiera habiendo una carencia. La vía adecuada depende de tu tienda actual: su configuración, versiones de módulos, integraciones, personalizaciones del tema, datos de catálogo y clientes, mercados y equipo que la mantendrá. Sustituir una herramienta que funciona requiere un beneficio que puedas demostrar en esa tienda.

Realiza el cambio elegido en una copia de pruebas protegida que refleje producción, ensaya su configuración y reversión y planifica después el paso a producción. Acuerda quién puede detener el despliegue, qué pruebas permiten reabrir y cómo conciliarás pedidos o mensajes de integraciones si hace falta recuperar el sistema. No copies una base de datos de pruebas antigua sobre una tienda activa para publicar un ajuste de módulo.

Si necesitas comparar candidatos y desplegar la solución, el PrestaShop Module Selection & Fit Assessment prueba las distintas vías en una copia controlada de la tienda; para un módulo ya elegido, el PrestaShop Module Installation & Configuration Service lo instala, aplica los ajustes acordados y verifica el recorrido afectado.

Redacta un requisito que puedas aceptar o rechazar

Da a cada candidato el mismo documento de requisitos. Describe la tarea que falla hoy, quién la realiza y el resultado que justificaría el cambio. Separa el comportamiento esencial de la presentación opcional para que una lista extensa de funciones no oculte un requisito sin cubrir.

• Contexto de la tienda: versiones exactas del núcleo, PHP de la web y tema, módulos y personalizaciones relevantes, idiomas, monedas, tiendas y grupos de clientes.
• Límites de datos e integración: campos del catálogo, registros de clientes o estados de pedido implicados, adónde deben ir después esos registros y qué sistema controla cada valor.
• Pruebas de aceptación: un producto o carrito representativo, pasos para reproducir, resultados esperados para clientes y personal y una comparación con la tienda actual.
• Condiciones operativas: quién configura la función, qué acceso necesita, cómo se supervisa el trabajo en segundo plano y quién la mantiene tras el traspaso.
• Condiciones de salida: ajustes y registros que debes exportar o conservar, qué deben hacer la desactivación y la desinstalación y la vía de recuperación si falla el cambio.

Por ejemplo, «mejorar la entrega» es demasiado amplio para probarlo. «Ofrecer solo transportistas válidos y recalcular el total del envío con impuestos cuando un cliente que vuelve cambia su dirección, y después exportar el servicio elegido a nuestro sistema de pedidos» ofrece al proveedor un recorrido concreto que demostrar. Una captura de un selector de transportistas responde solo a una parte de ese encargo.

Comprueba la compatibilidad exacta con PrestaShop y PHP

Registra tu versión completa de PrestaShop, la versión de PHP del servidor web, la versión del tema y los módulos instalados en Parámetros avanzados > Información y el Gestor de módulos. Una afirmación como «compatible con 1.7» es menos útil que una versión concreta y una combinación de PHP probada.

La declaración de compatibilidad con el núcleo es $this->ps_versions_compliancy en la clase PHP principal del módulo. Por ejemplo, esta declaración usa la versión de la tienda en ejecución como límite superior:

$this->ps_versions_compliancy = [
    'min' => '1.6.1.0',
    'max' => _PS_VERSION_,
];

Un intervalo de versiones declarado es una restricción de instalación, no un informe de pruebas. El PHP del módulo se ejecuta con los permisos de la tienda y puede acceder a su base de datos, registros de clientes y archivos con permiso de escritura, así que las comprobaciones del navegador por sí solas no acreditan que el código sea seguro. Lee por separado las restricciones de PHP y bibliotecas de Composer. El entorno de ejecución de PHP debe satisfacer a la vez los requisitos del núcleo, el módulo y sus dependencias. Una sintaxis nueva puede fallar antes de que el módulo muestre un error útil. No rebajes un requisito en el código para saltarte la comprobación.

Fija cada entorno de pruebas a una versión exacta del núcleo y de PHP. Para pruebas históricas, PrestaShop 1.7.6 solo admite hasta PHP 7.2; 1.7.8 hasta 7.4; y PrestaShop 8.0 a 8.2 hasta 8.1. Estas combinaciones antiguas son referencias de compatibilidad, no recomendaciones actuales de alojamiento.

Los requisitos de PrestaShop 9 distinguen 9.0, que admite PHP 8.1 a 8.4, de 9.1, que admite PHP 8.1 a 8.5. Comprueba los requisitos de tu versión de destino exacta, incluida 9.2, antes de elegir su entorno de ejecución. Ejecuta las pruebas pertinentes en 9.2 además de las versiones anteriores que admitas.

Inspecciona override/, los scripts de instalación y actualización, las definiciones de servicios y los archivos copiados fuera del módulo. Un directorio de overrides vacío solo indica que no hay overrides convencionales. Busca también registros de hooks y compáralos con los registros realmente instalados para cada tienda.

Prepara un entorno de pruebas y una copia de seguridad recuperable

Tu copia de pruebas debe coincidir con producción en núcleo, PHP y extensiones, motor de base de datos, tema, módulos, ajustes de tienda y configuración del servidor. Compara el contexto multitienda, los idiomas, las monedas, la caché y la conectividad saliente. Una demo limpia es útil para ver una función; no reproduce las interacciones de tu tienda.

Protege la copia del acceso público y de la indexación en buscadores. Elimina o anonimiza los datos de clientes cuando sea viable. Desactiva las capturas de pago reales, los correos a clientes, los webhooks de producción y las integraciones programadas. Usa credenciales sandbox de pago y un buzón controlado.

1. Haz una copia de seguridad conjunta de todos los archivos de la tienda y la base de datos, incluidos overrides, personalizaciones del tema y configuración.
2. Conserva el ZIP y la versión exactos del módulo actual y una exportación de configuración si está disponible.
3. Guarda las copias fuera de la raíz web pública y confirma que puedas restaurarlas.
4. Registra una referencia inicial de las páginas y flujos que probarás.

Para una base de datos InnoDB, un desarrollador puede usar un volcado lógico coherente como el siguiente desde un directorio privado de copias de seguridad. Sustituye la base de datos y la cuenta por tus valores reales; coordina por separado las escrituras y las tablas no transaccionales.

mysqldump --single-transaction -u backupuser -p prestashop > before-module.sql

Consulta la guía de entornos de pruebas y la guía de copias de seguridad para la preparación completa.

Instala el ZIP y diagnostica los fallos de subida

En PrestaShop 8 y 9, abre Módulos > Gestor de módulos > Subir un módulo y sube el ZIP instalable tal como se suministra. Conserva intacto el nombre técnico de su carpeta. Por ejemplo, mprcanonicalmanager/mprcanonicalmanager.php debe quedar en modules/mprcanonicalmanager/, con sus dependencias y demás directorios junto al archivo principal.

Una descarga del repositorio puede tener un directorio contenedor extra u omitir dependencias compiladas. Usa el paquete de versión destinado a la instalación. Copiar archivos por sí solo no ejecuta install(), que puede crear tablas, registrar hooks, añadir pantallas de administración y cargar valores predeterminados.

Si falla la subida desde el navegador, compara el tamaño del archivo con los valores efectivos de PHP web upload_max_filesize y post_max_size. Este último también debe alojar el resto de la petición POST. Información muestra algunos valores de PHP; obtén post_max_size de los ajustes PHP del alojamiento o de un diagnóstico privado del entorno de ejecución web. php -i en CLI puede leer una configuración distinta.

; Example limits for a ZIP smaller than 64 MB
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300

Son ejemplos, no requisitos mínimos para todos los módulos. Comprueba también los límites de cuerpo del proxy y del servidor web, el almacenamiento temporal, el espacio de extracción, las extensiones necesarias y los permisos de escritura. Usa directivas php_value en .htaccess solo cuando la integración PHP de Apache las admita; no son una solución general para PHP-FPM.

Si es necesario, extrae el ZIP localmente y sube su único directorio técnico de módulo por SFTP. Después usa el Gestor de módulos para instalarlo. Confirma la propiedad y el acceso del usuario efectivo de PHP en vez de conceder permisos de escritura a todo el mundo.

Observa var/logs/ y los registros de PHP-FPM y del servidor web durante la instalación. Parámetros avanzados > Registros es otra posible fuente, pero los fallos tempranos pueden no llegar nunca a ese registrador. Un módulo visible en disco puede haber fallado al crear tablas, registrar hooks, cargar dependencias o ejecutar otro paso del instalador. Conserva el error y comprueba el estado parcial antes de reintentar. No borres a ciegas tablas del módulo ni roles de autorización.

Tras completarse, abre Configurar, proporciona los ajustes comerciales necesarios, guarda y recarga. Comprueba los permisos, las traducciones, las entradas de menú y el contexto de tienda previsto.

Ejecuta pruebas funcionales y de regresión

Convierte la lista de funciones documentadas y tu documento de requisitos en una lista de comprobación con resultados esperados. Prueba la persistencia de la configuración, los permisos y todos los tipos de página afectados. Usa los mismos datos de prueba antes y después de instalar. Conserva juntos el ZIP del módulo, la configuración, los pasos de prueba, los resultados esperados y reales y las pruebas anonimizadas para que el proveedor pueda reproducir un fallo.

1. Añade un producto al carrito desde su página, una categoría y los resultados de búsqueda. Estos puntos de entrada pueden tener marcado y JavaScript distintos aunque su modificación del carrito llegue al mismo CartController.
2. Completa la compra en modo sandbox. Confirma productos, combinaciones, direcciones, opciones de entrega, impuestos, descuentos, moneda y totales tanto en el pedido como en el sistema de pago.
3. Registra un cliente, comprueba el correo esperado, cierra sesión y vuelve a entrar. Comprueba el historial de la cuenta.
4. Prueba las búsquedas que admita tu tienda, incluidos nombres de producto, referencias y EAN cuando estén indexados.
5. Abre los detalles de pedido en administración. Comprueba la información del transportista, las pestañas, las notas y los permisos pertinentes del personal.
6. Vacía el carrito y repite las interacciones clave en móvil, incluida una ventana estrecha, por ejemplo de 375 píxeles.
7. Cambia a cada idioma, moneda y tienda pertinentes. Confirma que los ajustes y el contenido permanezcan en su ámbito previsto.

En las herramientas de desarrollo del navegador, inspecciona los errores de consola, las peticiones AJAX fallidas, los errores 404 de recursos y los hosts externos inesperados. Visita páginas donde aparece la función y páginas donde no debería hacer nada. Comprueba las copias de plantillas de módulos del tema en themes/your-theme/modules/ cuando una función actualizada no aparezca.

Comprueba por separado las tareas programadas y los webhooks. Confirma su autenticación, frecuencia, destino y gestión de fallos. Que una página cargue correctamente no demuestra que el trabajo en segundo plano funcione.

Analiza un módulo que supera la demostración pero falla en tu tienda

Supongamos que pruebas un bloque de recomendaciones de productos en una tienda multilingüe con combinaciones y exportación de pedidos. La demostración acredita que aparecen recomendaciones. Tu prueba de aceptación también debe demostrar que los compradores siguen comprando el artículo previsto y que el personal recibe el pedido correcto.

Si la adición al carrito desde categorías funcionaba antes de instalar y ahora falla, conserva esa comparación y detén el despliegue. Aísla la interacción mediante las comprobaciones de conflictos indicadas abajo y repite después el mismo caso de prueba tras la corrección. Superar la prueba de visualización de recomendaciones no compensa un recorrido de compra roto.

Mide recursos, consultas y dependencias externas

Compara cargas de página repetidas en las mismas condiciones. Separa los resultados con caché fría y caliente. Registra el tiempo de respuesta del servidor, el número de peticiones, el tamaño transferido y las consultas lentas. Define límites de rendimiento aceptables para tu tienda en vez de tratar un umbral fijo de milisegundos como universal.

Los módulos tienen impactos distintos. Una herramienta de administración puede no añadir recursos a la tienda; una función condicional puede ejecutarse solo en ciertas peticiones. Cuenta los hooks, consultas y recursos que realmente se ejecutan. Perfila las llamadas repetidas a la base de datos dentro de bucles de productos y las peticiones externas síncronas durante el renderizado de páginas.

El modo de depuración y el perfilado son independientes. El perfilador heredado de consultas y tiempos usa _PS_DEBUG_PROFILING_ en config/defines.inc.php. El perfilador de Symfony se aplica a peticiones Symfony aptas cuando está configurado. Ninguno garantiza un desglose temporal para todas las peticiones de la tienda o fallidas. Usa el perfilado brevemente en un entorno de pruebas protegido.

Prefiere registerStylesheet() y la API de scripts correspondiente para gestionar recursos e integrarlos con CCC. Comprueba también el versionado explícito y la invalidación en los despliegues. El registro no garantiza automáticamente la renovación de caché, y un enlace directo no se convierte en 404 simplemente por borrar la caché.

Puedes listar los hosts de recursos observados por la página actual con este ejemplo para la consola del navegador:

const hosts = {};
for (const entry of performance.getEntriesByType('resource')) {
    const host = new URL(entry.name, location.href).host;
    if (host && host !== location.host) {
        hosts[host] = (hosts[host] || 0) + 1;
    }
}
console.table(hosts);

Revisa tus propios subdominios de CDN además de los terceros. Esta lista cubre los recursos observados en el navegador, no el tráfico entre servidores ni todas las formas de transferencia de datos. Pregunta por qué hace falta un nuevo servidor, qué datos recibe y cómo se comporta la función cuando no está disponible. Repite la observación con los estados pertinentes de consentimiento e inicio de sesión, ya que una solicitud puede aparecer solo tras una interacción o un cambio de permisos.

En el entorno de pruebas, utiliza el bloqueo de solicitudes del navegador para simular que no está disponible un servidor externo específico de la función y vuelve a recorrer la página. Registra si la función opcional falla de forma clara y si la navegación y la compra siguen funcionando. Esto solo prueba la dependencia del navegador; pide al desarrollador que ensaye por separado los tiempos de espera del servidor y los fallos de llamadas en segundo plano.

Prueba las actualizaciones y prepara una reversión completa

Lee el historial de cambios y los requisitos antes de sustituir archivos. Haz copias de los archivos y la base de datos, registra la versión instalada y conserva ambos ZIP. Prueba una actualización desde la versión real de producción, no solo una instalación nueva de la versión nueva.

Usa el flujo compatible de actualización del Gestor de módulos o de subida de ZIP. Comprueba que avance la versión instalada en la base de datos y que se completen las migraciones upgrade/install-X.Y.Z.php aplicables. Copiar archivos nuevos por SFTP por sí solo no demuestra que se hayan ejecutado las migraciones.

La configuración suele residir en la base de datos, pero el código de actualización puede cambiarla o eliminarla. Compara los ajustes guardados, tablas personalizadas, hooks, permisos y copias de plantillas del tema tras actualizar. Trata Restablecer por separado: puede desinstalar y reinstalar un módulo, con un tratamiento de datos que depende de la implementación y las opciones de conservar datos. No es un sustituto seguro de una migración.

Ensaya la instalación desde cero, la actualización, la desactivación, la reactivación y la desinstalación como operaciones distintas en copias desechables. Compara cada resultado con la política de conservación documentada. Una desinstalación limpia puede conservar deliberadamente reseñas o registros de integración; borrarlo todo no es automáticamente lo correcto. Exporta los registros que necesites antes de probar una limpieza destructiva.

Prefiere Parámetros avanzados > Rendimiento > Borrar la caché. También puede ser adecuado un borrado coordinado por CLI:

php bin/console cache:clear --env=prod

Ejecútalo desde la raíz de la tienda con el binario PHP y usuario del sistema de archivos correctos. Si es necesaria una recuperación del sistema de archivos, detén el tráfico entrante y los procesos de trabajo, confirma las rutas y la propiedad de la caché, reconstrúyela y verifica la tienda antes de reabrir. La caché de PrestaShop es regenerable; las peticiones simultáneas, la falta de dependencias y los permisos pueden hacer que la reconstrucción falle. Coordina por separado OPcache web y cualquier caché de página completa, proxy o CDN.

Cuando debas volver a una versión anterior

1. Pon la tienda en producción afectada en mantenimiento y detén las tareas que puedan escribir datos relacionados.
2. Guarda el estado averiado, los registros y los detalles de transacciones recientes para el diagnóstico.
3. Restaura un directorio limpio del módulo anterior sin mezclar versiones. Conserva la copia desplazada fuera del directorio público de módulos.
4. Restaura el estado de base de datos correspondiente o aplica una migración inversa proporcionada por un desarrollador. Los archivos por sí solos no pueden revertir cambios de esquema o datos.
5. Concilia los pedidos, pagos y cambios de stock realizados después de la copia. No sobrescribas transacciones nuevas de producción con una instantánea antigua de toda la tienda.
6. Borra las cachés pertinentes y repite las pruebas de función, configuración y compra.

No uses Desinstalar ni Eliminar como paso para volver a una versión anterior salvo que comprendas su limpieza. Un módulo puede eliminar intencionadamente sus tablas y ajustes. Obtén el ZIP anterior exacto de un archivo de versiones o del soporte en vez de asumir que todas las cuentas ofrecen versiones antiguas.

Aísla los fallos y resuelve personalizaciones solapadas

En un entorno de pruebas, reproduce el fallo con los dos módulos sospechosos, con cada uno por separado y sin ninguno. Registra el estado tras cada cambio. Para un conjunto mayor, desactiva un grupo controlado y después acota. Prueba dependencias y combinaciones: el último módulo activado puede revelar una interacción sin ser su única causa.

Varios módulos pueden compartir un hook. La posición puede importar para la salida visual, pero el orden no es una solución universal. Compara modificaciones del carrito, datos devueltos, listeners de eventos, selectores CSS, bibliotecas incluidas, plantillas y configuración. Los hooks y los servicios Symfony reducen el acoplamiento directo con el núcleo; no garantizan un funcionamiento sin conflictos.

El núcleo puede fusionar overrides que añadan métodos diferentes a una misma clase. Los métodos, propiedades o constantes solapados pueden provocar un conflicto explícito. No fusiones dos métodos de antemano y supongas que el siguiente instalador los aceptará. Acuerda un parche de compatibilidad con un responsable único de la implementación combinada y un procedimiento documentado de instalación, actualización y eliminación.

Inspecciona los archivos de overrides, sus comentarios de propiedad, los ajustes activos de overrides y las entradas de ruta del índice de clases. Una lista de nombres de clases por sí sola no identifica responsables ni demuestra que un archivo esté huérfano. Un archivo en disco no se ejecuta automáticamente en todas las páginas; un override se usa cuando se carga su clase mapeada.

Si no puedes acceder al back office, usa la acción normal de desactivar o el comando de consola compatible cuando sea posible. Renombrar un directorio de módulo es un aislamiento de archivos de emergencia y necesita una forma documentada de volver atrás. No desinstala overrides ni deshace servicios compilados ni cambios de base de datos. Conserva los registros antes de borrar las cachés. Ante una respuesta en blanco, inspecciona el estado HTTP y los registros del servidor; usa salida de depuración solo en una copia protegida y desactívala después porque puede revelar configuración sensible.

Consulta la resolución de problemas de PrestaShop para la recuperación según el síntoma.

Automatiza comprobaciones sobre el paquete de versión

Para desarrollar módulos, usa PHPUnit para lógica de negocio que puedas probar de forma independiente, como calculadoras y formateadores. Añade cobertura de integración para instalación, migraciones, hooks y almacenamiento con ámbito de tienda. Usa pruebas de navegador para flujos de cliente significativos como iniciar sesión, añadir al carrito y finalizar la compra.

Crea una matriz de las combinaciones exactas compatibles de núcleo, PHP, base de datos y tema. Incluye las versiones de destino actuales y la versión más antigua que realmente afirmes admitir. Guarda los resultados de pruebas con el ZIP o commit exacto de la versión, no solo un intervalo de compatibilidad del código fuente.

Un flujo de CI puede construir el archivo, comprobar dependencias y sintaxis, instalarlo en tiendas limpias, actualizar desde versiones anteriores compatibles del módulo y ejecutar pruebas básicas de navegador. Los análisis estáticos de API obsoletas complementan las pruebas en ejecución; no las sustituyen. Prueba la desinstalación y la conservación de datos documentada en copias desechables.

Evalúa fichas, proveedores y condiciones de compra

Usa tu documento de requisitos al comparar fichas de producto. Compara la misma función en tu propio catálogo mediante una demostración o prueba cuando esté disponible. Instala los candidatos por separado antes de probar una combinación prevista. Una demostración del proveedor muestra el comportamiento esperado; pregunta qué evaluación controlada está disponible para tu tienda real y si la licencia permite instalar en un entorno de pruebas privado.

• Compatibilidad: obtén requisitos precisos de núcleo, PHP y tema, incluidas las limitaciones conocidas.
• Mantenimiento: lee versiones fechadas, respuestas a incidencias y correcciones de seguridad. Una fecha de versión antigua necesita contexto; por sí sola no demuestra abandono.
• Documentación: busca requisitos, configuración, conservación de datos, tareas en segundo plano y pasos de recuperación.
• Reseñas: prefiere descripciones de una configuración real y del resultado del soporte a una media de estrellas.
• Acceso al código: comprueba si tu desarrollador puede revisarlo y mantenerlo. Los cambios del núcleo no documentados o las dependencias opacas merecen investigación.
• Seguridad: busca el nombre técnico y la versión exactos en Friends of Presta y en los avisos del responsable de mantenimiento. La ausencia de avisos publicados no demuestra seguridad. Compara las versiones afectadas, la gravedad y las correcciones disponibles; el mero número de avisos puede reflejar lo exhaustivamente que se ha examinado un módulo.

La revisión de Marketplace y los programas de calidad son señales útiles, pero tu tienda sigue necesitando pruebas en un entorno de pruebas. Un proveedor directo, un vendedor de marketplace, un proyecto de código abierto mantenido o un desarrollador a medida pueden ser opciones adecuadas. Compara el ámbito de licencia, el precio con impuestos, la renovación, las actualizaciones, el soporte, el trabajo personalizado y las condiciones de disputa de la oferta real. Evalúa la implementación y el mantenimiento del módulo concreto.

Las FAQ de soporte y actualizaciones de Marketplace describen Business Care y las condiciones de reembolso de las compras de complementos en Marketplace. Para las compras cubiertas por esas FAQ, Business Care incluye el primer año con la compra y se renueva automáticamente. Las solicitudes de reembolso deben presentarse por escrito; las condiciones de los complementos incluyen determinados problemas en el plazo de un mes, y el contacto previo con el vendedor es relevante en casos de mal funcionamiento. Vuelve a comprobar esas condiciones para tu compra, producto y país concretos antes de pagar, registra las condiciones y la fecha y conserva la conversación con soporte. No des por hecho un reembolso ni un plazo de respuesta.

Las ofertas gratuitas pueden ser proyectos comunitarios, ediciones lite, integraciones vinculadas a un servicio o productos descatalogados. Lee sus límites reales y obligaciones de soporte. Exigir una cuenta de terceros puede ser legítimo. Examina la finalidad de los datos, los destinatarios, la conservación y las condiciones contractuales en vez de tratar el registro de una cuenta como prueba de recopilación abusiva de datos.

Estima el coste total con tus costes reales de licencia, implementación, alojamiento, mantenimiento, soporte y migración. Que sea gratuito no significa que sea inseguro y pagar no garantiza soporte a largo plazo. Incluye la formación del personal, los servicios externos recurrentes, la exportación de datos y el trabajo de retirada. Compara los candidatos durante el mismo periodo con las condiciones reales del proveedor y las tarifas de tu equipo.

Una herramienta gratuita puede servir para una tarea definida: Security Scan informa de hallazgos de seguridad locales con ubicación y gravedad y ofrece pasos de corrección manual. No corrige la tienda ni certifica que un módulo candidato sea seguro. Usa un hallazgo para orientar la investigación y demuestra después el comportamiento pertinente en el entorno de pruebas.

Qué preguntar al desarrollador o la agencia

• ¿Qué versión has probado con esta combinación exacta de núcleo, PHP y tema? ¿Qué módulos o integraciones instalados necesitan un trabajo de compatibilidad aparte?
• ¿Puedes demostrar el recorrido de aceptación con nuestros datos representativos, incluidos el fallo y la recuperación, además de mostrar una pantalla de ajustes?
• ¿Cubre la licencia nuestras tiendas y el dominio privado de pruebas? ¿Quién recibe las descargas, actualizaciones y soporte si cambiamos de agencia?
• ¿Qué ajustes, tablas, overrides, tareas programadas y servicios externos cambian y qué queda tras desactivar o desinstalar?
• ¿Quién corrige una interacción entre proveedores, qué trabajo de soporte está incluido y quién mantiene un parche de compatibilidad a medida?
• ¿Qué pruebas recibiremos en el traspaso y quién se encarga de la reversión y de conciliar los nuevos pedidos si falla el lanzamiento?

Audita los módulos ya instalados

Enumera los módulos activos e inactivos, sus responsables, versiones, finalidad comercial, dependencias y preparación para actualizarse. Marca cada uno para conservar, configurar, actualizar, sustituir o retirar, con una persona responsable de la decisión. Elimina funciones redundantes solo después de comprobar qué depende de ellas. Desactiva primero para una prueba reversible y desinstala después mediante la acción admitida, eliminando los archivos sin uso según el plan de conservación.

No deduzcas que un módulo no se usa porque su bloque en la tienda esté vacío. Un módulo aparentemente inactivo puede exportar pedidos, ofrecer una acción administrativa o ejecutar un feed ocasional. Pregunta a la persona responsable de ese flujo y observa su ejecución programada pertinente antes de retirarlo. Eliminar una dependencia porque no tiene un widget visible puede romper una integración que funciona.

La desactivación normal impide la ruta estándar de ModuleFrontController para un módulo inactivo. No elimina endpoints PHP independientes, overrides instalados ni todo el código de integración. Los archivos residuales merecen revisión de seguridad aunque no añadan un coste de ejecución medido.

Estos ejemplos de solo lectura usan ps_. Sustitúyelo por tu prefijo real. En multitienda, inspecciona también las asociaciones de tiendas; el indicador global active no es un inventario completo tienda por tienda.

SELECT name, version, active
FROM ps_module
ORDER BY active ASC, name;

SELECT hm.id_module, hm.id_hook, h.name AS hook_name
FROM ps_hook_module hm
LEFT JOIN ps_module m ON m.id_module = hm.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.id_module IS NULL;

SELECT m.name, COUNT(*) AS registrations
FROM ps_hook_module hm
JOIN ps_module m ON m.id_module = hm.id_module
GROUP BY m.name
ORDER BY registrations DESC;

Los registros de hooks pueden incluir filas separadas por tienda y un recuento alto no demuestra una ejecución costosa. Investiga los registros huérfanos en vez de borrar filas a mano. Compara la estructura de base de datos antes y después de instalar y desinstalar, incluidos los datos conservados documentados. Las comprobaciones de archivos en override/classes/ y override/controllers/ complementan el inventario de base de datos.

Al revisar código SQL, prefiere vincular parámetros cuando sea posible. En código heredado, comprueba el escape de valores correcto para el contexto, las conversiones a entero y el tratamiento de identificadores. Traza cómo llega la entrada no fiable a cada consulta y cómo se protege ese contexto.

Elige funciones según las carencias reales de tu tienda

Comprueba primero las capacidades nativas. No existe un conjunto universal de módulos esenciales ni un umbral de número de productos que haga obligatoria una extensión.

La documentación del proceso de compra nativo en una página explica los cambios de compatibilidad de la versión 9.2. Consulta las páginas de ayuda de los módulos enlazadas para los detalles de configuración.

Toma decisiones de lanzamiento antes de que afecten a registros reales

Fija una política estable de URL antes de publicar enlaces. El núcleo genera URL a partir de las rutas y los datos de entidad actuales; los productos no guardan una URL completa inmutable al crearse. Los ID numéricos no crean contenido duplicado por sí mismos. Revisa las categorías predeterminadas, la redirección canónica y los enlaces generados por el tema antes de cambiar rutas. Mapea las URL antiguas publicadas cuando un cambio requiera redirecciones.

Define pronto la política de metadatos y datos estructurados y revisa después la salida real. Las entidades existentes pueden recibir plantillas de metadatos en bloque en SEO Revolution; distingue los cambios en metadatos almacenados de la salida dinámica. No tienes que completar todo manualmente.

Acuerda la política de facturación con tu contable antes de emitir facturas. Su creación depende de los ajustes de facturas y de la marca de factura del estado de pedido. El núcleo admite prefijos, un número inicial y reinicio anual. Aplica las reglas de corrección y auditoría de tu jurisdicción al cambiar documentos emitidos o numeración.

Decide qué datos de clientes necesitas realmente en el registro. El modo B2B nativo ofrece campos de empresa e identificación; los datos personalizados necesitan una extensión de campos adecuada y una finalidad lícita de recogida. Customer Extra Info (IP Ban) no es un constructor de campos de registro. Planifica cómo podrán facilitar los clientes existentes los nuevos datos obligatorios.

Configura la analítica y el acceso a Search Console antes de las campañas cuando sea viable. El seguimiento no puede recrear eventos de interacción no recogidos. Respeta los requisitos de consentimiento y verifica la referencia inicial antes de usarla para decidir. Prueba el proceso de compra antes del lanzamiento; una sustitución de pago necesita una ventaja de funciones o compatibilidad demostrada para tu tienda.

Añade chat, fidelización, widgets sociales y otras funciones de presentación cuando puedas identificar su finalidad y medir su efecto. Instala un cambio cada vez. Tras el despliegue en producción, repite las comprobaciones críticas y supervisa los registros. Si necesitas ayuda con un módulo MPR, envía su versión, tu entorno, los pasos para reproducir, los resultados esperados y reales y registros anonimizados a través de soporte.

Decide si el cambio probado puede pasar a producción

Usa los resultados de las pruebas como decisión de publicación, no como nota media. Un fallo de compra pendiente, un acceso incorrecto a datos de clientes, una transferencia de datos sin explicar o una recuperación no demostrada bloquean el lanzamiento aunque el resto de comprobaciones se supere. Registra expresamente las limitaciones menores, con un responsable y una acción acordada.

1. Fija el paquete probado y registra su versión, dependencias, ajustes y la configuración exacta de la tienda utilizada. Revisa los cambios en producción desde que se creó la copia.
2. Obtén la aceptación del responsable del negocio sobre los resultados de clientes y personal. Asegúrate de que quienes procesan pedidos sepan qué cambia y dónde aparecen los fallos.
3. Elige la franja de despliegue, realiza la copia de seguridad de archivos y base de datos correspondiente y confirma los pasos de reversión ensayados. Pausa las tareas y el tráfico afectados donde la migración lo requiera.
4. Aplica a producción la instalación o actualización admitida y la configuración registrada. Comprueba el contexto de tienda previsto, las credenciales y los endpoints; los valores de prueba no deben convertirse en ajustes de producción sin que se advierta.
5. Ejecuta las comprobaciones críticas en producción apropiadas para el módulo mediante el procedimiento autorizado de cada proveedor. Comprueba el pedido, correo o registro posterior resultante además de la página visible.
6. Reanuda de forma controlada las tareas afectadas, supervisa los registros y las colas de integración y designa a la persona que responderá a una comprobación fallida. Si reviertes el cambio, conserva y concilia las transacciones creadas durante esa franja.

Entrega al equipo los ajustes finales, el paquete conservado, las pruebas, las limitaciones conocidas, el contacto de soporte y el procedimiento de recuperación. Reutiliza las comprobaciones pertinentes tras el próximo cambio de núcleo, PHP, tema o integración; un informe de aceptación antiguo describe la configuración que superó las pruebas entonces.

Preguntas habituales de los propietarios

¿Cuántos módulos son demasiados?

Usa el inventario para identificar módulos sin finalidad comercial o responsable de mantenimiento y las pruebas medidas para detectar interacciones costosas. El número por sí solo no indica si una tienda con mucha actividad está sana o si una casi vacía tiene un fallo grave.

¿Puedo hacer las comprobaciones por mi cuenta?

Puedes comparar el comportamiento visible, los ajustes guardados y las solicitudes del navegador en el entorno de pruebas. Pide a un desarrollador que inspeccione los cambios de esquema, permisos, llamadas del servidor y migraciones que no puedas evaluar. Superar una lista de comprobaciones del navegador aporta pruebas útiles, pero no es una auditoría completa de código o seguridad.

¿Una insignia de Marketplace, una licencia de pago o un análisis reciente garantizan seguridad?

No. Cada uno responde a parte de la decisión de compra. Exige pruebas para tu configuración real, investiga los hallazgos críticos y asegúrate de tener un responsable de mantenimiento y una vía de recuperación antes del lanzamiento.

¿Debo actualizar un módulo antiguo o sustituirlo?

Pregunta si una actualización con soporte cumple el requisito y conserva tus datos y personalizaciones. Si no, compara la sustitución o un desarrollo de alcance definido, incluidos los costes de migración y retirada. Conserva la versión que puedas restaurar mientras ensayas la vía elegida.

¿Una desinstalación correcta demuestra que funcionará la reversión?

Prueba la recuperación que realmente utilizarías tras una actualización fallida. La desinstalación puede eliminar registros, mientras que volver a una versión anterior puede requerir archivos y cambios de base de datos correspondientes. Haz la prueba de desinstalación en una copia desechable y utiliza el procedimiento de recuperación documentado para los datos comerciales.

¿Puedo añadir estas funciones a una tienda que ya está vendiendo?

Sí. Define el efecto sobre los registros existentes, las URL publicadas, los documentos emitidos y los sistemas conectados, y ensaya después el cambio en una copia. Usa actualizaciones masivas o migraciones admitidas cuando sea necesario y programa el cambio; añadir una función no obliga automáticamente a reconstruir la tienda.