Licencias de módulos mypresta.rocks: activación y actualizaciones

Qué haríamos

Documentaríamos la tienda seleccionada, el dominio, la cuenta titular y las versiones instaladas antes de elegir una vía de activación o actualización. La vía adecuada depende de tus módulos actuales, tema, integraciones, datos de módulos guardados, mercados y permisos disponibles del personal. Identifica la fase que falla antes de cambiar archivos o asignar la licencia a otro sitio.

Para actualizar archivos o trasladar un dominio, ensaya en una copia privada de pruebas con la misma configuración y personalizaciones pertinentes. Confirma cómo puede activarse esa copia antes de vincularla y aísla los pagos reales, los mensajes a clientes y las tareas de integración. Acuerda el paso a producción, las comprobaciones de funciones y los pasos de reversión con la persona que gestiona los archivos y la base de datos de la tienda.

Si quieres que instalemos y configuremos el módulo elegido, el PrestaShop Module Installation & Configuration Service cubre los ajustes acordados y la verificación del recorrido pertinente.

Elige la siguiente acción según el estado mostrado

Separa la activación, el acceso en ejecución y las actualizaciones

El sistema compartido de licencias vincula la instalación de un módulo con la identidad de su tienda y la autoridad de licencia aceptada. Sus páginas del back office gestionan la activación, el estado, las actualizaciones y el acceso del soporte. Trátalos como estados relacionados en lugar de un único indicador booleano.

• Activación: el módulo y la tienda actuales cuentan con una autorización aceptada.
• Ejecución: el código instalado y la autorización firmada permiten ejecutar el módulo en este entorno.
• Acceso a actualizaciones: el servicio permite descargar un paquete compatible.
• Estado del soporte: el derecho a soporte y el acceso a tickets se presentan por separado.

Usa el estado mostrado y el resultado devuelto por la operación. Una asignación en el portal no demuestra por sí sola que esta instalación haya guardado una autorización de ejecución utilizable. Una descarga correcta de archivos no demuestra que una actualización haya finalizado.

Utiliza el proceso de activación de la tienda seleccionada

Activa la instalación prevista

Module Updates & Remote Assist permite instalar y actualizar tus módulos desde el back office mediante su espacio My modules. Instala el Connector antes de vincular tu cuenta. Si tu tienda no usa HTTPS en todas sus páginas, usa su vía de aprobación mediante código de dispositivo en mypresta.rocks. La vinculación da a la tienda acceso a tu cuenta; las licencias de cada módulo siguen determinando qué puedes instalar y actualizar.

1. Selecciona la tienda prevista en el back office y comprueba su dominio configurado. En multitienda, el Connector vincula cada tienda por separado, así que comprueba la tienda seleccionada antes de aprobar una conexión.
2. Al vincular con el Connector, inicia sesión y aprueba en mypresta.rocks. Introduce la contraseña de tu cuenta allí, no en la tienda.
3. Comprueba la cuenta, la tienda solicitada y el módulo antes de aprobar la solicitud de vinculación o activación correspondiente. Si has iniciado sesión con una cuenta incorrecta, resuélvelo antes de continuar.
4. Si el módulo que posees no está instalado, instálalo mediante el proceso compatible y abre después su espacio de activación. Sigue el resultado que aparezca allí, incluida cualquier solicitud de instalar su entorno de ejecución con licencia.
5. Vuelve a abrir el espacio del módulo y prueba su función prevista, como una visualización configurada en la tienda o una acción del personal. Documenta el resultado antes de devolver la tienda al equipo.

Detalle para desarrolladores: cómo funciona el intercambio de activación

La activación empieza en un contexto de tienda concreto. El proceso actual de intención de activación crea una solicitud de aprobación de corta duración, te envía a una URL de portal aprobada y consulta el resultado periódicamente. El verificador permanece almacenado con ámbito de tienda; el navegador recibe datos públicos de la intención, como la URL de aprobación y el plazo.

El proceso vincula el módulo, el dominio y la identidad de instalación y utiliza un desafío PKCE. Tras la aprobación, el paquete local valida y almacena la autorización devuelta. Las integraciones antiguas pueden seguir utilizando el proceso de confirmación por token. Mantén intactas sus validaciones de estado y verificador.

Introducir la clave manualmente es otra vía en línea. Envía una solicitud de asignación o verificación y completa la confirmación necesaria. Es útil cuando el proceso interactivo del portal resulta incómodo, pero no activa una tienda aislada sin acceso a la red.

No escribas una clave directamente en la configuración dando por hecho que la activación ha funcionado. El entorno de ejecución debe aceptar la autorización firmada correspondiente. Si la asignación se completa pero falla la activación local del entorno de ejecución, mantén visible esa distinción y reintenta mediante el proceso normal.

Un cambio de dominio o una instalación copiada modifica el contexto de vinculación. Selecciona la tienda prevista, comprueba su dominio configurado y usa el proceso de activación compatible. Los entornos de desarrollo y clonados pueden tener restricciones adicionales sobre las acciones que cambian el estado remoto de la licencia o del soporte.

Ejemplo práctico: traslado de dominio con cambios personalizados en el módulo

Supón que te trasladas a un dominio nuevo y el módulo tiene cambios locales en plantillas y una integración que exporta sus datos. Antes de cambiar la asignación de producción, pregunta cómo se autorizarán la copia de pruebas y el dominio final. Una clave copiada o una activación correcta en el entorno de pruebas no establece la autorización para el dominio final.

1. Documenta el dominio actual, la versión del módulo, los archivos modificados y la salida esperada de la integración. Acuerda qué archivos y datos restaurarías si el cambio falla y crea después una copia restaurable.
2. Prepara la copia privada de pruebas y usa su vía de activación permitida. Ensaya la actualización o instalación del entorno de ejecución admitidas y conserva los cambios personalizados mediante un paso de desarrollo acordado.
3. Prueba el recorrido del cliente o del personal que cubre el módulo con datos representativos y comprueba después la salida de la integración sin enviarla a las operaciones reales.
4. En el momento acordado del cambio, confirma el contexto final de tienda y dominio, completa su activación admitida y repite la comprobación de la función. Usa el plan de recuperación acordado si el cambio falla.

Si siguen entrando pedidos durante el traslado, acuerda cómo conservar los pedidos nuevos y los datos del módulo al revertirlo. Restaurar una base de datos puede eliminar cambios realizados desde la copia de seguridad; el plan de reversión debe tenerlos en cuenta.

Pasa de la autorización de demo a la ejecución con licencia

Un módulo puede detectar una asignación para la tienda actual y recuperar la activación correspondiente. El sistema local debe validar la autorización devuelta y hacer utilizable el entorno de ejecución antes de que el back office indique que la instalación está activada.

Algunas instalaciones también necesitan recibir el entorno de ejecución con licencia mediante el actualizador. Esto sustituye los archivos del módulo manteniéndolo instalado y conservando los datos de ejecución compatibles. Comprueba si la página solicita activar, instalar el entorno de ejecución con licencia o completar una actualización.

Una asignación en el portal no reescribe directamente todos los archivos de licencia incluidos en el paquete. Sigue el estado mostrado en el espacio del módulo. Conserva una copia de seguridad completa de la tienda y usa el ZIP personalizado de respaldo únicamente mediante la vía de actualización compatible cuando no se pueda usar la entrega con un clic.

Gestiona los fallos de actualización de licencia sin suponer una revocación

La actividad del back office puede solicitar una actualización de la licencia después de renderizar la página. La vía de verificación de claves de pago normalmente limita las comprobaciones salientes automáticas a un intervalo de una hora. Una comprobación explícita u otro estado de autorización pueden seguir una vía distinta, así que esto no supone una promesa universal de una sola comprobación por hora.

Si una acción no está disponible para un empleado, compara su permiso de edición con el que exige esa acción antes de considerarlo un fallo de licencia. Si varias tiendas comparten un back office, anota qué tienda produjo el error.

En la vía de compatibilidad de claves de licencias de pago, una clave suspendida se conserva por separado de la clave activa. Restaurarla requiere una verificación aceptada y un empleado autorizado para realizar la activación. La reasignación en el portal no es una promesa incondicional de restauración local inmediata.

Las autorizaciones gratuitas, de demo y de pago tienen políticas distintas. Una concesión gratuita puede mostrar un aviso de contacto sin bloquear la ejecución, mientras que una demo tiene una caducidad y un plazo sin conexión. No conviertas el comportamiento ante fallos de red de las claves de licencias de pago en una promesa de que todos los entornos de ejecución funcionan sin conexión indefinidamente.

Una autorización más reciente aceptada no debe sobrescribirse con una respuesta anterior que llegue tarde. Utiliza el almacén compartido y sus reglas de comparación/bloqueo en lugar de mantener otra caché de estado en paralelo.

Comprueba, descarga y finaliza una actualización

El actualizador separa las comprobaciones de elegibilidad, la preparación de la descarga, la instalación de archivos y la finalización de la actualización del módulo en PrestaShop. Usa el resultado de cada fase.

1. Comprueba la disponibilidad de la actualización, la compatibilidad y el derecho de descarga devuelto.
2. Solicita la URL de descarga autorizada mediante el descargador compartido.
3. Descarga y valida el ZIP, incluida la identidad del módulo y las comprobaciones aplicables a los archivos protegidos.
4. Comprueba si hay cambios locales. Si los cambios necesitan confirmación explícita, muestra los archivos afectados y la opción de copia de seguridad.
5. Crea la copia de archivos del módulo antes de sustituirlos y conserva los datos de ejecución compatibles.
6. Instala y verifica los archivos del módulo y completa después sus pasos de actualización en PrestaShop y cualquier trabajo de infraestructura necesario.
7. Lee cualquier aviso restante o estado de finalización pendiente y verifica la función real del módulo.

Una copia de archivos del módulo no es una copia completa de la base de datos. El código personalizado no se fusiona automáticamente con la nueva versión. Mantén una vía de restauración de la tienda probada antes de actualizar una tienda en producción.

El instalador intenta restaurar su copia de seguridad de archivos ante los fallos de sustitución o verificación que contempla. Los avisos de caché y la finalización pendiente de la actualización pueden aparecer después de instalar los archivos. No presentes esos estados como una actualización sin incidencias y totalmente completada.

Los controles de activación y actualización específicos del módulo se explican en su página de ayuda. Si el resultado mostrado sigue sin estar claro, utiliza soporte e indica las versiones del módulo, PrestaShop y PHP y el resultado exacto de la operación.

Integración para desarrolladores: usa las API compartidas de controlador y cliente

Para la integración en el back office, usa MyPrestaRocks\License\LicenseUI en un controlador basado en MPRAdminController o la base compartida de controladores de licencia. El trait proporciona la presentación de licencia y los hooks de actualización del entorno de ejecución que espera la base de administración.

El antiguo MyPrestaRocks\License\AdminUpdateControllerBase es un alias de compatibilidad del paquete de actualizaciones. Utiliza el espacio de nombres canónico de actualizaciones para nuevas integraciones.

Resuelve los endpoints del proveedor desde el contexto de compilación/configuración de confianza del módulo. No aceptes una URL de API arbitraria de una solicitud del navegador. Mantén el nombre del módulo y el contexto del directorio asociados a las llamadas de API para que la verificación de respuesta utilice la identidad correcta del emisor.

Distingue entre el éxito del transporte, una respuesta de negocio y el almacenamiento local correcto. No reduzcas todo el proceso a HTTP 200 o una respuesta no vacía. Conserva los códigos de error estructurados para el mensaje del back office y los registros, sin exponer claves, verificadores ni tokens.

Integración para desarrolladores: conserva permisos, firmas y límites de entorno

Conserva la validación del token de administración y las comprobaciones de acceso del controlador de PrestaShop. Las acciones de licencia que cambian el estado requieren POST y el permiso de edición de la pestaña. Un empleado con acceso de solo lectura puede leer la página sin obtener permiso para activar una licencia o modificar el soporte.

El cliente compartido clasifica las acciones de API. Las operaciones de lectura, las escrituras de activación y las operaciones de vinculación de demo siguen políticas distintas. Una acción sin clasificar se bloquea. Utiliza esa política en lugar de eludirla con una solicitud HTTP separada.

La configuración de emisores de confianza y la validación de respuestas firmadas protegen la autorización aceptada. PKCE, la identidad de la solicitud, los nonces y los recibos firmados cumplen funciones distintas del protocolo. Un contenido con apariencia de firma no basta si no es válido para este módulo, vinculación y secuencia aceptada.

Conserva intactos los archivos de licencia e integridad distribuidos. La autorización de ejecución puede depender de la compilación personalizada y sus archivos firmados. No copies archivos protegidos del módulo de otro dominio ni edites la autoridad almacenada para borrar un error. Restaura el paquete correcto y usa el proceso de activación normal.

Lee la guía de integridad para las comprobaciones separadas de archivos instalados e infraestructura.

Delimita el estado almacenado y reúne diagnósticos útiles

El almacén de configuración compartido delimita el estado modificable de la licencia por módulo, tienda y un contexto derivado del dominio. Una identidad de instalación y los recibos firmados añaden información de vinculación del protocolo. No supongas que un valor de configuración global autoriza todas las tiendas de una multitienda.

El estado puede incluir la clave activa o suspendida, la hora de activación, el tipo y la caducidad de la licencia, el estado del soporte, el endpoint de verificación de confianza, los recibos aceptados, el contexto de presentación en caché y las marcas temporales de comprobación. Trata los secretos y la autoridad firmada de forma distinta al estado destinado solo a mostrarse.

Los mensajes de estado incluyen inglés, alemán, francés, polaco, italiano y español. Conserva los códigos estructurados al traducir el mensaje visible para que los desarrolladores puedan diagnosticar el mismo resultado en distintos idiomas.

Para informar de un fallo, reúne la tienda y el dominio actuales, las versiones del módulo y los paquetes, las versiones de PrestaShop y PHP, la acción fallida, la marca temporal y el código de error o registro saneado. Comprueba la conectividad de red, el almacenamiento local, los permisos de archivos y la finalización pendiente de la actualización según corresponda. Excluye de los informes públicos las claves, los verificadores de aprobación, los tokens y los archivos protegidos de licencia.

Qué preguntar a tu desarrollador o agencia

• ¿Qué tienda, dominio y cuenta titular vas a vincular y qué activación se permite para la copia de pruebas?
• ¿Qué cambios locales, comportamientos del tema, mercados e integraciones probarás y qué resultado demostrará que siguen funcionando?
• ¿La operación cambia los datos del módulo además de los archivos y cómo conservarás los pedidos o datos posteriores si la reviertes?
• ¿Quién realizará el paso a producción, comprobará el resultado y gestionará cualquier fase de actualización sin terminar?

Preguntas de los propietarios de tiendas

¿Debo desinstalar y reinstalar para arreglar la activación?

Empieza por el proceso de activación o recuperación admitido. La desinstalación puede afectar a los datos del módulo, según el módulo. Pide su procedimiento de recuperación antes de eliminar una instalación funcional.

¿Puede mi desarrollador encargarse de la activación?

Dale una cuenta de empleado nominativa con los permisos adecuados y organiza cualquier aprobación necesaria del titular. No incluyas contraseñas de cuentas ni secretos de licencia en tickets compartidos; confirma quién conservará el acceso después de la entrega.

¿La caducidad del soporte implica que el módulo debe dejar de funcionar?

Consulta por separado el derecho a soporte y la autorización de ejecución en el espacio del módulo. No deduzcas la revocación ni el acceso a actualizaciones a partir de la etiqueta de soporte. Si el derecho parece incorrecto, informa al soporte del módulo y de la tienda seleccionada.

¿Puede la tienda seguir vendiendo después de un aviso de actualización?

Comprueba qué ha fallado y prueba el recorrido del cliente afectado antes de decidir. Si no se puede utilizar, pide al desarrollador responsable que complete la recuperación o restaure el estado funcional probado, teniendo en cuenta los pedidos y datos nuevos.