El módulo solo se renderiza cuando la tienda no está en modo catálogo y cuando PrestaShop devuelve más de una moneda activa. Si solo hay una moneda activa, el hook no devuelve nada, por lo que no se muestra ningún selector. La ubicación también depende de que el tema renderice el hook displayNav2 en el header o área de navegación.

Sí. El módulo está diseñado para PrestaShop 1.7.7 y versiones posteriores y funciona en 1.7.x, 8.x y 9.x con PHP 7.1 o superior. Se registra en los hooks de la página de inicio (displayHome / displayHomeIntro) y también puede insertarse como widget, por lo que funciona en los temas compatibles sin cambios en el núcleo.

Sí. El módulo registra su propio selector en el hook displayNav2 y carga una hoja de estilos que oculta el selector de moneda nativo de escritorio de PrestaShop con #_desktop_ps_currencyselector { display: none !important; }. El cliente ve el desplegable compacto de símbolo del módulo en lugar del bloque de moneda predeterminado.

No desinstala ni edita el módulo nativo de moneda de PrestaShop. Simplemente renderiza un desplegable de reemplazo en el hook de cabecera/navegación y oculta el bloque de escritorio estándar con CSS. Eso hace el cambio reversible: desactiva o desinstala el módulo y el selector nativo puede volver a mostrarse, suponiendo que el tema todavía lo renderice.

El reemplazo usa el símbolo de la moneda actual en el toggle, opcionalmente muestra la etiqueta ISO junto a él y lista monedas activas en el desplegable. Los valores predeterminados son SHOW_LABEL=0 y SHOW_NAMES=1, así que el toggle se mantiene compacto mientras el desplegable sigue mostrando nombres completos de moneda. Cada opción es un enlace nofollow construido con los parámetros normales de cambio de moneda de PrestaShop.

La colocación sigue dependiendo del tema. Si el tema no llama a displayNav2 en el área de cabecera o navegación, el módulo no tiene dónde renderizar el selector aunque los assets se carguen.

Añade el Messenger oficial de Intercom a tu tienda PrestaShop. El módulo inserta el cargador de Intercom justo antes de la etiqueta body de cierre en cada página, de modo que solo pegas tu App ID de Intercom una vez en lugar de editar plantillas del tema. El widget se carga exactamente como el fragmento de instalación de Intercom, manteniendo plenamente operativos tu bandeja de entrada, los tours de producto y los mensajes automáticos.

El módulo crea eventos GA4 a partir de acciones reales de PrestaShop en lugar de una etiqueta genérica de página vista. Registra vistas de producto, añadir al carrito y cambios de cantidad, el inicio del pago, compras completadas, búsquedas en el sitio, inicios de sesión y creación de cuentas, cada uno enviado con los parámetros de comercio electrónico de GA4 correspondientes. Un generador de eventos integrado también permite definir eventos personalizados.

El módulo solo renderiza cuando la tienda no está en modo catálogo y cuando PrestaShop devuelve más de una moneda activa. Si solo hay una moneda activa, el hook no devuelve nada, así que no se muestra selector. La ubicación también depende de que el tema renderice el hook displayNav2 en el área de cabecera o navegación.

Comprueba primero estos puntos:

• Modo catálogo: si el modo catálogo está activado, el selector devuelve intencionadamente una cadena vacía.
• Recuento de monedas: el módulo llama a la lista de monedas activas de PrestaShop y se oculta cuando esa lista contiene una moneda o ninguna.
• Hook del tema: el selector se renderiza solo mediante displayNav2. Algunos temas personalizados eliminan o mueven ese hook.
• CSS del bloque nativo: el módulo oculta #_desktop_ps_currencyselector. Si solo estás buscando el bloque antiguo, está oculto intencionadamente mientras este módulo está activo.

Si el selector todavía no aparece después de activar varias monedas, inspecciona el código fuente de la página buscando mprcurrency-dropdown. Si ese marcado falta, el hook no se está renderizando o el módulo devolvió salida vacía antes. Si el marcado existe pero no puedes verlo, el problema es CSS del tema o layout de cabecera, no disponibilidad de moneda.

El módulo carga su propio CSS y JavaScript en front office. El JavaScript solo abre y cierra el desplegable; no crea el marcado del selector. Así que un selector ausente casi siempre es modo catálogo, configuración de una sola moneda, falta del hook displayNav2 o estilos del tema ocultando el bloque renderizado.

Inicia sesión en tu cuenta de Intercom en app.intercom.com, abre Ajustes > Instalación > Web y copia el App ID del código de instalación. Pégalo en el campo App ID del módulo y guarda. Mientras no introduzcas un App ID el widget permanece inactivo, de modo que el módulo nunca emite un script roto o vacío en tu tienda.

Sí, cuando lo activas. Si configuras un API Secret de GA4, el módulo puede enviar las compras del lado del servidor mediante el Measurement Protocol como respaldo, de modo que un pedido se registra en GA4 incluso cuando la etiqueta gtag.js del navegador está bloqueada por un bloqueador de anuncios o se pierde en una página fallida. El respaldo solo se ejecuta si lo activas y proporcionas el API Secret.

No. Usa las monedas ya configuradas en PrestaShop y construye enlaces de cambio con SubmitCurrency=1&id_currency=.... No crea monedas, no edita tipos de cambio ni calcula conversiones. La disponibilidad de monedas, tipos y comportamiento de precios siguen gestionados por la configuración de moneda de PrestaShop.

El módulo lee las monedas activas de PrestaShop, encuentra la moneda actual desde el contexto del cliente y renderiza un enlace para cada moneda disponible. Al hacer clic en un enlace, se pide a PrestaShop que cambie la moneda seleccionada por el visitante; después de eso, PrestaShop gestiona conversión de precio, redondeo, visualización de impuestos y formato exactamente como lo haría normalmente.

Usa los propios ajustes de moneda de PrestaShop para cambios operativos: añadir o desactivar monedas, actualizar tipos de cambio, configurar localización y decidir cómo deben mostrarse los precios. Usa este módulo para la presentación del selector en front office: toggle solo con símbolo, código ISO opcional en el toggle, nombres opcionales en el desplegable, estilos conscientes del tema y una huella compacta en cabecera.

Una forma útil de pensarlo es: PrestaShop controla la lógica del dinero; el módulo controla la UI del desplegable. Si falta una moneda en el selector, corrige primero su estado activo/disponible en PrestaShop. Si los valores de conversión son incorrectos, actualiza los tipos de cambio en PrestaShop en lugar de en este módulo.

Sí. Cuando "Pasar datos de usuario" está activado, el módulo envía el correo y el nombre del cliente con sesión iniciada a intercomSettings, de modo que las conversaciones llegan ya identificadas a tu bandeja de Intercom. Los invitados siguen viendo el Messenger, pero de forma anónima: no se envía ningún dato personal de los visitantes sin sesión.

El módulo admite una carga respetuosa con el consentimiento, de modo que el seguimiento tiene en cuenta el estado de consentimiento del visitante, y ofrece un User ID con hash respetuoso con la privacidad en lugar de almacenar identificadores en bruto. El comportamiento del consentimiento depende de las opciones que actives y de la solución de consentimiento externa (por ejemplo, una CMP) que conectes. Sigues siendo responsable de tu propia configuración de privacidad y consentimiento.

Sí. El texto de la diapositiva —título, subtítulo y etiqueta del botón— se almacena por idioma, de modo que cada idioma activo de tu tienda puede mostrar su propia redacción compartiendo el mismo diseño e imágenes. Las traducciones se gestionan directamente en la administración del módulo.

Sí. Puedes elegir si el Messenger se muestra en todas las páginas o solo en algunas, activar o no su aparición en móviles y fijar un retraso en segundos para que el widget cargue un poco después de la página. Así mantienes la tienda rápida y muestras el chat solo donde realmente ayuda a los compradores.

Sí. El módulo incluye exclusión de tráfico por empleado y por dirección IP, de modo que las visitas del personal con sesión iniciada o de las direcciones IP que indiques no se envían a GA4. Así, las pruebas internas y la actividad del back-office quedan fuera de tus informes de analítica.

No. Banner Revolution solo muestra los banners, textos y enlaces de llamada a la acción que configures. No recopila datos personales de los visitantes ni establece cookies de seguimiento, por lo que no tiene impacto propio en el RGPD más allá de las páginas a las que enlaces.

Un panel de diagnóstico en el back-office valida el Measurement ID de GA4 antes de iniciar el seguimiento y comprueba la entrega de eventos, con reintentos para el Measurement Protocol. Un registro de eventos anota los eventos que el módulo ha creado y enviado, de modo que puedes confirmar la llegada de datos a GA4 antes de fiarte de los informes.

El módulo es compatible con PrestaShop de la 1.6 a la 9.x, incluida la 8.x, y funciona con PHP 7.2 y versiones posteriores. Toda la configuración se realiza en el back-office, por lo que no depende de editar las plantillas de tu tema.

No. Nunca edita plantillas ni sobrescribe archivos del tema. Funciona mediante los hooks de presenter de PrestaShop — actionPresentProduct y actionPresentProductListing añaden los datos loading y decoding a los arrays de imágenes que tu tema ya renderiza — y mediante el hook filterHtmlContent para el texto WYSIWYG. Tu tema conserva el control total del marcado; el módulo solo aporta los atributos. Al desinstalarlo, los atributos simplemente dejan de añadirse y nada queda modificado en tu tema.

No. El botón flotante de LINE se añade mediante los hooks de PrestaShop displayBeforeBodyClosingTag y displayHeader, por lo que tus archivos de tema y plantilla nunca se editan ni se sobrescriben. Al desinstalarlo, el botón se retira por completo sin dejar rastro en el tema.

Sí. El módulo no analiza ni reescribe el HTML final renderizado de una página. Enriquece los datos de imagen en la capa del presenter antes de que se ejecute la plantilla y solo procesa determinados campos de contenido WYSIWYG. Como nunca toca la salida de la página, puede funcionar con seguridad junto a la caché de página completa, CCC y CDN — no hay búfer de salida que invalidar, por lo que las páginas en caché siguen siendo válidas.

El widget abre tu enlace de contacto de LINE (https://line.me/ti/p/tu-LINE-ID) en una pestaña nueva para que el visitante inicie una conversación en la app de LINE. No añade ningún mensaje predefinido ni guardado al enlace: simplemente traslada al cliente a LINE.

Sí. Para las imágenes dentro del contenido WYSIWYG, añade la clase CSS de exclusión (por defecto no-autolazy) a la etiqueta img y el módulo la omite. Es la forma recomendada de que tu imagen principal visible al cargar se cargue de inmediato, porque aplicar carga diferida a la imagen visible más grande puede perjudicar el Largest Contentful Paint. Las imágenes data-URI en línea y las que ya tienen un atributo loading también se omiten automáticamente.

Sí. La segmentación por páginas permite mostrar el botón en todas las páginas o limitarlo a algunas, y un interruptor móvil independiente permite ocultarlo en los teléfonos. Una opción de retardo de carga también puede contener el botón un momento para que no compita con la página mientras se carga.

Es una sugerencia para el navegador que permite decodificar una imagen fuera del hilo principal, de modo que decodificar una imagen grande tenga menos probabilidades de bloquear el desplazamiento o la interacción. Complementa a loading="lazy". El módulo lo añade por defecto pero ofrece un único control para desactivarlo si lo prefieres, dejando solo loading="lazy". Los atributos decoding existentes nunca se sobrescriben.

Las imágenes de producto en la página de producto, las imágenes de producto en los listados de categoría y búsqueda, y las imágenes incrustadas en el contenido WYSIWYG como las descripciones de producto, categoría, páginas CMS y fabricante. Las dos primeras se gestionan mediante los hooks de presenter de producto; la última mediante el hook del filtro de contenido. Es una ayuda específica a la velocidad — no comprime, redimensiona ni convierte imágenes, solo añade los atributos loading y decoding.

El toggle cerrado del header siempre muestra el símbolo o signo de la moneda actual, como $, €, £ o el código ISO como fallback. Si Show ISO label in toggle está activado, el toggle también muestra el código ISO actual junto al símbolo. El dropdown abierto siempre lista cada moneda con su símbolo/signo, y si Show currency names in dropdown está activado también muestra el nombre completo de la moneda junto a cada símbolo.

El toggle no renderiza un tooltip al pasar el cursor. Los nombres de moneda se usan en las filas del dropdown, incluido el atributo title del enlace para cada opción de moneda.

Sí. El módulo registra su propio selector en el hook displayNav2 y carga una hoja de estilos que oculta el selector de moneda desktop nativo de PrestaShop con #_desktop_ps_currencyselector { display: none !important; }. El cliente ve el dropdown compacto de símbolos del módulo en lugar del bloque de moneda predeterminado.

Activa el módulo, pega tu ActiveCampaign Account ID y guarda la configuración. El Account ID es el valor numérico que ActiveCampaign muestra en Settings > Tracking > Site Tracking; se almacena como ACCOUNT_ID, y el módulo no renderizará el script del storefront hasta que tanto ENABLED como ACCOUNT_ID estén presentes.

• En PrestaShop, abre la configuración del módulo ActiveCampaign.
• Activa Enable ActiveCampaign.
• Pega el Account ID numérico, por ejemplo 123456789.
• Visita una página del storefront y confirma que el código fuente contiene el script diffuser de ActiveCampaign.

Cuando está activo, el hook displayBeforeBodyClosingTag carga el script diffuser de ActiveCampaign, ejecuta vgo('setAccount', ...), activa el tracking predeterminado y llama a vgo('process'). Para clientes con sesión iniciada también puede pasar el email del cliente con vgo('setEmail', ...).

El script se inserta justo antes de la etiqueta de cierre body, no en el head de la página. Eso es útil al comprobar la instalación: busca en el código fuente renderizado cerca del final diffuser-cdn.app-us1.com/diffuser/diffuser.js, vgo('setAccount' y tu account ID. Si faltan, el módulo está desactivado, el Account ID está vacío o el tema no ejecuta el hook displayBeforeBodyClosingTag.

La configuración también tiene un campo opcional EVENT_KEY, pero el hook actual de storefront es solo site tracking. No envía llamadas personalizadas de event tracking de ActiveCampaign desde esta ruta de código del módulo. Úsalo para añadir el snippet oficial de site tracking e identificar clientes con sesión iniciada por email; construye automatización de eventos personalizada por separado si necesitas tracking de eventos más profundo en ActiveCampaign.

Por privacidad, recuerda que esto es un script de tracking. Combínalo con tu configuración de consentimiento si tu tienda requiere consentimiento de marketing o analítica antes de cargar tracking de terceros, porque este módulo no implementa por sí mismo una puerta de consentimiento de cookies.

Sí, los clientes de PrestaShop con sesión iniciada se identifican por email en el script de tracking de ActiveCampaign. El módulo lee el cliente actual desde el contexto de PrestaShop y envía el email solo cuando el cliente ha iniciado sesión; los visitantes anónimos se rastrean sin valor de email.

La comprobación ocurre en el hook de cierre de body del storefront. El tracking se renderiza solo cuando el módulo está activado y existe un ActiveCampaign Account ID. El hook asigna entonces tres valores de plantilla: el account ID, el email del cliente y un booleano que indica si se encontró email.

En la plantilla, vgo('setEmail', ...) está envuelto en una comprobación de sesión iniciada, así que los invitados no reciben una llamada de email vacía. Cada página rastreada sigue definiendo la cuenta, activa el tracking de página predeterminado y llama a vgo('process'). Eso significa que ActiveCampaign puede conectar visitas de página conocidas al email del cliente con sesión iniciada, mientras las visitas de invitados permanecen anónimas hasta que ActiveCampaign pueda identificarlas por otra ruta.

Logged in customer -> setAccount + setTrackByDefault + setEmail + process
Guest visitor -> setAccount + setTrackByDefault + process

El ajuste obligatorio es el ActiveCampaign Account ID, además de que el módulo debe estar activado. El código comprueba ambos antes de renderizar el script del storefront de PrestaShop; el campo Event Key se guarda en configuración, pero la plantilla de tracking actual no lo usa.

Al instalar, ENABLED queda por defecto en 0, ACCOUNT_ID queda por defecto como cadena vacía y EVENT_KEY también como cadena vacía. El aviso de configuración obligatoria solo declara ACCOUNT_ID como requerido, y la comprobación de activación es simplemente activado más account ID no vacío.

La opción admin etiqueta el Account ID como el ID numérico del site tracking de ActiveCampaign, pero este código fuente no aplica un validador numérico antes de renderizar. Para una configuración limpia, copia el account ID exactamente desde los ajustes de site tracking de ActiveCampaign, activa el módulo y luego comprueba el código fuente de la página buscando el script diffuser.js y vgo('setAccount', ...).

ENABLED = 1
ACCOUNT_ID = 123456789
EVENT_KEY = optional, stored but not rendered by tracking.tpl

No, este módulo no envía eventos de producto, carrito, pedido ni eventos ecommerce personalizados de ActiveCampaign. Su código PrestaShop solo carga site tracking, define la cuenta, opcionalmente identifica por email a un cliente con sesión iniciada y llama a la función de procesamiento de página de ActiveCampaign.

El ajuste guardado EVENT_KEY se describe como opcional para eventos personalizados, pero la plantilla de storefront nunca lo referencia. No hay llamadas de eventos de compra, carrito, producto o checkout en la plantilla de tracking; las únicas llamadas ActiveCampaign son setAccount, setTrackByDefault, setEmail opcional y process.

Para comerciantes, el resultado práctico es tracking de visitas de página en lugar de tracking ecommerce. Puedes usarlo para que ActiveCampaign vea páginas visitadas rastreadas e identifique clientes con sesión iniciada por email, pero este módulo no envía valor de pedido, IDs de producto, contenido de carrito ni líneas de artículo. Si eso es necesario, requeriría otra integración o nuevo código que realmente se enganche a eventos de producto, carrito y pedido.

Los módulos de PrestaShop necesitan cada uno tareas programadas (feeds, limpiezas, sincronizaciones), pero conectar una línea de cron de servidor separada para cada uno es frágil. Un gestor de cron te da un único endpoint protegido por token que las ejecuta todas. Con Cron Manager, PrestaShop expone una URL como /module/mprcron/cron?token=… (más un punto de entrada cron.php para llamadas CLI o HTTP con opciones de máximo de tareas y contexto) que ejecuta cada tarea registrada por turno. Apunta un solo cron de servidor, o un servicio externo como cron-job.org, a esa URL en el intervalo que elijas, y gestiona programaciones individuales, estado activado/desactivado e historial de ejecuciones desde el back office en lugar de editar crontab. Mantén el token en secreto para que terceros no puedan dispararlo, y empieza con un intervalo de 5-15 minutos según lo sensibles al tiempo que sean tus tareas. El logging centralizado también facilita detectar una tarea fallida.

El comando CLI generado es una línea crontab de una sola línea usando el token compartido, por ejemplo * * * * * php /path/to/modules/mprcron/cron.php --token=TOKEN --max-seconds=300. El punto de entrada requiere token, limita max_tasks entre 1 y 100, limita max_seconds entre 10 y 300, y usa por defecto 20 tareas y 300 segundos. El token compartido se genera como un valor hexadecimal de 64 caracteres y se valida con hash_equals.

Internamente, el paquete compartido posee dos tablas: mpr_cron_task para tareas registradas y mpr_cron_log para historial de ejecución. Cada tarea guarda módulo, clave de tarea, etiqueta, callable o payload, tipo de executor, programación, estado activado, próxima ejecución, contexto, prioridad y timeout. El runner reclama una tarea antes de ejecutarla, registra estados completed, failed, skipped, timeout o crashed, y escribe una fila de log. En modo CLI, cuando el cron.php local soporta tareas aisladas y proc_open está disponible, cada tarea puede ejecutarse en un subproceso para que una tarea fatal no detenga el resto del lote.

Una buena sección FAQ responde preguntas de compradores antes de que escriban y captura tráfico de búsqueda long-tail. Para añadir una a PrestaShop, usa FAQ Manager: crea un hub FAQ público con rutas de categoría, etiqueta, búsqueda y pregunta, muestra una pestaña FAQ de producto mediante displayProductExtraContent y puede mostrar contenido FAQ contextual de categoría como bloque de columna izquierda/sidebar mediante displayLeftColumn. Guardas preguntas, categorías, etiquetas y asignaciones de producto o categoría, así que la misma respuesta puede aparecer en el hub y en cada producto relacionado. Los clientes pueden enviar sus propias preguntas para moderación, y las respuestas comunitarias aprobadas con votos útiles añaden contenido fresco. Para SEO, da a cada pregunta indexable un título y meta description únicos, mantén respuestas realmente útiles en lugar de una línea, y usa FAQ schema solo donde sea preciso y siga siendo útil para tu objetivo de búsqueda/visualización.

En la configuración práctica, empieza en el menú de administración FAQ: crea categorías FAQ y luego añade preguntas con texto de pregunta multilingüe, HTML de respuesta, URL amigable, meta title y meta description. Si la URL amigable se deja vacía, las categorías generan un slug desde el nombre de categoría y las preguntas generan un slug desde el texto de la pregunta. Una pregunta pública es visible solo cuando está activa, su fecha de publicación está vacía o ya ha pasado, y el grupo de clientes actual está permitido. También puedes definir una Answer Reveal Date, que permite que la pregunta exista antes de mostrar la respuesta.

• Usa Categories para hubs FAQ públicos y para mapear categorías FAQ a categorías de PrestaShop donde sean útiles los bloques de contexto en página de categoría.
• Usa Questions para las entradas FAQ reales; asigna productos directamente cuando una pregunta deba aparecer en una pestaña FAQ de producto.
• Usa Tags para mejorar la búsqueda FAQ, páginas de etiqueta y descubrimiento interno.
• Usa Pending Questions y Additional Replies para moderar envíos de visitantes antes de que se vuelvan públicos.

Para páginas de producto, no dependas de mapeos amplios de categoría cuando necesitas una FAQ exacta de producto. La pestaña de producto carga preguntas desde la tabla de asignación directa producto-pregunta y no devuelve nada si no hay pregunta asignada a ese producto. Las preguntas asignadas exactamente a un producto pueden renderizar una respuesta en el HTML inicial de página de producto; las preguntas compartidas entre varios productos se tratan como relacionadas/compartidas y sus respuestas se cargan de forma diferida al abrirse. Esto evita inyectar grandes artículos de troubleshooting en cada página de producto y ayuda a evitar contenido duplicado ruidoso.

Las páginas de categoría no se renderizan como pestaña por este módulo. La integración de categoría es un bloque de columna izquierda/sidebar que carga un conjunto limitado de preguntas para la categoría actual y las enlaza con la experiencia FAQ.

Los controles SEO son deliberadamente granulares. La indexación del hub FAQ está activada por defecto, pero las páginas de categoría, páginas de etiqueta y páginas individuales de pregunta no se indexan salvo que el interruptor global correspondiente esté activado y, para categorías o preguntas, la entidad esté marcada como indexable. Las páginas de búsqueda siempre son noindex. Los campos meta title y meta description recurren al título visible, descripción de categoría o extracto de respuesta cuando se dejan vacíos, y las URLs canonical se construyen desde el slug FAQ localizado, slug de categoría y slug de pregunta.

Schema es un interruptor, no magia automática. El ajuste es SCHEMA_ENABLED y usa por defecto 0; la pista de administración dice que Google deprecó los rich results FAQ en mayo de 2026, así que trátalo como datos estructurados opcionales en lugar de un disparador garantizado de rich results. El manejo de respuestas programadas no es consistente en todas las rutas de schema del código actual: los builders JSON-LD de pregunta y categoría del front comprueban answer_visible, pero la salida QAPage de cabecera a nivel de módulo lee questionData['answer'] directamente, y la ruta de consulta/construcción de schema del hub FAQ no comprueba date_response ni answer_visible. Si usas respuestas retrasadas, mantén schema desactivado o corrige esas rutas antes de confiar en schema para ocultar contenido de respuestas futuras.

El flujo de envíos de visitantes está moderado. Ask a Question está activado por defecto, valida nombre, email y texto de pregunta, limita el texto de pregunta a 5000 caracteres, usa un campo honeypot y guarda el elemento en mprfaq_pending con estado pending. El límite de frecuencia predeterminado es ASK_MAX_PENDING=2 preguntas pendientes por email y categoría de producto de nivel superior; establécelo en 0 solo si quieres deliberadamente no tener límite de preguntas pendientes. Si el visitante pregunta desde una página de producto y no se proporciona categoría FAQ, el controlador resuelve una categoría desde el contexto del producto.

Las respuestas públicas son independientes de la respuesta oficial. CA_ENABLED usa por defecto 0; cuando está activado, el módulo puede requerir login, valida detalles del autor, limita el texto de respuesta a 5000 caracteres y guarda la respuesta como pending. Las respuestas adicionales aprobadas pueden aparecer como respuestas comunitarias y pueden votarse. Los votos útiles se limitan a un voto por IP por pregunta o respuesta, con una cookie de PrestaShop usada solo para recordar el estado de interfaz del visitante.

FAQ_SLUG=faq
FAQ_HUB_INDEXABLE=1
FAQ_CATEGORY_INDEXABLE=0
FAQ_TAG_INDEXABLE=0
QUESTION_INDEXABLE=0
SCHEMA_ENABLED=0
ASK_ENABLED=1
ASK_MAX_PENDING=2
CA_ENABLED=0

Para una FAQ SEO, la regla práctica es mantener el hub amplio, hacer indexables solo páginas sólidas independientes de categoría o pregunta, asignar preguntas de producto directamente y dejar respuestas pequeñas específicas de producto en la pestaña de producto. Así das respuestas a los clientes donde las necesitan mientras mantienes el índice centrado en páginas que pueden sostenerse por sí solas.

Sí, puedes bloquear por IP, rango CIDR, código de país o patrón user-agent, incluido ámbito solo checkout. El gestor de bloqueos de PrestaShop comprueba primero las entradas de whitelist, luego las reglas de bloqueo activas, y aplica ámbito completo, checkout o autenticación según el contexto de la solicitud actual.

El formulario de bloqueo soporta una IP única, IP con comodín como 192.168.1.*, rango IP como 1.1.1.1-1.1.1.255, CIDR como 192.168.1.0/24, un código ISO de país y un patrón user-agent. Las reglas user-agent pueden ser texto plano con coincidencia case-insensitive, o una regex encerrada entre barras.

El ámbito se basa en el controlador actual. El ámbito checkout se aplica a order, orderopc, cart, supercheckout, onepagecheckout y checkout. El ámbito login/auth se aplica a authentication, my-account, identity, registration y password. Los bloqueos completos se comprueban antes que los bloqueos por ámbito, así que un bloqueo completo bloquea al visitante en todas partes.

• Activación: BAN_ENABLED se instala activado por defecto.
• Bloqueos temporales: un bloqueo puede tener date_expiry; los bloqueos activos caducados se desactivan durante la carga de bloqueos activos.
• Mensaje: cada bloqueo puede tener su propio mensaje; si no, el módulo recurre al mensaje predeterminado multilingüe configurado.
• Multitienda: los registros de bloqueo con id_shop=0 se aplican globalmente, mientras que los bloqueos específicos de tienda solo se aplican en el contexto de la tienda actual.

Checkout-only CIDR example:
ip_cidr = 203.0.113.0/24
ban_type = checkout
reason = Repeated fraudulent checkout attempts

Con el tiempo, una base de datos PrestaShop se llena de datos que ya no necesitas: carritos abandonados, filas huérfanas de carrito, precios específicos y reglas de carrito caducadas, registros antiguos de conexiones e invitados, estadísticas de búsqueda, logs de correo y 404, vistas de página e hilos de cliente cerrados. Si no se controlan, esas tablas ralentizan las consultas y agrandan las copias de seguridad. Para limpiarlas de forma segura, usa Cleanup Revolution: agrupa cada limpieza en tareas con nombre, cuenta las filas afectadas antes de eliminar, soporta vistas previas dry-run por defecto y registra ejecuciones reales de eliminación en el historial de limpieza. Empieza con carritos abandonados de más de 30 días y estadísticas antiguas de búsqueda/conexión, revisa los recuentos de la vista previa y luego elimina por lotes. Haz siempre una copia de seguridad de la base de datos primero. Para mantenimiento continuo, programa las tareas en lugar de ejecutarlas a mano; consulta nuestra guía de rendimiento de PrestaShop.

Before any real cleanup, make a fresh database backup and run the module preview first. Do not delete rows manually with SQL; use Cleanup Revolution's dry-run counts, review the affected tasks, then run the cleanup from the module in controlled batches.

mysqldump -u db_user -p db_name > prestashop-before-cleanup.sql

La configuración predeterminada es deliberadamente conservadora: dry run está activado por defecto, modo papelera está activado, los carritos abandonados usan 30 días por defecto, muchos logs/estadísticas usan 90 días, los hilos de cliente cerrados usan 180 días, las cuentas vacías usan 365 días, y el motor usa tamaños de lote por tarea más un límite total de 50000. Una tarea sin filas que eliminar se omite en el runner masivo, y la eliminación real ocurre por lotes en lugar de como una sola sentencia enorme.

Hay un detalle de log de auditoría importante: las ejecuciones dry-run devuelven el recuento afectado antes de llamar a MPRCleanupLog::record(), así que las vistas previas dry-run no se escriben en el historial de limpieza. Las limpiezas reales de base de datos se registran con dry_run = 0. Las acciones manuales del Back Office llaman a DatabaseCleanupEngine::executeTask(..., $employeeID) o a DatabaseCleanupEngine::executeAll($dryRun, $employeeID), por lo que usan el valor predeterminado trigger_type = manual y registran el ID del empleado cuando está disponible. La limpieza programada de la base de datos llama a MPRCleanupRevolution::cronDBCleanup(), que pasa DatabaseCleanupEngine::executeAll(false, null, 'cron'); por tanto, esas filas del registro guardan trigger_type = cron sin ID de empleado.

El motor de limpieza de base de datos incluye tareas con nombre para carritos abandonados, productos huérfanos de carrito, estadísticas de búsqueda, precios específicos caducados, reglas de carrito caducadas con cantidad cero, logs antiguos, conexiones antiguas, filas huérfanas de conexión, invitados antiguos, logs de correo, logs 404, vistas de página, hilos de cliente cerrados y caché de referentes. También tiene limpiezas comerciales de mayor riesgo como cuentas de invitado sin pedidos, direcciones huérfanas y cuentas registradas antiguas sin pedidos ni carritos recientes. Los valores predeterminados de cron dividen el trabajo en ventanas de limpieza de base de datos, limpieza de archivos y optimización de tablas, para que puedas automatizar el mantenimiento sin ejecutar todas las operaciones pesadas a la vez.

Si solo necesitas un aviso de cookies claro de aceptar o rechazar, un banner ligero es la implementación más sencilla. Lightweight Cookie Banner renderiza el banner desde hooks de nivel footer, guarda la elección del visitante en una cookie de consentimiento y te permite configurar texto del banner, botones, colores, posición, enlace a la política de privacidad y cuánto dura el consentimiento antes de volver a preguntar (365 días por defecto). Es intencionadamente mínimo, sin scripts pesados, así que no ralentizará tu tienda. Úsalo cuando tu huella de tracking sea pequeña y necesites principalmente informar a visitantes y registrar su elección. Si también necesitas bloquear scripts hasta el consentimiento, registrar logs de consentimiento u ofrecer preferencias granulares por categoría, una plataforma completa de consentimiento encaja mejor. Acompaña siempre el banner con una política de cookies y privacidad precisa y actualizada.

El módulo usa por defecto activado, posición bottom-left, botones lado a lado, tema oscuro, COOKIE_EXPIRY de 365 días, Google Consent Mode activado y DEFAULT_CONSENT establecido en denied. Puede renderizarse como barra superior o inferior de ancho completo, banner de esquina, banner flotante inferior o modal centrado con overlay. La elección del visitante se guarda en la cookie first-party mprcookie_consent con granted o denied; JavaScript la escribe con path=/, SameSite=Lax y Secure cuando la tienda está en HTTPS.

Cuando Google Consent Mode está activado, el hook de cabecera inyecta la señal de consentimiento predeterminada y carga assets/config seguros para head; no renderiza el marcado visible del banner. El marcado del banner se renderiza desde displayFooterAfter o displayFooter, protegido para que se genere solo una vez, y el script del front envía una actualización de consentimiento después de que el visitante acepta o rechaza. El módulo no categoriza cookies, no reescribe scripts de terceros ni mantiene una tabla de logs de consentimiento. También advierte cuando Cookies Revolution está disponible porque solo un módulo de consentimiento de cookies debería controlar el escaparate a la vez.

Para cumplimiento completo de GDPR y ePrivacy necesitas más que un banner: los compradores deben poder aceptar o rechazar cookies por finalidad. Cookies Revolution añade consentimiento granular a PrestaShop con las categorías estándar — necessary, functional, analytics y marketing — y un panel de preferencias donde los visitantes pueden aceptar todo, rechazar categorías opcionales o guardar una selección personalizada; su elección se guarda en una cookie de consentimiento. También puede bloquear scripts de seguimiento coincidentes hasta que se conceda el consentimiento, reescribiendo etiquetas para que solo se ejecuten para categorías permitidas, y registrar consentimientos con identificadores hasheados para tu pista de auditoría. El consentimiento previo (sin casillas opcionales premarcadas) y retirar el consentimiento con la misma facilidad que concederlo son requisitos legales; esto cubre ambos. Combínalo con Google Consent Mode v2 para que tus etiquetas de Google se ajusten automáticamente a la elección de cada comprador.

Al instalar, el módulo crea tablas de categorías, cookies, reglas de script, log de consentimiento, resultados de escaneo y diseño. Las categorías iniciales son necessary, functional, analytics y marketing; necessary es obligatoria y está activada por defecto, mientras que las categorías opcionales están desactivadas por defecto salvo que cambies el modo de consentimiento predeterminado. El estado del navegador guardado es compacto, por ejemplo necessary:1|functional:0|analytics:0|marketing:0 en mprcr_consent, con una cookie separada mprcr_version usada cuando RECONSENT_ON_CHANGE está activado.

El bloqueo de scripts funciona en dos capas. En la salida del servidor, el módulo reescribe scripts externos coincidentes a type="text/plain" con data-cookiecategory y guarda la fuente original en data-original-src; también puede reescribir scripts inline coincidentes basados en reglas de contenido de script. En el navegador, un MutationObserver comprueba scripts inyectados dinámicamente contra la misma lista de reglas y los bloquea si la categoría coincidente no está concedida. Cuando se guarda el consentimiento, el módulo actualiza Google Consent Mode, activa scripts permitidos, elimina cookies de categorías revocadas cuando está configurado, dispara mprcr:consent y registra la decisión por AJAX cuando el logging está activado, con una pequeña limitación para evitar spam de logs duplicados.

Sí, puede crear o sincronizar un trabajo de cron-job.org cuando está configurado. La configuración admin de PrestaShop puede probar la clave API de cron-job.org, comprobar alcance externo y apuntar el trabajo remoto a la URL cron tokenizada de estado o ejecución del módulo.

Usa el espacio de limpieza para eliminar los registros antiguos compatibles de PrestaShop. El módulo cuenta y borra carritos de más de 30 días sin pedidos, estadísticas de búsqueda, precios específicos caducados, logs, conexiones, invitados huérfanos y registros mail.

El módulo gestiona registros de catálogo digital para módulos, temas y addons. En PrestaShop cada producto digital puede guardar nombre técnico, rama, versión actual, campos de compatibilidad, URL de documentación, demo y repositorio, changelog, meses de soporte y límites de dominio.

Los compradores convierten mejor cuando pueden ver cuándo llegará un pedido. Para mostrar una fecha estimada de entrega en PrestaShop, usa Estimated Delivery Date: añade tus días de procesamiento configurados a la fecha actual y muestra el resultado en la página de producto mediante el bloque displayProductAdditionalInfo. Puedes definir una hora de corte diaria (los pedidos realizados después cuentan desde el día siguiente), excluir fines de semana para que sábados y domingos no cuenten y que un resultado final en fin de semana avance al lunes, y elegir el formato de fecha que ven los compradores. El mensaje aparece automáticamente en páginas de producto elegibles, dando una expectativa concreta de llegada en lugar de un vago envío pronto. Mantén honesto tu tiempo de procesamiento y alinea el corte con tu horario real de despacho, para que la fecha prometida coincida con lo que reciben los clientes; las estimaciones precisas reducen tickets de dónde está mi pedido.

Los valores predeterminados de instalación son ENABLED=1, PROCESSING_DAYS=1, CUTOFF_HOUR=14, EXCLUDE_WEEKENDS=1 y DATE_FORMAT=l, F j. El cálculo usa el DateTime actual del servidor, lee la hora actual como valor entero de 24 horas y añade un día extra de procesamiento cuando la hora actual es mayor o igual que la hora de corte. Luego avanza un día cada vez hasta contar el número configurado de días de procesamiento, saltando sábado y domingo cuando la exclusión de fin de semana está activada.

El mensaje del escaparate también recibe hours_left, que es simplemente la diferencia de horas enteras hasta el corte cuando el pedido sigue antes del corte. Este módulo no inspecciona rangos de entrega de transportistas, estado de stock, calendarios de almacén, festivos, código postal de destino ni plazos específicos por producto. Es una promesa simple de página de producto basada en reglas de procesamiento de toda la tienda, así que funciona mejor cuando tu catálogo comparte el mismo patrón de despacho.

El Meta (Facebook) Pixel rastrea acciones de compradores para que puedas medir el rendimiento de anuncios y crear audiencias de retargeting. PrestaShop no tiene Pixel nativo, así que lo añades con un módulo de seguimiento. Con Facebook Pixel, introduce tu Pixel ID y activa el seguimiento del navegador; el módulo dispara entonces los eventos ecommerce estándar — PageView, ViewContent, AddToCart, InitiateCheckout, Search, AddToWishlist, CompleteRegistration y Purchase — con interruptores individuales para activar o desactivar eventos concretos. Para conversiones precisas pese a pérdidas por navegador y bloqueadores de anuncios, activa también la Conversions API del lado del servidor, que envía eventos Purchase a Meta con un event ID coincidente para que los impactos de navegador y servidor se dedupliquen. Verifica todo en la herramienta de prueba de Events Manager de Meta antes de lanzar campañas, y asegúrate de que el disparo del Pixel respete tu banner de consentimiento de cookies para que el seguimiento solo se ejecute después de conceder consentimiento de marketing.

El módulo se instala con ENABLED desactivado y PIXEL_ID vacío, así que no empieza ningún seguimiento de navegador hasta que lo configures. Los Pixel IDs se validan como solo dígitos. La mayoría de interruptores de eventos estándar están activados por defecto una vez que el propio módulo se activa, mientras que CAPI_ENABLED está desactivado por defecto y requiere Pixel ID más CAPI_ACCESS_TOKEN. La versión predeterminada de Graph API en el módulo es v25.0, y puede enviarse un código opcional de evento de prueba mientras validas en Meta Events Manager.

El consentimiento se comprueba antes de renderizar la plantilla de seguimiento. Si Cookies Revolution está activo, el módulo lee el valor marketing desde mprcr_consent; si Lightweight Cookie Banner está activo, lee mprcookie_consent; si ninguno está activo y el respeto al consentimiento está activado, el módulo trata el consentimiento de marketing como disponible. La navegación de empleados también puede excluirse. AddToCart se rastrea mediante el evento updateCart de PrestaShop cuando está disponible, con fallbacks de clic para temas antiguos. Purchase se emite en la confirmación de pedido con un event id determinístico de pedido, y cuando CAPI está configurado la misma compra se encola y procesa mediante la cola de conversiones compartida, incluida una tarea cron programada cada 300 segundos para reintento/procesamiento.

Sí, MPR FAQ puede recoger preguntas de clientes para revisión. En PrestaShop los registros pendientes guardan nombre, email, pregunta, producto o categoría FAQ, estado, posible respuesta de administración y fechas antes de publicarse.

El renderizado en el storefront se gestiona mediante el hook displayMprSubtitle. El resolver puede detectar la página actual de producto, categoría, CMS, fabricante o proveedor, y las plantillas también pueden pasar un ID de producto explicito cuando haga falta.

Sí, las IPs en whitelist se comprueban antes que los bloqueos y nunca son bloqueadas por el matcher de bloqueos. El módulo de PrestaShop soporta entradas de whitelist por IP exacta o rango CIDR, con filtrado consciente de tienda para que los registros de whitelist específicos de tienda se apliquen solo en el contexto correspondiente.

La whitelist se basa en IP, no en país ni user-agent. En el formulario admin, introduces un campo de dirección IP o un rango CIDR, no ambos. El campo de dirección IP está documentado para una única IP o comodín como 192.168.1.*; el campo CIDR espera notación como 192.168.1.0/24.

Cuando se comprueba una solicitud, isBanned() llama primero a isWhitelisted(). Si la IP del visitante coincide con una fila de whitelist, la función devuelve false de inmediato y no se aplica ningún bloqueo por país, user-agent, IP exacta o CIDR. Esto es útil para IPs de oficina, desarrolladores, proveedores de pago o monitorización que no deben quedar bloqueadas por reglas amplias de país o rango.

• Almacenamiento: las filas de whitelist almacenan dirección IP, CIDR, etiqueta, ID de empleado, ID de tienda y fecha de creación.
• Gestión de tienda: cuando multishop está activo, la consulta de whitelist carga filas de la tienda actual y filas globales id_shop=0.
• Gotcha: una whitelist solo ayuda cuando el módulo detecta la misma IP real de visitante que guardaste. Si un proxy o CDN cambia la IP que ve PrestaShop, pon en whitelist la dirección que PrestaShop realmente recibe.

PrestaShop no tiene blog integrado, así que para publicar artículos, guías y contenido SEO añades un módulo de blog. Blog Revolution crea un blog completo dentro de tu tienda: registra rutas dedicadas para el índice del blog, posts individuales, categorías, etiquetas, autores, archivos mensuales, búsqueda y feed RSS, y añade bloques para la página de inicio, columnas laterales, footer, páginas de producto y listados tipo categoría para que tus últimos posts aparezcan en toda la tienda. Como el blog comparte tu tema, diseño y configuración de idiomas, los artículos heredan automáticamente tu branding y URLs multilingües. Un blog es una de las inversiones SEO más eficaces en PrestaShop: apunta a consultas informativas que tus páginas de producto y categoría no pueden cubrir, construye enlaces internos hacia esas páginas y consigue backlinks. Planifica primero una estructura de categorías, luego publica de forma constante y enlaza cada post con los productos relevantes.

En código, esto no es solo un wrapper de página CMS. El módulo crea sus propias tablas para posts, traducciones de posts, categorías, etiquetas, autores, comentarios, enlaces post-producto, seguimiento de vistas/likes, imágenes, restricciones de grupo y redirecciones de slugs. Los posts tienen campos SEO como meta title, meta description, meta keywords y canonical URL por idioma, y el módulo puede generar datos Open Graph, autodiscovery RSS, enlaces hreflang y enlaces de paginación anterior/siguiente desde el hook de cabecera.

El prefijo de URL predeterminado es blog, así que el conjunto de rutas generado incluye rutas como /blog, /blog/tag/{rewrite}, /blog/author/{slug}, /blog/archive/{year}/{month}, /blog/search y /blog/rss. Los valores predeterminados también asumen 12 posts por página, cuadrícula de tres columnas, comentarios, valoraciones, extractos, metadatos de autor/fecha/vistas/comentarios, compartir en redes, schema, hreflang, Open Graph y RSS activados. Eso te da una superficie de publicación completa, pero aun así deberías definir reglas editoriales: qué posts enlazan a productos, qué categorías se asignan a términos comerciales y qué URLs antiguas deberían redirigir en lugar de devolver 404.

Las etiquetas canonical indican a Google qué versión de una página es la original, evitando problemas de contenido duplicado por filtros, paginación y productos casi idénticos. PrestaShop define canonicals automáticamente, pero no te da forma de sobrescribirlas por página. Para definir una canonical personalizada para un producto, categoría, página CMS, fabricante o proveedor concreto, usa Product Canonical Manager: crea una regla para la entidad objetivo, introduce la URL a la que quieres que los buscadores atribuyan la página y guarda un valor distinto por idioma de tienda cuando haga falta. Úsalo cuando varios productos sean variantes de un maestro, cuando una página CMS replique un artículo del blog o cuando una URL de campaña deba consolidarse en la página limpia del producto. Para entender cómo encajan canonicals, URLs, schema y sitemaps, consulta nuestra guía SEO de PrestaShop.

El módulo guarda reglas en una tabla dedicada mprcanonical_rule y soporta los tipos de entidad product, category, cms, manufacturer y supplier. Cada regla tiene una acción: override sustituye una canonical existente por la URL de la entidad, add_missing solo inserta una cuando la página todavía no tiene canonical, y custom usa la URL personalizada multilingüe guardada en la regla. Las reglas también pueden establecer noindex y nofollow.

Para reglas de producto, el resolvedor puede coincidir con un producto concreto, todos los productos, productos por categoría, fabricante o proveedor, y soporta exclusiones de selector. Cuando varias reglas coinciden, la consulta ordena por priority DESC, así que la regla de mayor prioridad gana para la URL canonical, mientras que las banderas noindex/nofollow pueden acumularse. El hook de salida edita el head HTML terminado, por lo que puede sustituir etiquetas canonical existentes, añadir directivas robots, añadir enlaces hreflang cuando está activado y normalizar URLs generadas con eliminación de parámetros configurada, conversión a minúsculas y manejo opcional de slash final.

Sí, el modo dry-run muestra los resultados antes de borrar. El módulo lo activa por defecto, usa tamaños de lote por tarea y límites de seguridad configurables, y registra historial con tipo de disparador, filas afectadas, estado dry-run y empleado.

Sí, soporta Google Consent Mode v2 cuando está activado. El módulo escribe un comando de consentimiento predeterminado antes de las etiquetas y actualiza ad_storage, ad_user_data, ad_personalization y analytics_storage después de que el comprador acepte o rechace cookies en PrestaShop.

Sí, puede bloquear scripts coincidentes hasta que se conceda consentimiento. Con el bloqueo activado, el hook de salida reescribe las etiquetas script como type text/plain con metadatos de categoría, y el JavaScript front restaura solo los scripts cuya categoría está permitida.

Sí, el módulo ofrece un espacio back office de tareas programadas. Puede listar tareas de módulos que usan CronTrait compartido, ejecutar pruebas, activar o desactivar tareas, editar calendarios, eliminar tareas personalizadas, revisar logs y aplicar cambios masivos de frecuencia.

Sí, el espacio admin muestra conteos antes de ejecutar la limpieza. En PrestaShop cada tarea incluye una consulta de conteo y la plantilla muestra el total y los conteos individuales para ejecutar una tarea o todas.

Depende de a qué descarga se refiera:

• Un módulo con licencia — sí. Las descargas con licencia están vinculadas a su tienda, así que el controlador de descargas comprueba la propiedad de la licencia, su validez, los límites de descarga restantes y que la tienda seleccionada esté asignada a la licencia antes de emitir una URL de descarga tokenizada. Esa vinculación es lo que mantiene una licencia de pago unida a su tienda.
• La demo gratuita de 30 días — no. Indicar su email y el dominio de instalación al descargar es opcional. Lo único que le aporta es comodidad más adelante: si compra con ese mismo email, su tienda podrá ofrecerle la activación en un clic. Si lo omite, simplemente pegará una clave de licencia.

Para todo el recorrido desde la prueba hasta la activación y el soporte, vea Cómo funcionan las licencias, la activación y el soporte.

Las ventas flash, promociones estacionales y ofertas por tiempo limitado funcionan mejor cuando empiezan y terminan automáticamente. Para programar descuentos basados en tiempo en PrestaShop, usa Smart Dynamic & Scheduled Discounts: crea campañas con fechas de inicio y fin, y el hook de precio comprueba la ventana activa, alcance de producto, acceso por grupo de clientes y límites de uso, luego aplica el mejor descuento elegible al precio del producto sin trabajo manual. Como el descuento se calcula en tiempo de visualización y checkout, los precios vuelven automáticamente cuando se cierra la ventana, sin tener que recordar deshacer una promoción. Usa alcance por grupo de clientes para ofertas solo de miembros y apóyate en la lógica de mejor precio para que campañas solapadas sean predecibles. Muestra siempre el precio original junto a la oferta para que el ahorro sea visible y comprueba que los precios programados respeten cualquier regla de margen mínimo que tengas.

El modelo de campaña soporta tipos de campaña como scheduled, recurring, flash sale, countdown, early bird y last chance, con tipos de descuento percent, amount y fixed_price. El alcance de producto puede ser asignación directa de producto/combinación, categorías con subcategorías opcionales, fabricantes, grupos de clientes o ningún alcance, en cuyo caso una campaña activa puede aplicarse a todos los productos. Los descuentos personalizados por producto pueden sobrescribir el descuento de campaña cuando la fila de producto no hereda el valor predeterminado.

Las campañas recurrentes añaden filas de programación con ventanas diarias, semanales, mensuales o personalizadas, horas de inicio/fin y zona horaria. El uso se rastrea por pedido/producto/cliente en mprdsd_campaign_usage, y el módulo comprueba límites de uso total, límites por cliente y límites de cantidad por producto antes de aplicar un descuento. El hook de precio usa deliberadamente el precio actual pasado por PrestaShop en lugar de llamar a Product::getPrice(), porque eso recursaría de nuevo en el hook de precio. Luego resta el mayor importe de descuento elegible del precio calculado actual y nunca escribe filas nativas de precio específico, por eso el descuento desaparece automáticamente cuando no hay ninguna campaña activa.

Sí, puede omitir sábados y domingos cuando está activada la exclusión de fines de semana. El cálculo de PrestaShop no cuenta esos días al sumar el tiempo de preparación y también mueve al lunes un resultado final que caiga en fin de semana.

Sí, admite eventos Purchase del lado del servidor mediante Meta Conversions API. En PrestaShop el módulo encola conversiones de compra, las envía a la versión configurada de Graph API y usa event IDs coincidentes para navegador y servidor.

Sí, admite respuestas adicionales aprobadas y votos de utilidad. En PrestaShop los registros de respuesta guardan tipo de autor, referencias de cliente o empleado, estado, conteos de votos y contenido, mientras los votos de preguntas y respuestas se registran por entidad e IP.

Sí. Las reglas de subtítulos de producto pueden dirigirse a todos los productos, productos concretos, productos en categorías, productos por fabricante y productos por proveedor. Las reglas de exclusión también pueden quitar productos específicos o coincidencias de categoría de una regla más amplia.

Sí, el módulo contiene una ruta automática de bloqueo de autenticación para logins fallidos de PrestaShop, pero solo se ejecuta cuando el registrador de logins fallidos del módulo es invocado por la integración de autenticación. Cada fallo registrado almacena IP del visitante, email intentado, user agent, ID de tienda y timestamp en mprceiipban_failed_logins.

Los dos ajustes que controlan el bloqueo son MPRCEIIPBAN_AUTOBAN_THRESHOLD y MPRCEIIPBAN_AUTOBAN_WINDOW. Los valores predeterminados de instalación son umbral 0 y ventana 60 minutos, así que el autoban está desactivado hasta configurar un umbral positivo. Cuando el número de fallos desde la misma IP dentro de la ventana configurada alcanza el umbral, el módulo añade un bloqueo auth con el motivo Auto-banned: X failed login attempts in Y min y una caducidad de una hora en el futuro.

Un bloqueo auth es más estrecho que un bloqueo completo del sitio: apunta a páginas relacionadas con autenticación, mientras que los bloqueos completos existentes siguen teniendo precedencia. Como este checkout de código fuente contiene el registrador y la lógica de bloqueo pero no un archivo concreto de override de autenticación, verifica que tu build instalada incluya la integración de autenticación antes de confiar en ello como única protección de login.

El contador de umbral se basa en IP. El email fallido se almacena para revisión, pero countRecentFailedLogins() cuenta solo filas con la misma ip_address más recientes que la ventana configurada; no cuenta por separado por email intentado. La comprobación de autoban también omite crear un nuevo bloqueo auth temporal si la IP ya está bajo un bloqueo completo.

• Para activarlo: define AUTOBAN_THRESHOLD en un número positivo como 5 y deja o ajusta AUTOBAN_WINDOW en minutos.
• Qué se crea: una fila activa en mprceiipban_banned con ban_type=auth, la IP del visitante y un date_expiry de una hora.
• Limpieza: las filas de login fallido están cubiertas por la ruta de purga del módulo, que usa los días de retención de log configurados.

AUTOBAN_THRESHOLD = 5
AUTOBAN_WINDOW = 60
Result after 5 failures from one IP in 60 minutes: temporary auth ban for 1 hour

Las reseñas con foto permiten a los compradores adjuntar imágenes reales de producto a sus valoraciones, lo que genera confianza y añade contenido único, rico en palabras clave, a tus páginas de producto. PrestaShop no tiene una función integrada de reseñas con imagen, así que la añades con un módulo de reseñas. Con Reviews & Ratings, activa la subida de imágenes en los ajustes de reseñas: el formulario acepta entonces archivos JPEG, PNG y WebP, aplica tu tamaño máximo de archivo y número de imágenes, redimensiona automáticamente subidas grandes, genera miniaturas y adjunta las imágenes al registro de reseña guardado. Las reseñas con foto aprobadas se muestran junto al producto y alimentan los rich results de valoración por estrellas. Define un límite sensato, por ejemplo 3-5 imágenes por reseña, y mantén la moderación activada para que solo se publiquen fotos genuinas y relevantes. Las fotos de clientes también reducen devoluciones al fijar expectativas precisas antes de comprar.

En la fuente local, esta función vive en el módulo mprcomments. Las subidas de imagen se activan con ALLOW_IMAGES, con valores predeterminados de 3 imágenes por reseña y 2 MB por imagen. La plantilla de reseña de producto usa un input de archivo múltiple llamado review_images[] y acepta image/jpeg, image/png y image/webp. El uploader valida tipo MIME, tamaño de archivo y dimensiones de imagen, luego redimensiona imágenes grandes a un máximo de 1200 por 1200 píxeles y crea miniaturas de 150 por 150.

La reseña se guarda primero con estado pending o approved según los ajustes de moderación, y luego las subidas de imagen se procesan inmediatamente contra ese ID de reseña guardado. La aprobación controla la visibilidad pública, no el adjunto de imagen. La validación normal de reseñas sigue aplicándose primero: el contenido de la reseña debe cumplir la longitud mínima, la valoración debe estar entre 1 y 5, los invitados se bloquean salvo que estén permitidos, se comprueban reseñas duplicadas de cliente y la moderación puede dejar la reseña pendiente en lugar de hacerla pública inmediatamente. Los datos estructurados se basan intencionadamente en reseñas nativas de producto; las reseñas de empresa importadas se excluyen del schema de producto, y el renderizador de schema limita los elementos de reseña incrustados mientras sigue generando aggregate rating cuando existen reseñas nativas.

PrestaShop trae una página de contacto fija, lo que no basta cuando necesitas solicitudes de presupuesto, consultas B2B, entrada de soporte o inscripciones a eventos. Para crear tus propios formularios, usa Better Contact Form: guarda formularios y sus campos en tablas dedicadas y los renderiza mediante un controlador de módulo o hook, con manejo funcional de valores enviados para campos text, email, phone, textarea, select, checkbox, URL y number. Puedes crear varios formularios para distintos propósitos, colocarlos en cualquier página y recoger envíos estructurados en lugar de emails de texto libre. Mantén cada formulario corto, marca claramente los campos obligatorios y añade protección anti-spam. Para GDPR, incluye una casilla de consentimiento y un enlace a tu política de privacidad para que los datos de consulta se recojan legalmente.

La plantilla también tiene una rama de input file, pero el procesador de envío actual lee valores de campo mediante Tools::getValue() y no maneja $_FILES. Eso significa que los campos de archivo pueden renderizarse, pero los archivos subidos no se persisten como valores de campo enviados en la implementación actual. No dependas de la recogida de archivos salvo que se añada manejo de archivos.

Formularios, campos, envíos y valores individuales de envío se guardan en tablas separadas, así que una consulta mantiene tanto una fila de resumen como datos de campo estructurados. El renderizador puede elegir un formulario concreto o el formulario activo predeterminado, no devuelve nada cuando un formulario está inactivo o no tiene campos, y prerrellena nombre/email de clientes conectados cuando están disponibles.

El procesamiento de envío comprueba que se haya publicado el botón submit, realiza comprobaciones de campos obligatorios, validación de tipo, validación de opciones select, métodos opcionales de validación de PrestaShop, aplicación de casilla GDPR, detección de spam y persistencia en base de datos. El valor oculto _mpr_ft no es un token CSRF; es una marca temporal base64 usada por la comprobación anti-spam de tiempo. Honeypot y comprobación de tiempo anti-spam están activados por defecto, con un tiempo mínimo de envío predeterminado de 3 segundos. Los envíos de spam siguen guardándose con is_spam y spam_reason, pero los emails de administración/cliente solo se envían para envíos no spam. Eso te da una pista de auditoría sin dejar que tráfico de bots evidente dispare notificaciones.

Sí, las elecciones de consentimiento pueden registrarse cuando el logging está activado. El controlador AJAX de PrestaShop guarda mapa de consentimiento, fuente y versión, mientras el modelo de log aplica hash a visitante, IP y user agent en vez de guardarlos en texto claro.

Puedes añadir Criteo OneTag a PrestaShop configurando un Criteo Partner ID numérico y activando el seguimiento de navegador. El módulo crea eventos OneTag en el header para páginas ecommerce compatibles y mantiene el tracking inactivo si falta el Partner ID o no es válido.

Sí, las tareas cron personalizadas pueden añadirse desde el controlador de tareas. El formulario admin de PrestaShop valida módulo propietario, calendario, contexto y tipo de ejecutor, y admite tareas URL, callable y command, con command limitado a cron o pruebas admin explícitas.

En PrestaShop, el H1 de página de categoría es el nombre de la categoría, así que cambiar el encabezado para SEO normalmente también cambia tus etiquetas de menú y breadcrumbs, algo que normalmente no quieres. La solución es sobrescribir el H1 de forma independiente. Con Custom Category H1, guardas un valor H1 separado por categoría y el módulo lo sustituye en la página de categoría mediante hooks de PrestaShop, dejando intacto el nombre del objeto Category (y por tanto la navegación y breadcrumbs). Esto te permite apuntar a un encabezado rico en palabras clave como "Waterproof Shower Trays for Wet Rooms" mientras el menú sigue mostrando un breve "Shower Trays". Ten en cuenta que las categorías raíz se excluyen intencionadamente, porque no renderizan una página de categoría normal del escaparate donde aplique un H1 visible para compradores. Usa un H1 claro y único por categoría y mantenlo alineado con el title tag de esa página; consulta nuestra guía SEO de PrestaShop.

El módulo guarda overrides en tablas dedicadas para filas de override, valores de idioma y asignaciones de categoría. Los valores predeterminados son activado, mostrar el campo de edición de categoría, sustituir el nombre de página de categoría en el contenido de categoría filtrado, aplicar el mismo valor a etiquetas de listado de productos, recurrir al idioma predeterminado, recurrir de un valor específico de tienda a un valor de todas las tiendas, eliminar etiquetas HTML y normalizar espacios. Existe fallback de categoría padre, pero está desactivado por defecto para evitar encabezados duplicados entre categorías hijas.

Para trabajo SEO masivo, un override puede asignarse a varias categorías. Si un comerciante edita después directamente una categoría y esa categoría pertenece a un override compartido, el código separa esa categoría concreta y crea un override local de categoría, dejando el override compartido para las demás. El valor H1 puede usar placeholders como {category_name}, {nb_products}, {page}, {page_label}, {shop_name} y {lang}. La paginación también puede añadir automáticamente una etiqueta de página cuando está activada. El módulo cambia los datos de categoría renderizados; no renombra el registro de categoría guardado en PrestaShop.

Puedes recopilar IP de visitante e información de dispositivo con este módulo PrestaShop cuando la recopilación está activada. Guarda ID de cliente o invitado, ID de tienda, dirección IP, datos de país, detalles de dispositivo y campos opcionales de user agent, sistema, navegador y resolución.

Los clientes pueden enviar galerías de proyectos desde el flujo front-office del módulo. En PrestaShop el showcase guarda proyectos, títulos y descripciones multiidioma, imágenes, categoría y estado de moderación, con límites por defecto de 20 imágenes y 5 MB por imagen.

El módulo permanece instalado, pero hookDisplayHeader() no devuelve nada porque isActive() requiere el Brand ID. El aviso de configuración obligatoria también informa al personal de que el seguimiento permanece inactivo hasta que se añada el Brand ID.

No. El módulo comprueba si mprcheckoutrevolution está instalado y habilitado. Cuando está activo, este módulo le cede la interfaz de edición de pedidos en lugar de gestionar por sí mismo los hooks de edición de pedidos.

El generador comprueba el registro de referencias del módulo, la tabla nativa orders y las referencias de order_payment. Prueba hasta 10 candidatos antes de registrar un error y desistir.

El formulario ofrece coma, punto y coma, tabulación y pipe. El controlador convierte la opción tab en un carácter de tabulación real antes de transmitir el CSV.

El esquema incluye tablas para equipos, empleados de equipo, asignaciones equipo-estado, estados de workflow y traducciones, historial de pedido, comentarios de pedido, recordatorios, notificaciones y preferencias de notificación de empleados.

Registra displayHeader, displayOrderConfirmation, actionValidateOrder y actionCustomerAccountAdd. Estos hooks renderizan tracking del navegador y ponen en cola datos de conversión relacionados con pedidos o registros.

No. El código de detección comprueba si la referencia del producto empieza por mpr-pack-. El contenido del pack se lee después desde la tabla propia del módulo mpr_pack_content.

El hook comprueba actionDispatcherBefore y solo gestiona Dispatcher::FC_FRONT y Dispatcher::FC_MODULE. Los dispatches de Back Office se ignoran.

hookPaymentOptions() requiere módulo activo, configuración habilitada, cliente conectado, al menos un término de pago activo asignado a los grupos del cliente y crédito suficiente para el total del carrito actual.

El resolver ordena las coincidencias activas por prioridad. En modo único devuelve el subtitulo de mayor prioridad; en modo todos devuelve la lista ordenada para que la plantilla pueda mostrar más de un subtitulo.

Detecta el país del visitante en un orden fijo de fallback. Primero lee la cabecera de Cloudflare HTTP_CF_IPCOUNTRY cuando existe y no es XX. Si no está disponible, intenta GeoIP de PrestaShop mediante GeoIp::getCountryByAddr($ip) y convierte el nombre de país devuelto de vuelta a un código ISO. Si GeoIP no está disponible, finalmente comprueba la cookie de contexto de PrestaShop iso_code_country.

1. Cloudflare reverse proxy sends HTTP_CF_IPCOUNTRY=US -> module stores country code US and resolves the country name.
2. No Cloudflare header -> PrestaShop GeoIP returns United States -> module looks up ISO code US.
3. GeoIP unavailable -> PrestaShop cookie iso_code_country=US is used.
4. No signal -> empty country code and empty country name.

Eso significa que los bloqueos de país dependen de la señal disponible para esa solicitud. Si dependes de la detección de país de Cloudflare, asegúrate de que el tráfico de la tienda llegue realmente a PrestaShop a través de Cloudflare para que la cabecera esté presente.

La IP del visitante usada para GeoIP viene de Tools::getRemoteAddr() cuando PrestaShop la proporciona. El módulo tiene una cadena de fallback para HTTP_CF_CONNECTING_IP, HTTP_X_REAL_IP, el primer valor de HTTP_X_FORWARDED_FOR y luego REMOTE_ADDR. Eso importa porque la calidad de GeoIP depende de la IP real del cliente, no de la IP de un proxy intermedio.

Un bloqueo de país solo coincide cuando la solicitud actual tiene un código de país no vacío. Si Cloudflare envía XX, falta GeoIP, la búsqueda de nombre de país no puede mapear el resultado GeoIP a un código ISO y la cookie está ausente, las reglas solo de país no se dispararán para esa solicitud. VPNs, proxies y configuración CDN también pueden hacer que el país detectado difiera de la ubicación física del comprador.

No. S2S_ENABLED es false por defecto. El panel de readiness trata S2S explícitamente como opcional, y el tracking Pixel del navegador puede funcionar con un Marketer ID válido y tracking de navegador activado.

Sí, el módulo incluye herramientas de importación y exportación para contenido de blog. El controlador admin de PrestaShop puede importar XML WordPress WXR, incluidos comentarios opcionales, y exportar datos del blog como XML o JSON mediante el servicio BlogExporter.

El controlador checkout personalizado redirige a los compradores a la página de pedido nativa de PrestaShop cuando el one page checkout está desactivado. Así el módulo no fuerza su flujo si el ajuste one_page_checkout_enabled está apagado.

El banner vuelve a aparecer cuando falta la cookie de consentimiento o ha caducado. En el front de PrestaShop, JavaScript lee mprcookie_consent y oculta el banner a compradores recurrentes; la caducidad configurada controla la duración de la elección, con 365 días por defecto.

Sí, el módulo tiene un interruptor de visualización móvil. Antes de renderizar el widget Crisp, el guard de PrestaShop comprueba SHOW_MOBILE y el contexto del dispositivo; si la visualización móvil está desactivada y el contexto es móvil, no se imprime el script de Crisp.

El Front Controller acepta un nombre de evento y parámetros JSON, rechaza payloads de más de 8192 caracteres, conserva como máximo 50 claves normalizadas por nivel, limita la profundidad de anidación y trunca valores de texto a 512 caracteres.

No, las subidas de archivos no se procesan en el código actual de envío. La lista de campos admin incluye un input de archivo, pero el procesador lee valores con Tools::getValue y no gestiona el array PHP files, rutas de almacenamiento ni adjuntos de email.

Sí, el módulo incluye un escáner de cookies del storefront. Puede rastrear una URL de PrestaShop, inspeccionar cabeceras Set-Cookie y asignaciones inline document.cookie, guardar cookies nuevas sin categorizar y sugerir categorías para patrones conocidos de analítica, marketing y funcionales.

Sí, los comerciantes pueden definir reglas de disparador para eventos Criteo compatibles. La configuración PrestaShop acepta reglas JSON validadas con disparadores de clic, URL, controlador o evento DOM, y normaliza los nombres al vocabulario OneTag admitido por Criteo.

No, desinstalar el módulo no elimina las tablas cron compartidas. La ruta de desinstalación de PrestaShop quita el menú admin del módulo y desregistra sus propias tareas, pero conserva deliberadamente las tablas cron porque otros módulos MPR pueden depender de la misma infraestructura.

No, las categorías raíz son rechazadas por la lógica de guardado de overrides. El controlador admin de PrestaShop comprueba que las categorías seleccionadas sean categorías storefront, porque las raíz no renderizan páginas normales de categoría donde se aplicaría un H1 visible.

Sí, puede hacer coincidir patrones de user agent como objetivos de ban. En el admin de PrestaShop, una regla puede usar texto simple para contiene sin distinguir mayúsculas o una regex entre barras, y combinarse con filtros de IP, CIDR o país.

Sí. El validador acepta dígitos separados por comas o espacios en blanco, hasta las reglas de longitud configuradas, por lo que pueden guardarse varios IDs numéricos en el campo Marketer ID.

El panel de diagnóstico incluye una acción Retry failed events. Llama al reset de queue compartido para este módulo y el provider outbrain, devolviendo los eventos fallidos al estado pending.

El módulo guarda IDs de producto en la cookie del navegador del visitante mprrecent_ids. La cookie se escribe con ruta /, vida de 30 días y SameSite=Lax.

No. El controlador AJAX crea un objeto Product para cada ID solicitado y omite entradas no cargadas o no activas antes de devolver datos de tarjeta de producto.

La respuesta AJAX incluye el nombre de cada producto, URL de producto, URL de imagen de portada usando home_default y precio formateado. El script front renderiza esos valores como tarjetas de producto compactas.

No se requiere cuenta, y la descripción fuente dice que funciona para invitados, clientes con sesión iniciada y visitantes recurrentes. Recuerda páginas de producto recientes en una cookie del navegador en lugar de rellenar una tabla de historial de usuario de PrestaShop. Aun así debes describir el uso de cookies en tu información de privacidad o cookies cuando los requisitos legales de tu tienda lo pidan.

El script del storefront usa una cookie llamada mprrecent_ids. En páginas de producto, pone el ID del producto actual al principio de la lista, elimina duplicados, limita la lista al máximo configurado y escribe la cookie durante 30 días con SameSite=Lax. El valor predeterminado de instalación es MAX_PRODUCTS=8, y el hook de display predeterminado es displayFooterProduct.

Cuando se renderiza el widget, el navegador lee la cookie y envía por POST la lista de IDs de producto al controlador AJAX del módulo. El controlador sanea los IDs con intval, elimina valores vacíos, limita la solicitud a 20 IDs y solo devuelve productos activos. La respuesta contiene ID de producto, nombre, URL, imagen de portada y precio formateado para que el widget pueda dibujar la lista de productos recientes.

Así que el módulo no construye un perfil de navegación server-side ligado a una cuenta de cliente. El servidor sigue recibiendo los IDs de producto recientes durante la búsqueda AJAX, y los IDs se almacenan en la cookie del navegador del visitante, por lo que la función sigue siendo tracking basado en cookies desde el punto de vista de aviso de privacidad.

Introduce el AdRoll Advertiser ID de adroll_adv_id, introduce el Pixel ID de adroll_pix_id, activa el tracking de navegador y elige los eventos que quieres enviar. Ambos IDs deben contener solo letras, números, guiones bajos o guiones, y el tracking permanece inactivo hasta que los IDs son válidos y el módulo está activado.

• Configuración obligatoria: Advertiser ID, Pixel ID y tracking de navegador activado.
• Eventos del recorrido de página: page view, product view, checkout start y search.
• Eventos de interacción: add to cart, add to wishlist, signup y eventos personalizados de navegador configurados.
• Evento purchase: enviado en la confirmación de pedido cuando el tracking de purchase está activado.

El módulo es una integración Pixel de navegador. Sus propios metadatos demo marcan la compra server-side de AdRoll como no disponible porque el acceso público S2S de AdRoll no se expone como flujo estable de token/endpoint en este módulo.

En la instalación, el tracking de navegador en sí queda desactivado por defecto, mientras que los interruptores de eventos estándar quedan activados por defecto. Eso permite al comerciante configurar IDs primero y luego activar tracking cuando esté listo. La exclusión de empleados y el respeto al consentimiento de marketing están ambos activados por defecto, así que empleados de back office navegando el storefront y visitantes sin consentimiento de marketing soportado pueden suprimirse antes de enviar eventos.

El hook de cabecera prepara la cola de AdRoll, define window.adroll_adv_id, window.adroll_pix_id y window.adroll_version='2.0', y luego carga https://s.adroll.com/j/roundtrip.js. Los eventos de cabecera se construyen server-side para page view, product view, checkout start, search y signup, mientras que add-to-cart y wishlist se enlazan en JavaScript a eventos de PrestaShop o selectores comunes de botones.

Los eventos personalizados de navegador son opcionales y están desactivados por defecto. Si se activan, el JSON debe ser un array o un objeto con un array events. Los nombres de evento se limitan a letras, números, guiones bajos y guiones, con un límite de 64 caracteres, y este módulo limita los eventos personalizados a 15 nombres de evento distintos. Los triggers soportados son click, url, controller y event.

[{"event":"GalleryBrowse","trigger":"click","selector":".product-images img","params":{"segment_name":"gallery_browse"}}]

Sí, el tracking de purchase envía valor de pedido y moneda desde la página de confirmación de pedido de PrestaShop. El módulo también construye recuento de artículos, referencia de pedido, IDs de producto, nombres, categorías, precios y cantidades, y luego envía el evento purchase mediante el pixel del navegador cuando el tracking de purchase está activado.

El hook de confirmación de pedido comprueba primero la puerta normal de tracking: el módulo debe estar activo, los IDs deben ser válidos, la exclusión de empleados no debe bloquear la solicitud, el consentimiento de marketing debe pasar cuando está activado, y TRACK_PURCHASE debe estar activo. Luego acepta order u objOrder desde los parámetros del hook de PrestaShop y construye el payload de compra desde ese pedido cargado.

El mapeo de valor es explícito. Los datos comunes de conversión se convierten a parámetros estilo AdRoll: value se convierte en conversion_value, currency en adroll_currency, num_items se mantiene como recuento de artículos, order_id se define como la referencia de pedido de PrestaShop, y los datos de producto se convierten en product_id, content_ids y un array products con ID de artículo, nombre, precio y cantidad cuando están disponibles.

El evento sigue siendo del lado del navegador. La plantilla llama a window.mpradrollTrack('purchase', params, 'Order confirmation') cuando el script de cabecera está presente, o recurre a window.__adroll.track/window.adroll.track. Si existe la función legacy record_user de AdRoll, la plantilla también la llama, pero el módulo no envía una solicitud purchase server-to-server.

Sí. Cuando MPRADROLLPIXEL_RESPECT_CONSENT está activado, el módulo comprueba módulos de consentimiento de cookies soportados antes de renderizar o disparar tracking de AdRoll. Con mprcookiesrevolution, el consentimiento de marketing se concede solo cuando la cookie mprcr_consent contiene marketing:1. Con mprcookiebanner, el consentimiento se concede cuando mprcookie_consent=granted. Si falta la cookie correspondiente, el módulo recurre al valor DEFAULT_CONSENT de ese módulo de consentimiento.

mprcookiesrevolution allowed: mprcr_consent=essential:1|marketing:1|statistics:1
mprcookiesrevolution blocked: mprcr_consent=essential:1|marketing:0|statistics:1
mprcookiebanner allowed: mprcookie_consent=granted

Si no hay activo ningún módulo de consentimiento soportado, la comprobación de consentimiento no bloquea el tracking. La exclusión de empleados todavía puede suprimir tracking por separado cuando MPRADROLLPIXEL_EXCLUDE_EMPLOYEES está activado.

Los valores predeterminados de instalación están orientados a privacidad: RESPECT_CONSENT=1 y EXCLUDE_EMPLOYEES=1. El método server-side canTrack() devuelve false si el módulo está inactivo, si un contexto de empleado válido navega el front office o si no se concede consentimiento de marketing según las comprobaciones de módulos de consentimiento soportados.

La plantilla de navegador también realiza una comprobación de consentimiento antes de cargar AdRoll. Cuando está activo un módulo de consentimiento soportado, comprueba window.MPRCR.isGranted('marketing') si está disponible y luego las mismas dos cookies. Si esa comprobación client-side falla, el script retorna antes de cargar roundtrip.js o disparar eventos en cola. Un detalle práctico es que la comprobación client-side no conoce el valor server-side DEFAULT_CONSENT, así que una configuración que depende de consentimiento granted predeterminado sin cookie de consentimiento debe probarse en el navegador.

No, este módulo envía eventos de AdRoll mediante el pixel del navegador, no mediante una API server-side pública. El código de PrestaShop incluye una nota demo indicando que AdRoll S2S es beta bajo soporte; en producción carga roundtrip.js y solo envía eventos del navegador.

Usa este módulo para definir nombres visibles separados para páginas CMS de PrestaShop. Almacena un nombre visible por id_cms, idioma y tienda en su propia tabla mprcmsnames, así que el registro CMS nativo y su meta_title SEO no se reescriben en la tabla CMS.

• Ejemplo: mantén el meta title de la página CMS como Terms and Conditions | My Shop para SEO.
• Abre la pantalla CMS Display Names del módulo y encuentra esa fila de página CMS por ID y meta title existente.
• Introduce un nombre visible más corto como Terms en el campo Display Name y guarda.
• En el front office, el encabezado de la página CMS recibe el nombre visible mediante filterCmsContent, y los enlaces CMS que coinciden con el patrón cms-page-link de PrestaShop se sustituyen en el HTML final.
• Si limpias el campo de nombre visible, el módulo elimina su fila personalizada para esa página CMS y la tienda vuelve al meta_title CMS original.

Así que la división práctica es: usa el título CMS nativo para snippets de búsqueda y comportamiento del título del navegador, y usa este módulo para encabezados de página, enlaces de footer y etiquetas de menú más cortos que los compradores escanean realmente.

El módulo tiene dos rutas de front office. Primero, filterCmsContent cambia el objeto CMS pasado a la plantilla de página sustituyendo meta_title por el nombre visible almacenado para el idioma y tienda actuales. Segundo, actionOutputHTMLBefore edita el HTML final de enlaces CMS coincidentes antes de enviar la respuesta.

El comentario fuente es explícito: la etiqueta HTML real <title> no se ve afectada porque PrestaShop la construye mediante Meta::getMetaTags() usando su propia ruta SQL. Por eso este módulo puede acortar nombres visibles sin sobrescribir el título SEO CMS almacenado por PrestaShop.

El marcado del tema sigue importando. El reetiquetado de enlaces solo se ejecuta en anchors que coinciden con el patrón esperado por el módulo para enlaces CMS, con el ID de página CMS en link-cms-page-{id}-... y el atributo de clase exacto cms-page-link en el orden esperado por la regex. Si un tema construye menús CMS con marcado distinto o HTML anidado dentro del texto del anchor, el encabezado aún puede cambiarse pero el texto del enlace quizá no se sustituya.

No, no reescribe la etiqueta HTML title. El módulo se limita intencionadamente al contenido CMS visible y al texto renderizado de enlaces CMS, para que PrestaShop pueda seguir usando el meta title CMS original para el head de la página y los snippets de búsqueda.

El comentario fuente indica que la etiqueta <title> la construye la ruta Meta::getMetaTags() de PrestaShop y no se ve afectada. El módulo no actualiza la tabla CMS nativa, no se engancha a la generación de meta tags y no escribe un nuevo título SEO de vuelta en PrestaShop.

Lo que sí puede cambiar es el objeto CMS pasado por filterCmsContent. Si la plantilla de página usa el meta_title de ese objeto CMS filtrado como encabezado visible, los compradores ven el nombre visible más corto en la página. Por separado, actionOutputHTMLBefore puede sustituir texto de enlaces CMS coincidentes en el HTML final. Esos son cambios de contenido visible, no cambios de head tag.

Para trabajo SEO, sigue editando el meta title CMS real en la página CMS nativa de PrestaShop. Usa este módulo cuando el título SEO sea demasiado largo para menús, footers, breadcrumbs o encabezados en la página.

Reetiqueta enlaces CMS que coinciden con el marcado de enlace CMS esperado por PrestaShop. El hook de salida busca un anchor cuyo id empiece por link-cms-page-{id}- y cuya clase sea cms-page-link, y luego sustituye el texto plano del enlace por el nombre visible almacenado para el idioma y tienda actuales.

<a id="link-cms-page-3-1" class="cms-page-link" href="/content/3-terms-and-conditions">Terms and conditions</a>

Ese patrón importa para temas personalizados: si el enlace CMS tiene una clase distinta, no tiene id link-cms-page-..., la clase aparece antes del id en el marcado al que apunta el módulo, o la etiqueta se construye con HTML anidado en lugar de texto plano, la sustitución de salida puede no coincidir.

La regex es deliberadamente estrecha. Espera el atributo id antes de class="cms-page-link", y captura texto plano entre las etiquetas de apertura y cierre del anchor. Un enlace con múltiples clases como class="footer-link cms-page-link", un span dentro del anchor o un componente de menú completamente personalizado puede quedar fuera de ese patrón.

La sustitución tampoco hace nada en el back office y retorna pronto si no hay nombres visibles para el idioma y tienda actuales. Si el footer o menú CMS de tu tema no se reetiqueta, inspecciona primero el marcado anchor generado; a menudo la solución es hacer que la plantilla emita el patrón nativo de ID y clase de enlace CMS de PrestaShop.

Sí, los nombres visibles se almacenan por página CMS, idioma y tienda. La tabla del módulo usa id_cms, id_lang e id_shop como clave, y guardar un valor vacío elimina esa etiqueta almacenada para que PrestaShop vuelva al título CMS nativo.

La búsqueda de front office también es específica por idioma y tienda. Carga filas de mprcmsnames donde id_lang equivale al idioma de contexto actual y id_shop equivale a la tienda de contexto actual. No hay fallback amplio id_shop=0 en esta búsqueda, así que un nombre visible guardado para una tienda no se reutiliza automáticamente en otra.

Al guardar, el módulo recorre páginas CMS e idiomas, reemplazando filas cuando se envía un valor y eliminando filas cuando el valor enviado está vacío. Por eso limpiar un campo es un reset real, no solo una etiqueta personalizada en blanco.

Un detalle de implementación que comprobar en esta versión de código fuente: la tabla de configuración renderizada muestra el input del idioma predeterminado para cada página CMS. La base de datos y la lógica de guardado soportan id_lang, pero el formulario visible en este checkout no renderiza columnas de input separadas para cada idioma. Si necesitas nombres visibles en idiomas no predeterminados, confirma que la build instalada exponga esos inputs o añádelos antes de confiar en edición multilingüe mediante el formulario estándar.

Sí, el módulo genera automáticamente una contraseña para formularios de registro y checkout soportados. En PrestaShop apunta a campos comunes de contraseña de cliente, autenticación y checkout, y luego rellena inputs password, passwd, confirmation y password_confirmation cuando coincide el ámbito de página configurado.

Los valores predeterminados de instalación activan el módulo, lo aplican tanto a registro como a checkout, ocultan campos de contraseña, generan una contraseña de 12 caracteres e incluyen mayúsculas, números y caracteres especiales. Los controladores aplicables son authentication, registration e identity para registro, más order, orderopc y order-opc para checkout.

En PrestaShop 1.7+, el módulo registra su CSS y JavaScript front mediante actionFrontControllerSetMedia. En PrestaShop 1.6, carga los assets desde displayHeader. El mismo hook de cabecera inyecta los ajustes de contraseña en window.mprcustomerpassword_config para que JavaScript los use.

El script frontal encuentra campos nombrados como password, passwd, confirmation y password_confirmation, y también escanea formularios comunes de registro/autenticación buscando cualquier input type=password. Genera una contraseña por página, rellena todos los campos coincidentes con el mismo valor, define autocomplete=new-password y añade al formulario un marcador oculto mprcustpass_auto=1.

• Modo oculto: el wrapper del campo de contraseña se oculta y se marca aria-hidden.
• Modo opcional en código: el campo se muestra con el valor generado y un mensaje informativo, pero el script define el campo como readonly.
• Formularios dinámicos de checkout: un MutationObserver reprocesa campos de contraseña insertados recientemente, y el script protege los valores generados al enviar y con una comprobación periódica.

Sí, puede enviar por email la contraseña generada cuando el modo de email está configurado para enviar contraseña. El hook de alta de cuenta de PrestaShop solo envía ese email cuando el formulario enviado incluye el marcador de autogeneración del módulo, así que las cuentas de cliente normales no se procesan accidentalmente.

El EMAIL_MODE predeterminado es send_password. Cuando se ejecuta actionCustomerAccountAdd, el módulo primero comprueba que esté activado y luego busca mprcustpass_auto en el formulario enviado. Ese marcador lo añade JavaScript solo después de rellenar campos de contraseña, así que la ruta de email queda ligada a contraseñas generadas por el módulo.

Para el email de contraseña, el módulo lee primero la contraseña enviada desde password y recurre a passwd para formularios antiguos de PrestaShop. Si ninguno está presente cuando llega el hook, retorna sin enviar. Cuando envía, usa la plantilla de correo mprcustomerpassword_account y pasa nombre, apellidos, email, contraseña generada, nombre de tienda y URL de tienda del cliente.

Hay dos alternativas importantes. Con EMAIL_MODE=silent, el hook sale sin enviar email de contraseña. Con EMAIL_MODE=setup_link, envía un enlace de restablecimiento/configuración en lugar de la contraseña generada. Los comerciantes que no quieran enviar contraseñas por email deben usar setup-link o modo silent en lugar del modo predeterminado send-password.

Sí, el módulo puede enviar un enlace de configuración en lugar de la contraseña generada. En modo setup-link de PrestaShop crea un token de restablecimiento, almacena un valor de validez de 24 horas en el registro del cliente o campos legacy, y envía al cliente un enlace a la página de contraseña.

Esta ruta se selecciona con EMAIL_MODE=setup_link. El mismo hook de alta de cuenta y marcador mprcustpass_auto siguen aplicándose, así que el email de configuración solo se envía para cuentas donde el script frontal del módulo generó y envió los campos de contraseña.

En objetos de cliente de PrestaShop nuevos que exponen reset_password_token, el módulo crea un token desde random_bytes(32), lo hace apto para URL sustituyendo caracteres base64 inseguros, lo almacena en reset_password_token, define reset_password_validity a 24 horas en el futuro, actualiza el cliente y construye una URL de página de contraseña con token, id_customer y reset_token.

Para la ruta legacy, el módulo crea un token MD5, actualiza directamente los campos reset_password_token y reset_password_validity de la tabla customer con una ventana de validez de 24 horas, y construye la URL de página de contraseña con token e id_customer. El email usa la plantilla mprcustomerpassword_setup con {setup_link}, valores de identidad del cliente, nombre de tienda y URL de tienda.

La contraseña generada sigue usándose para permitir que PrestaShop cree la cuenta durante checkout o registro. La diferencia es lo que el cliente recibe después: el modo setup-link envía un enlace para elegir contraseña, mientras que el modo send-password envía la propia contraseña generada.

No, el modo opcional muestra la contraseña generada, pero el script actual deja el campo como solo lectura. En PrestaShop el modo oculto esconde el bloque de contraseña, mientras el modo opcional muestra el valor con una nota informativa.

Añade un Facebook Page Access Token y Page ID, y luego activa el feed. En PrestaShop el módulo obtiene publicaciones desde Facebook Graph API y puede renderizarlas en hooks de home, footer, columna izquierda o columna derecha.

El formulario de conexión espera un Page Access Token y Page ID. La ayuda admin dirige a los comerciantes hacia una app Facebook Developer con acceso Pages API y permisos pages_read_engagement y pages_read_user_content. Page Name es opcional y se usa para la cabecera del feed cuando se proporciona.

• El hook de display predeterminado es displayHome, pero el módulo también soporta displayFooterBefore, displayFooter, displayLeftColumn y displayRightColumn.
• El recuento predeterminado de publicaciones es 6, el layout predeterminado es una cuadrícula de 3 columnas, y la caché compartida del feed tiene por defecto 3600 segundos.
• Si falta el access token o Page ID, la obtención desde Facebook API no devuelve publicaciones, así que el bloque de front office no tiene nada que renderizar.

MPRFB_ACCESS_TOKEN=your-page-token
MPRFB_PAGE_ID=your-page-id
MPRFB_DISPLAY_HOOK=displayHome
MPRFB_POST_COUNT=6

Cuando está configurado, el módulo llama a Facebook Graph API v21.0 para las publicaciones de la página, almacena el feed normalizado en caché y solo renderiza en el hook seleccionado en los ajustes del módulo.

Sí, puede mostrar texto de publicación, medios, fecha, reacciones, compartidos, comentarios e información de autor. En PrestaShop estas opciones de visualización se configuran por separado, y las publicaciones compartidas pueden excluirse cuando el ajuste EXCLUDE_SHARED está activado.

Los interruptores relevantes son ajustes separados como SHOW_TEXT, SHOW_MEDIA, SHOW_DATE, SHOW_REACTIONS, SHOW_SHARES, SHOW_COMMENTS y SHOW_AUTHOR. El texto está activado por defecto y se trunca con puntos suspensivos cuando supera TEXT_LENGTH, que por defecto es 200 caracteres.

• Los medios se extraen primero de attachments y subattachments de Facebook, con full_picture usado como fallback.
• Los recuentos de reacciones, comentarios y compartidos vienen de los campos summary devueltos por Facebook, así que los recuentos mostrados dependen de lo que incluya la respuesta API.
• Cuando EXCLUDE_SHARED está activado, se omiten publicaciones con status_type igual a shared_story.
• Las publicaciones sin texto de mensaje ni imagen se omiten antes de renderizar.

Esto importa porque un comerciante puede construir un bloque compacto de prueba social solo con imágenes y recuentos de engagement, o un feed editorial más completo con captions, fechas y atribución de página.

Los proyectos aprobados admiten votación de la comunidad y comentarios anidados. El número de votos y de visitas se guarda por proyecto, lo que ofrece una señal sencilla de qué trabajos de clientes despiertan más interés.

Sí. El módulo cachea el feed de Facebook en un archivo JSON llamado mprfb_feed_cache.json. La caché almacena un timestamp cached_at y los posts obtenidos, y luego reutiliza esas publicaciones hasta que caduca la duración configurada.

Cache file: mprfb_feed_cache.json
Duration setting: MPRFB_CACHE_DURATION=3600
Admin refresh: submitMprfbSync clears the file; the next front-office feed load fetches fresh posts and writes cached_at + posts

La duración predeterminada de caché en el trait compartido del feed es 3600 segundos. El formulario de configuración del módulo expone duraciones comunes como 30 minutos, 1 hora, 2 horas, 6 horas, 12 horas y 24 horas. Las acciones admin refresh y clear-cache eliminan ambas el archivo de caché, así que la siguiente solicitud de feed se fuerza de vuelta a la fuente de Facebook en lugar de servir publicaciones cacheadas obsoletas.

La caché es independiente de la solicitud, así que los compradores normales no disparan una llamada a Facebook API en cada página vista. Si el archivo de caché falta, está vacío, tiene JSON inválido o es más antiguo que la duración configurada, el trait compartido de feed lo trata como caducado y vuelve a obtener datos. Guardar configuración relacionada con el feed también limpia la caché del feed, lo que evita mezclar cambios de layout o recuento con datos antiguos de publicaciones.

Para tiendas con tráfico, esta es la protección principal contra cargas de página lentas y presión API evitable. Para lanzamientos de campaña, usa la acción admin refresh después de publicar en Facebook si quieres que el bloque del storefront recoja contenido nuevo inmediatamente en lugar de esperar a la siguiente caducidad de caché.

Sí, puede publicar entradas de blog en Facebook, pero el flujo de autopublicación está construido alrededor de entradas de MPR Blog Revolution, no de cualquier módulo de blog de terceros posible. El módulo de Facebook usa el trait compartido de publicador social, escucha hooks de add y update de objetos PrestaShop, comprueba que auto-publish esté activado, comprueba si es un objeto Blog Revolution o estilo Post, y solo continúa cuando el objeto tiene status = 1.

La prevención de duplicados se almacena en la tabla mpr_social_publish. Antes de enviar, el módulo comprueba si mprfacebookpostsintegration ya ha publicado el tipo de objeto blog_post con ese ID de entrada en la plataforma facebook. Los envíos correctos se registran con el ID de publicación de plataforma, URL de plataforma, caption, URLs de medios y estado published, así que hooks add o update posteriores omiten la misma entrada en lugar de enviarla otra vez.

Los captions vienen de la plantilla de autopublicación del módulo Facebook. Los placeholders soportados son {title}, {excerpt}, {url} y {shop_name}. Si la entrada de blog tiene una imagen destacada, el publicador construye su URL de medio desde img/mprblogrevolution/posts/. Si faltan credenciales de Facebook, el publicador no está configurado o no se cumple una condición obligatoria de plataforma, la ruta de autopublicación retorna sin publicar.

El publicador específico de Facebook solo se configura cuando existen tanto PAGE_ID como ACCESS_TOKEN. Usa Facebook Graph API v21.0, soporta publicaciones de texto, enlaces y fotos/imágenes en la ruta implementada publish(), permite un elemento multimedia por envío y tiene un límite de caracteres de 63206. Una publicación solo de imagen se envía mediante el endpoint de fotos de página, mientras que las publicaciones de enlace o texto usan el endpoint feed de página.

Aunque getSupportedMediaTypes() actualmente lista video, el publicador implementado no sube vídeo ni llama a un endpoint de vídeos. Trata la publicación de vídeo como no soportada salvo que se añada una ruta real de publicación de vídeo.

MPRFB_AUTOPUBLISH=1
MPRFB_AUTOPUBLISH_CAPTION={title}
{excerpt}
Read more: {url}

El módulo también omite su propia ruta de publicador cuando la toma de control más amplia de mprsocialrevolution está activa para Facebook, para que dos módulos sociales no intenten publicar la misma entrada de blog al mismo tiempo.

El módulo añade páginas dedicadas de galería, categoría, proyecto, envío y un área de cliente „mis proyectos“, cada una con su propia URL optimizada para SEO. Los proyectos aprobados destacados también pueden mostrarse en zonas seleccionadas de la tienda.

Todos los textos de la galería — categorías, proyectos y comentarios — se almacenan por idioma, por lo que la galería es totalmente multilingüe. El módulo funciona en PrestaShop de la 1.6.1 a la 9.x.

Sí, cada perfil de feed puede llevar su propio idioma, moneda, países objetivo y etiquetas. Es útil cuando una tienda vende en varios mercados con distinta redacción de catálogo o estructura publicitaria. Una separación clara de feeds también ayuda a los responsables a entender qué mercado genera ingresos y cuál necesita atención.

En el modelo de feed, cada perfil almacena id_lang, id_currency, id_shop, target_country, feed_label, content_language y sync_mode. Un feed nuevo usa por defecto ajustes franceses en el código fuente actual: target_country=FR, feed_label=FR y content_language=fr.

target_country=AE,AU,GB,US
feed_label=GB
content_language=en
sync_mode=file_only or api

• target_country se normaliza a mayúsculas y puede ser un código de país de dos letras o una lista separada por comas.
• feed_label se normaliza a mayúsculas y debe encajar con la forma de etiqueta de Google Merchant API: letras mayúsculas, números y guiones, hasta 20 caracteres.
• content_language se normaliza a minúsculas y debe ser un código de idioma de dos letras para input de producto API.
• Para sincronización API, perfiles de feed separados suelen ser más limpios cuando cada mercado necesita una etiqueta, moneda o idioma distinto.

El controlador frontal de feed sirve un feed específico por ID o nombre de archivo con un token, usa un TTL de caché predeterminado de 3600 segundos y puede regenerar con generate=1. Eso permite que una tienda PrestaShop mantenga feeds Merchant separados sin mezclar países, idiomas o etiquetas de campaña.

No, la descripción fuente dice que los valores numéricos internos de PrestaShop permanecen intactos por debajo. El módulo personaliza los números mostrados en facturas, albaranes de entrega y abonos. Si necesitas personalizar las propias referencias de pedido, la fuente recomienda usar el producto separado Custom Order Numbering.

El módulo de facturas confirma esa división en código: hookActionSetInvoice genera y registra la referencia de factura formateada, pero deja intencionadamente el número de factura almacenado por PrestaShop como numérico/nativo. La cadena formateada mostrada se suministra después mediante actionInvoiceNumberFormatted, y la generación de albarán almacena el valor de contador numérico en order_invoice.delivery_number.

Default invoice format: {DOC_TYPE}/{YYYY}/{NNNNNN}
Default delivery format: {DOC_TYPE}/{YYYY}/{NNNN}
Default credit slip format: {DOC_TYPE}/{YYYY}/{NNNN}

Los valores generados se registran en mprinvoicenumber_number con tipo de documento, IDs de pedido, factura o abono, valor de contador, patrón y número formateado. Eso te da documentos personalizados visibles para el cliente sin cambiar IDs de pedido ni referencias aleatorias de pedido; eso lo gestiona mprordernumber.

El módulo genera un indicador mediante displayProductListReviews. Su JavaScript encuentra la miniatura de producto contenedora e inyecta un badge Bundle en el área de imagen.

La pestaña lista los productos incluidos configurados en una cuadrícula. Cada tarjeta puede mostrar imagen del producto, nombre del producto, precio formateado o FREE para precio cero, y un enlace al producto incluido.

Incluye un helper dispatcher para rutas rewrite-only. Cuando una ruta no tiene ID, puede resolver slugs coincidentes de categoría, producto, CMS o fabricante y actualizar los parámetros de request en consecuencia.

Sí. El formulario admin almacena el flag enabled, y cada hook front termina antes cuando isFeatureEnabled() es false.

La ruta server-side requiere que CAPI esté activado y que haya un Reddit access token configurado. El Events Testing ID es opcional y se usa solo cuando está presente.

No, la fuente describe eventos del navegador y eventos del lado del servidor funcionando en paralelo con IDs de conversión compartidos. La ruta del lado del servidor puede ayudar a reducir huecos cuando el seguimiento del navegador está bloqueado, mientras que el píxel del navegador sigue capturando el comportamiento del cliente. Usar ambos con cuidado da a Reddit señales más completas que usar solo un píxel pegado.

El seguimiento del navegador se prepara en los hooks de cabecera y de confirmación de pedido. El módulo puede emitir eventos como PageVisit, ViewContent, Search, SignUp, InitiateCheckout, eventos puente de tipo add-to-cart y Purchase. Cuando Conversions API está activada, los eventos correspondientes se encolan del lado del servidor con la misma identidad: los parámetros del navegador usan conversionId, mientras que la carga de la API guarda conversion_id en los metadatos del evento.

• Se requiere un Reddit Pixel ID para el seguimiento del navegador.
• Conversions API también requiere un token de acceso, y el módulo envía al endpoint de conversiones de Reddit para el píxel configurado.
• Las comprobaciones de exclusión de empleados y consentimiento de marketing pasan por canTrack() antes de preparar el seguimiento del front office.
• El límite predeterminado de lote de la cola CAPI es 20, mientras que las rutas puente del front y de compra procesan lotes pequeños de inmediato.

La configuración práctica es mantener activo el píxel del navegador para los eventos normales del cliente y usar Conversions API como señal complementaria del lado del servidor, no como sustituto.

El módulo mapea directamente la mayoría de acciones estándar, mientras que InitiateCheckout se envía como evento personalizado de Reddit llamado InitiateCheckout en el mapeo server-side.

Sí. La configuración incluye exclusión de empleados, y la barrera de seguimiento la comprueba antes de construir la salida del pixel front o permitir eventos por la ruta de seguimiento del módulo.

La lista de hooks disponible cubre displayHome, displayFooterCategory, displayLeftColumn, displayRightColumn, displayFooterBefore, displayFooterProduct, displayProductAdditionalInfo, displayOrderConfirmation2 y displayCrossSellingShoppingCart.

Sí, la descripción de la fuente incluye colecciones de productos curadas y widgets dinámicos. Las colecciones seleccionadas a mano son útiles para campañas, merchandising editorial y promociones centradas en el margen. Las fuentes dinámicas son útiles cuando quieres que los más vendidos, las novedades o los productos que vuelven a estar disponibles se mantengan actualizados con menos trabajo manual.

Las colecciones curadas se almacenan por separado de los widgets. La tabla colección-producto guarda id_collection, id_product y position, y setProducts() reescribe esa lista en el orden guardado por el administrador. Después, un widget puede usar el tipo de widget collection y apuntar a la colección elegida.

• Los tipos de colección incluyen curated, staff_picks, seasonal y spotlight.
• Las consultas públicas de colecciones devuelven productos activos de la tienda y conservan el orden colección-producto guardado.
• Si el widget requiere imágenes, el proveedor filtra los productos sin una imagen utilizable.
• Los tipos de widget automáticos con proveedores de productos implementados incluyen bestsellers, new, sale, featured, trending, back_in_stock y cart_recommendations.
• recently_viewed aparece como tipo/etiqueta de widget en el modelo, pero getProducts() todavía no tiene un caso de proveedor para él, así que no debería presentarse como una lista automática funcional hasta que se añada esa implementación.

Esto significa que puedes seleccionar a mano una colección de campaña para la página de inicio o un bloque de página de producto, y seguir usando bloques dinámicos implementados en otras zonas de la misma tienda PrestaShop.

Sí. El modelo del widget guarda hide_products_without_images, y las consultas de producto/el ensamblaje del provider usan esa bandera para exigir una imagen de portada de tienda en muchas fuentes de widget.

El módulo escucha actionUpdateQuantity. Cuando la cantidad de un producto pasa de cero o menos a un valor positivo, inserta una fila en mprshowcaserevolution_stock_change, que puede usar la fuente de productos de nuevo en stock.

Instala y activa el módulo para añadir un botón Ask a question en las páginas de producto de PrestaShop. Se renderiza mediante el hook displayProductAdditionalInfo, abre un formulario modal junto a la información del producto y pasa el nombre del producto, la referencia y el ID de producto a la consulta.

Durante la instalación, el módulo guarda ENABLED=1, define RECIPIENT_EMAIL a partir de PS_SHOP_EMAIL y usa [Product Question] como prefijo de asunto predeterminado. El hook asigna el nombre del producto, la referencia del producto, el ID del producto, la URL AJAX y un valor de token oculto a la plantilla Smarty.

• Hook del front: displayProductAdditionalInfo.
• Endpoint AJAX: module/mpraskaboutproduct/ask.
• Ajustes de administración: interruptor de activación, email del destinatario y prefijo del asunto.

El resultado es un formulario de consulta específico del producto en la página de producto, de modo que el comerciante recibe el mensaje con contexto del producto en lugar de una solicitud de contacto genérica.

Sí, los clientes envían la consulta de producto directamente desde el modal del escaparate. El front controller de PrestaShop recibe el nombre del remitente, email del remitente, mensaje, nombre del producto e ID del producto por AJAX, y luego devuelve un mensaje JSON de éxito o error sin obligar al cliente a abrir un cliente de correo.

La plantilla envía una petición FormData al front controller del módulo y actualiza el modal con la respuesta JSON. Si todo va bien, el formulario se reinicia y el cliente ve el mensaje de éxito; si hay un fallo de validación o de correo, el mismo modal muestra el error devuelto.

• La petición se considera inválida si falta el marcador de envío esperado sender_email.
• El controlador envía al destinatario configurado del módulo o recurre al email de la tienda.
• Si existe la plantilla de correo question del módulo, se usa; de lo contrario, el código recurre a la plantilla principal contact de PrestaShop.

Esto mantiene la consulta dentro del flujo del escaparate de PrestaShop y conserva el nombre del producto y el ID del producto en el cuerpo del email.

Valida la consulta en el front controller AJAX antes de enviar el email. Una petición debe enviar sender_email, y los campos obligatorios son sender_name, sender_email y message. El email se comprueba con Validate::isEmail() de PrestaShop, y el mensaje se comprueba con Validate::isCleanHtml().

POST /module/mpraskaboutproduct/ask sender_name=Alice&sender_email=alice@example.com&message=Can you confirm availability?&id_product=42&product_name=Demo product

• Si falta el marcador de envío sender_email, devuelve {"success":false,"message":"Invalid request."}.
• Si el nombre, email o mensaje están vacíos, devuelve {"success":false,"message":"All fields are required."}.
• Un email inválido devuelve {"success":false,"message":"Invalid email address."}.
• HTML inseguro en el mensaje devuelve {"success":false,"message":"Invalid message content."}.

Si la validación pasa, el módulo envía la consulta al email de destinatario configurado, recurriendo al email de la tienda cuando no hay destinatario del módulo definido.

Después de la validación, el controlador construye el asunto del email a partir del prefijo de asunto configurado más el nombre del producto enviado. El mensaje se escapa y se convierte con nl2br() para la plantilla de email. El nombre del producto y el ID del producto se incluyen en las variables del correo, para que el equipo pueda identificar el artículo sin pedir al cliente que vuelva a enviar detalles.

El modal incluye un campo de token oculto, pero la ruta actual del controlador valida los campos de la petición y el contenido del mensaje en lugar de comprobar ese token. Si se necesita una protección anti-spam más fuerte, añádela alrededor del formulario del front en lugar de asumir que este controlador realiza una comprobación de token CSRF.

Sí, el módulo te permite definir el email de destinatario y el prefijo de asunto para las preguntas de producto. Si no se configura ningún destinatario, el front controller de PrestaShop recurre a la dirección de email de la tienda y luego envía el mensaje con el contexto del producto incluido.

La clase de configuración expone RECIPIENT_EMAIL y SUBJECT_PREFIX. Durante la instalación, RECIPIENT_EMAIL se inicializa desde PS_SHOP_EMAIL, y SUBJECT_PREFIX usa por defecto [Product Question]. En el front controller, un destinatario vacío se sustituye por Configuration::get('PS_SHOP_EMAIL').

Recipient: mpraskaboutproduct.RECIPIENT_EMAIL or PS_SHOP_EMAIL
Subject: SUBJECT_PREFIX + product name

Esto es útil cuando las preguntas de producto deben ir a una bandeja de ventas, al equipo técnico o a un proveedor en lugar de a la dirección principal de contacto de PrestaShop.

Sí. Las reseñas se comprueban antes de guardarse, y las comprobaciones fallidas devuelven un error de validación en lugar de aceptar la reseña en silencio. La fuente incluye estas protecciones:

• Límite por misma IP: cuando MIN_TIME_BETWEEN es mayor que cero, el módulo comprueba si la misma IP ha publicado otra reseña en esa tienda dentro del número de segundos configurado.
• reCAPTCHA: cuando está activado, el módulo verifica con Google el token enviado. Soporta v2 y v3; v3 usa un umbral de puntuación de 0.5. Un token ausente falla la comprobación, mientras que una clave secreta ausente o un problema de verificación de red se trata como no bloqueante.
• Comprobaciones de enlaces y etiquetas: se rechaza el contenido con más de dos URLs, y se bloquea HTML incrustado evidente como <script>, <iframe>, <object>, <embed> y <form>.

La protección de tiempo mínimo es una comprobación de tiempo entre reseñas para la misma IP, no un temporizador de carga del formulario. Para usar reCAPTCHA como protección activa, actívalo y configura la clave del sitio y la clave secreta en los ajustes del módulo.

El flujo de envío más amplio añade más salvaguardas prácticas. Las reseñas requieren un tipo de entidad válido, ID de entidad, contenido de al menos 10 caracteres y una valoración de 1 a 5. Las reseñas de invitados están desactivadas por defecto, y los clientes conectados no pueden reseñar dos veces la misma entidad salvo que la reseña anterior se haya marcado como spam.

• MODERATION usa por defecto 1, así que las nuevas reseñas se guardan como pending salvo que la moderación esté desactivada.
• MIN_TIME_BETWEEN usa por defecto 30 segundos.
• Para reseñas de producto de clientes conectados, el módulo puede marcar una reseña como compra verificada cuando encuentra un pedido válido que contiene ese producto.
• Las subidas de fotos, cuando están activadas, se restringen a JPEG, PNG y WebP, con límites predeterminados de 3 imágenes y 2 MB por imagen.

Aun así, no es un sistema de detección de fraude. El código proporciona limitación de frecuencia, reCAPTCHA, comprobaciones de contenido, prevención de duplicados, marcado de compra verificada y moderación, por lo que los comerciantes deberían mantener la moderación activada cuando la calidad de las reseñas sea importante.

Sí, las reseñas no se limitan a las páginas de producto. El módulo incluye manejo de entidades para reseñas de producto, categoría, CMS y tienda, además de una ruta pública de reseñas, con cada área de visualización controlada por configuración y renderizada mediante hooks o controladores del front office de PrestaShop.

El modelo de datos guarda reseñas con entity_type y entity_id, y el servicio de envío acepta product, category, cms y store como tipos de entidad válidos. La página de ajustes tiene interruptores separados para PRODUCT_REVIEWS, CATEGORY_REVIEWS, CMS_REVIEWS y STORE_REVIEWS; en los valores actuales, solo las reseñas de producto están activadas por defecto.

La integración automática en página de producto es la ruta más completa en el código inspeccionado: las reseñas de producto se renderizan mediante displayProductExtraContent, las estrellas en listados mediante displayProductListReviews, y la insignia de valoración del producto mediante hooks de página de producto. La página pública de reseñas se expone como /reviews y puede filtrar reseñas aprobadas por type=product, category, cms o store.

Allowed entity types: product, category, cms, store
Public route: /reviews
Filtered examples: /reviews?type=category or /reviews?type=store

Para la colocación en categorías, CMS y tienda, planifica cuidadosamente la ubicación en el front office. La fuente soporta esos registros de reseña y el centro de reseñas, pero las páginas de producto tienen la cobertura de hooks integrada más fuerte en los archivos inspeccionados.

Sí, los recordatorios pueden crearse después de que un pedido alcance el estado entregado configurado. El hook de estado de pedido de PrestaShop programa recordatorios solo cuando la función de recordatorios está activada, y el módulo guarda filas de recordatorio con datos de pedido, cliente, retraso y estado de reseña.

Más concretamente, el hook inspeccionado escucha actionOrderStatusPostUpdate y comprueba si el nuevo estado de pedido de PrestaShop tiene activada su bandera delivery. Cuando REMINDERS_ENABLED está activo, carga los productos del pedido y crea una fila de recordatorio por producto mediante ReviewReminder::createForOrder().

• REMINDERS_ENABLED usa por defecto 0.
• REMINDER_DELAY_DAYS usa por defecto 7.
• Se omiten filas duplicadas para el mismo pedido y producto.
• Se omiten los productos ya reseñados por ese cliente.
• Cada fila de recordatorio guarda un token de 64 caracteres y un estado como pending, sent o reviewed.

El modelo también incluye helpers para encontrar recordatorios pendientes después del retraso configurado, marcar recordatorios como enviados, marcarlos como reseñados y cargar un recordatorio por token. En los archivos inspeccionados encontré la programación y el modelo de datos, pero no un flujo cron completo de envío de emails que llame a esos métodos helper.

Sí, el módulo incluye gestores de reseñas externas para Google Business Profile y Trustpilot. Cuando se configuran las credenciales de API requeridas, las reseñas externas pueden sincronizarse en tablas locales de reseñas externas y luego mostrarse o agregarse según los ajustes del módulo de PrestaShop.

La tabla de reseñas externas guarda fuente, ID de reseña de la fuente, autor, título, contenido, valoración, URL de la fuente, fecha de publicación, idioma, ID de producto opcional, ID de tienda, datos API sin procesar y marcas temporales de sincronización. Una clave única sobre source más source_review_id evita importaciones duplicadas cuando se vuelve a obtener la misma reseña.

• La sincronización de Trustpilot requiere EXT_TRUSTPILOT_ENABLED, una clave API y Business Unit ID. El proveedor también tiene una alternativa de importación CSV para exportaciones de Trustpilot.
• La sincronización de Google Business Profile requiere EXT_GOOGLE_ENABLED, JSON de cuenta de servicio que contenga client_email y private_key, además de Account ID y Location ID.
• El controlador cron se ejecuta en /module/mprcomments/cron?token=EXT_CRON_TOKEN&action=sync y devuelve resultados de sincronización por fuente como JSON.
• Las reseñas externas de empresa pueden mostrarse en páginas de producto, cargarse de forma diferida por defecto y contarse opcionalmente en insignias de valoración de producto cuando la agregación externa está activada.

Por seguridad SEO, el renderizador de schema usa reseñas nativas de producto para los datos estructurados Product. Las reseñas de empresa importadas pueden mostrarse a los compradores, pero los comentarios de la fuente las mantienen explícitamente fuera del marcado de reseñas de producto salvo que el comerciante tenga reseñas nativas de producto.

No, los proyectos enviados no se publican automáticamente por defecto. En PrestaShop, el ajuste auto_approve usa por defecto 0, así que los nuevos proyectos se guardan como pendientes y las consultas de la galería pública usan el estado de proyecto aprobado antes de mostrarlos.

El controlador de envío requiere autenticación de cliente y un token de seguridad válido antes de crear un proyecto. Valida el título del proyecto, exige al menos una imagen subida y aplica el límite configurado de número de imágenes antes de guardar el proyecto. Los ajustes de imagen predeterminados son max_images=20 y max_image_size_mb=5.

Default: auto_approve=0
Submitted project status: pending
Public gallery status filter: approved

• Si auto_approve sigue desactivado, el cliente es redirigido a My Projects después del envío y el proyecto espera moderación.
• Si auto_approve está activado, el mismo flujo de envío guarda el nuevo proyecto con estado approved.
• La lista de administración de proyectos soporta acciones masivas de aprobar, rechazar, destacar y eliminar.
• El controlador público de proyecto devuelve un 404 para proyectos no aprobados salvo que una sesión de vista previa de administrador sea válida.

Para la mayoría de tiendas, dejar la aprobación automática desactivada es el valor predeterminado más seguro, porque los títulos, descripciones y fotos enviados por clientes se revisan antes de aparecer en el escaparate público.

Sí, los administradores pueden añadir pines de producto a imágenes del escaparate. En PrestaShop cada pin guarda coordenadas x e y de la imagen, una etiqueta y IDs de producto de respaldo ordenados, y luego resuelve un producto activo y con stock para la visualización pública del proyecto.

El controlador de pines de administración añade, actualiza, elimina y carga pines mediante AJAX JSON. Las coordenadas deben estar entre 0 y 100 y se redondean a dos decimales. Los IDs de productos de respaldo se normalizan, se deduplican y se guardan como JSON, con el primer ID escrito también en el campo heredado id_product.

Pin fields: id_showcase_image, id_product, product_fallback_ids, x_percent, y_percent, label, position
Resolution order: first active in-stock product, then first active product

• La búsqueda de productos en administración devuelve productos activos por nombre, referencia o ID de producto, limitada a 20 resultados.
• En la página pública del proyecto, los pines se enriquecen con URL del producto, imagen de portada y precio formateado.
• El endpoint AJAX de pines del front también puede renderizar la plantilla de miniatura de producto del tema cuando está disponible.
• Si todos los productos de respaldo están inactivos, el pin mantiene su posición pero no resuelve ningún producto.

Esto permite al comerciante convertir una imagen de galería de cliente en un lookbook comprable, manteniendo una lista de respaldo para productos sin stock o desactivados.

Sí, se evitan votos duplicados del mismo cliente en un proyecto. En PrestaShop la tabla de votos tiene una clave única por proyecto y cliente, y el modelo actualiza el voto existente en lugar de insertar otra fila.

Sí. Una página de proyecto de Customer Showcase que no sea vista previa puede generar JSON-LD cuando el controlador de proyecto tiene suficientes datos para construirlo. El controlador recopila el título del proyecto, una meta descripción de página resuelta, la URL canónica del proyecto, URLs de imágenes grandes del escaparate y el nombre de la categoría, y luego la plantilla del front imprime el JSON en un script application/ld+json cuando project_schema_json no está vacío.

{"@context":"https://schema.org","@type":"ImageGallery","name":"Bathroom renovation","description":"Short project summary","url":"https://shop.example/showcase/bathroom-renovation","mainEntityOfPage":"https://shop.example/showcase/bathroom-renovation","image":["https://shop.example/img/showcase/large/photo.jpg"],"about":"Bathrooms"}

El tipo de schema usado por el módulo es ImageGallery, por lo que describe la galería de proyecto del cliente en lugar de afirmar un schema separado de producto, servicio o reseña.

El controlador omite deliberadamente el schema en modo vista previa: las páginas de vista previa reciben un valor project_schema_json vacío y el helper de vista previa aplica manejo noindex. En páginas normales de proyecto, las URLs de imágenes grandes se construyen desde img/showcase/large/ usando el dominio SSL de la tienda y el URI base, así que los datos estructurados apuntan a URLs absolutas de imagen en lugar de a los archivos thumbnail o medium usados en otras partes de la página.

• Fuente de la descripción: el JSON-LD usa la meta descripción de página resuelta. Es la meta descripción guardada del proyecto cuando existe; de lo contrario, el controlador genera una descripción de customer-showcase basada en el título. La descripción del proyecto limpiada y truncada es solo un último recurso dentro de buildProjectSchema() si la meta descripción resuelta sigue vacía.
• Campos opcionales: image se incluye solo cuando existen imágenes de proyecto, y about se incluye solo cuando el proyecto tiene nombre de categoría.
• Seguridad de salida: el JSON se genera con json_encode(..., JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) y recurre a Tools::jsonEncode() si hace falta, luego Smarty imprime ese JSON preparado sin filtrar dentro del script JSON-LD.

No. El módulo solo implementa el código de Google Customer Reviews en el lado de PrestaShop; no contiene ningún código que pueda inscribir, aprobar o hacer elegible una tienda en Google Merchant Center. Necesitas que el programa Google Customer Reviews esté disponible para la tienda en Merchant Center, un Merchant ID numérico y datos de pedido que Google acepte para la invitación a la encuesta.

Lo que el módulo puede controlar es la implementación en el escaparate una vez que existen esos requisitos: guarda el Merchant ID, carga la invitación de encuesta de Google en la página de confirmación de pedido, envía el ID de pedido, email del cliente, país de entrega, fecha estimada de entrega y valores GTIN de producto del pedido, y renderiza la insignia de valoración en la posición configurada.

El envío de encuestas, la aprobación del programa, el cálculo de seller rating y cómo aparecen las valoraciones en las propiedades de Google siguen bajo control de Google. El módulo puede hacer que aparezcan el código de invitación y la insignia, pero no puede aprobar la tienda ni obligar a Google a mostrar valoraciones.

Al instalarse, el módulo empieza desactivado con MERCHANT_ID vacío, una posición predeterminada de insignia BOTTOM_RIGHT e idioma de insignia en. La guarda del escaparate requiere tanto ENABLED como un Merchant ID no vacío, así que un módulo instalado pero sin configurar no generará el código de invitación ni de insignia.

• Invitación en confirmación de pedido: el hook se ejecuta solo para un pedido cargado, usa el email del cliente del pedido, lee el país de entrega desde la dirección de entrega, usa una fecha estimada de entrega simple de hoy más siete días y pasa el ean13 de cada producto pedido como valor GTIN.
• Insignia: el hook de cierre del body renderiza la insignia de valoración de Google con el ID de comerciante configurado y una de las posiciones soportadas, como BOTTOM_RIGHT, BOTTOM_LEFT o INLINE.
• Límite: si los productos no tienen valor EAN13, el módulo sigue enviando la entrada de producto con un GTIN vacío; si Google acepta o usa esos datos de producto se gestiona fuera de PrestaShop.

No automáticamente. El módulo ofrece vista previa e historial, pero la fuente no contiene un rollback de un clic que restaure todos los productos a su precio anterior. Antes de aplicar una actualización masiva, usa la vista previa para revisar los IDs de producto afectados, el precio actual, el nuevo precio calculado y la diferencia.

• Antes de aplicar: exporta o haz una copia de seguridad de los IDs de producto afectados y del campo de precio que vas a cambiar, especialmente si estás actualizando un alcance amplio como todos los productos, una categoría o un fabricante.
• Después de aplicar: el módulo escribe una entrada de registro con la fórmula, alcance, campo de precio, número de afectados, empleado y fecha.
• Si necesitas deshacer: usa el registro para identificar la ejecución y luego restaura desde tu copia/exportación. Aplicar la fórmula inversa puede ser arriesgado porque el redondeo, las ediciones posteriores de precio y los cambios de alcance de producto pueden hacer que el cálculo inverso difiera de los valores originales.

Para cambios de alto riesgo, ejecuta la vista previa, exporta el mismo conjunto de productos y aplica la actualización en un periodo tranquilo para que cualquier corrección pueda hacerse desde valores de origen conocidos.

La vista previa y la actualización real usan el mismo helper de cálculo, así que los números que previsualizas se basan en las mismas acciones de fórmula que luego se aplican: increase_percent, decrease_percent, increase_fixed y decrease_fixed. Las reducciones porcentuales y fijas se limitan a cero, y los precios calculados se redondean a seis decimales antes de escribirse.

increase_percent:10 => current price * 1.10; decrease_fixed:5 => max(0, current price - 5)

Al aplicarse, el módulo actualiza tanto product como product_shop para el campo seleccionado, y solo soporta price o wholesale_price. El selector de alcance puede apuntar a todos los productos activos o a productos activos de una categoría, fabricante o proveedor seleccionado; los productos inactivos no se seleccionan en las consultas de alcance.

El hook permite URLs que contienen module/mprpasswordprotect o module-mprpasswordprotect, y también retorna cuando el parámetro module del request coincide con el nombre del módulo.

La clase de configuración expone activar protección por contraseña, contraseña, mensaje, bypass de empleado/mantenimiento y switches noindex mediante el formulario OptionsManager.

Sí. La instalación crea una página meta no configurable para module-mprpasswordprotect-gate con título Password Required y URL rewrite password.

El controlador gate establece un flag de error y vuelve a renderizar el mismo template de contraseña, que muestra el mensaje traducido Incorrect password. Please try again..

No. El controlador de reenvío envía el email de confirmación de pedido reconstruido y registra un mensaje privado, pero no llama a ninguna lógica de cambio de estado de pedido.

Antes de enviar, el controlador AJAX exige un ID de pedido y un token del módulo, valida ambos, carga el pedido y el cliente, y luego llama a Mail::Send() estándar de PrestaShop con la plantilla order_conf desde _PS_MAIL_DIR_ y el ID de tienda original del pedido.

• Productos: reconstruye filas de producto en HTML y texto plano desde $order->getProducts(), incluyendo nombre del producto, referencia opcional, cantidad, precio unitario con impuestos y precio total con impuestos.
• Direcciones: los bloques de entrega y factura se generan con AddressFormat::generateAddress(), con una alternativa construida desde empresa, nombre, calle, código postal y ciudad si falla el formato de dirección.
• Pista de auditoría: después de un reenvío correcto añade un mensaje privado al pedido y escribe una entrada de log de PrestaShop; si falla el envío del correo, devuelve un error JSON en lugar de cambiar el estado del pedido.

El módulo envía la plantilla estándar de PrestaShop order_conf mediante Mail::Send, después de reconstruir filas de productos, direcciones, totales, transportista y valores de pago desde el pedido.

Tras un envío correcto, el módulo crea un mensaje privado de pedido indicando que la confirmación se reenvió, incluyendo el email del destinatario y la marca de tiempo.

El módulo debe estar activado y PHONE_NUMBER debe estar definido. Su validador de configuración obligatoria espera solo dígitos y un signo más inicial opcional, por ejemplo +1234567890.

Sí. El trait de chat compartido admite filtros de página all, product, category y checkout mediante el ajuste PAGES.

No. La plantilla renderizada crea un enlace normal a Signal y usa CSS local del módulo más SVG inline para el botón. No hay ningún cargador JavaScript externo de Signal en la plantilla del hook.

Si DELAY es mayor que cero, la plantilla oculta inicialmente el widget y usa un timeout para mostrarlo después del número de segundos configurado.

El módulo guarda la elección de visualización del visitante en la cookie ligera mpr_tax_display y, al inicio del front controller, prepara la caché de visualización de precios por grupo de PrestaShop para que los cálculos de precios de producto se rendericen con impuestos incluidos o excluidos para esa petición. No actualiza carritos, pedidos, reglas fiscales, facturas ni grupos de clientes en la base de datos.

En páginas de producto/listado también inyecta datos ocultos .mpr-tax-prices con precios formateados con y sin impuestos, para que JavaScript pueda intercambiar los precios visibles inmediatamente. Si una página no tiene datos de precio de producto inyectados, como algunas páginas de carrito o checkout, el script guarda la preferencia y recarga para que PrestaShop renderice la página con el modo de visualización elegido.

El total del checkout y el importe de impuestos siguen siendo calculados por PrestaShop a partir del carrito, dirección, reglas fiscales y flujo normal de checkout. Este módulo afecta a la preferencia de visualización y etiquetas de precio, no al cálculo fiscal.

Activa el módulo para renderizar un botón fijo de volver arriba en el escaparate de PrestaShop. El código genera el botón desde hooks de footer/cierre de body, evita el renderizado duplicado cuando ambos hooks están disponibles e incluye el CSS y JavaScript necesarios para el botón.

Después de la instalación, los valores predeterminados son activado, mostrar después de 300 píxeles, estilo circle y posición right. El módulo registra displayFooter, displayFooterAfter y displayBeforeBodyClosingTag; el primer hook compatible que renderice tu tema generará el botón, y las llamadas posteriores a hooks devuelven una cadena vacía porque buttonRendered ya está definido.

La plantilla crea un único botón fijo con ID mprb2t-btn, una etiqueta/título accesible, un SVG inline de flecha hacia arriba y CSS/JavaScript inline. No hay regla de producto, categoría o página en este módulo, así que activarlo hace que el botón esté disponible allí donde el tema ejecute uno de esos hooks de footer/cierre de body.

Sí, puedes definir la distancia de scroll antes de que aparezca el botón. La configuración de PrestaShop guarda un valor Show After en píxeles, y el JavaScript del escaparate compara ese umbral con window.pageYOffset antes de añadir o quitar la clase visible del botón.

El umbral predeterminado es 300 píxeles, y el campo de administración se guarda como SHOW_AFTER. El valor se asigna a Smarty como mprb2t_show_after y se convierte en la variable JavaScript threshold en la plantilla.

if (window.pageYOffset > threshold) { btn.classList.add('mprb2t-visible'); } else { btn.classList.remove('mprb2t-visible'); }

El listener de scroll se registra como pasivo y toggleBtn() también se ejecuta una vez inmediatamente después de cargar el script, por lo que el estado del botón es correcto incluso cuando un comprador aterriza en una página con ancla o vuelve a una posición ya desplazada.

Sí, el módulo soporta las opciones de estilo presentes en su configuración: forma circular o cuadrada y posición izquierda o derecha en pantalla. La plantilla de PrestaShop aplica esos valores a CSS inline; el código no incluye selector de color ni reglas de segmentación por página.

Los valores instalados por defecto son STYLE=circle y POSITION=right. En la plantilla, POSITION=left escribe left: 30px; cualquier otro valor configurado sigue la rama derecha y escribe right: 30px. Para la forma, STYLE=circle escribe border-radius: 50%, mientras que la opción cuadrada usa un radio pequeño de 6px.

• Dimensiones fijas: el botón mide 48 por 48 píxeles, está fijado en la parte inferior del viewport y usa z-index: 9999.
• Colores integrados: la plantilla usa fondo oscuro, color de icono blanco y un estado hover más oscuro. Esos valores están hardcodeados en la plantilla actual.
• Límite práctico: no hay ajuste para elección de icono, posición por dispositivo, duración de animación o colores personalizados en la clase de configuración.

Sí, al hacer clic en el botón la página se desplaza suavemente hasta arriba. El script del escaparate de PrestaShop escucha el clic del botón, evita la acción predeterminada y llama a window.scrollTo con top establecido en 0 y behavior establecido en smooth.

El manejador de clic es pequeño y directo: se vincula al botón generado mprb2t-btn, llama a e.preventDefault() y luego pide al navegador que se desplace hasta arriba usando el desplazamiento suave nativo.

window.scrollTo({ top: 0, behavior: 'smooth' });

Como el módulo usa el comportamiento nativo scrollTo del navegador en lugar de un bucle de animación personalizado, se mantiene ligero y no guarda ningún estado de scroll. El botón solo se vuelve visible después de superar el umbral configurado; hacer clic en él no recarga la página ni cambia la URL.

Usa MPR Compare para añadir una lista de comparación del lado del cliente a PrestaShop. Los IDs de productos seleccionados se guardan en localStorage del navegador bajo la clave mprcompare, mientras que el módulo solo consulta detalles de producto por AJAX cuando la página de comparación o las miniaturas flotantes necesitan datos.

El comentario de cabecera del propio módulo describe el diseño como cero almacenamiento en base de datos y cero cookies para la interacción en páginas de listado. Los hooks de lista de productos y página de producto generan botones estáticos con un atributo data-id-product; el script del navegador añade o elimina esos IDs de localStorage y actualiza localmente el estado de los botones, contadores y barra flotante.

El servidor solo interviene cuando se necesitan datos reales del producto. La página de comparación lee los IDs desde localStorage y los envía al front controller actions con action=getProducts, mientras que las miniaturas flotantes llaman a action=getProductImage. Vaciar la lista de comparación simplemente guarda un array vacío de nuevo en localStorage.

La tabla de comparación puede mostrar el nombre del producto, URL, imagen de portada, precio actual, precio anterior, descripción corta, referencia, fabricante, peso, estado de stock, características, condición y EAN13 cuando esos valores existen. El controlador AJAX omite productos inactivos de PrestaShop.

Los datos vienen de objetos Product cargados en el idioma y la tienda actuales. Los precios se formatean desde Product::getPriceStatic() con impuestos activados; el precio anterior solo se devuelve cuando el precio sin reducción es mayor que el precio actual. Las imágenes de portada usan medium_default para la tabla de comparación y cart_default para el endpoint de miniatura flotante.

• Características: el controlador llama a getFrontFeatures() y devuelve cada par nombre/valor de característica, mientras que el script del front agrupa nombres de característica únicos en filas de comparación.
• Disponibilidad: el estado de stock se devuelve desde Product::getQuantity($idProduct) > 0, así que es un indicador simple de con stock/sin stock.
• Datos ausentes: campos opcionales como fabricante, referencia, peso, EAN13 y precio anterior quedan vacíos o se omiten en la tabla cuando PrestaShop no tiene valor para ellos.

Sí, el tamaño máximo de comparación es configurable. El ajuste MAX_ITEMS usa por defecto cuatro en la instalación, el script del front rechaza añadir más artículos cuando se alcanza el límite, y el endpoint AJAX de productos recorta los IDs entrantes al mismo máximo configurado.

Al instalar, MAX_ITEMS se crea con el valor 4; el controlador de administración lo guarda con un mínimo de 1. Ese valor se envía al navegador en mprCompareConfig.maxItems y también se asigna a la plantilla de la página de comparación como maxItems.

var max = config.maxItems || 4;

La prevención de duplicados también es del lado del cliente: si el producto ya está en localStorage, la función de añadir vuelve sin agregarlo de nuevo. El endpoint AJAX aun así recorta la lista de IDs solicitada al máximo configurado, por lo que una petición editada manualmente no puede hacer que la página de comparación cargue más productos que el límite configurado.

Sí, añade controles de comparación mediante hooks de PrestaShop. El módulo renderiza botones en listas de productos y páginas de producto, un contador de navegación y una barra flotante opcional de comparación con miniaturas de producto, controles de eliminación y enlace a la página de comparación.

Para PrestaShop 1.7 y versiones más nuevas, el módulo registra hooks de medios, página de producto, navegación y cierre de body; para temas antiguos 1.6 usa los hooks heredados de header, botón de producto, nav y footer. Los botones de listado de productos son enlaces estáticos con js-mprcompare-toggle, los controles de página de producto son botones, y ambos usan el mismo valor data-id-product para el gestor de lista de JavaScript.

La barra flotante se controla con el ajuste SHOW_FLOATING, activado por defecto. Cuando hay productos seleccionados, el script muestra la barra, carga datos de miniatura por AJAX si no están ya en caché, renderiza botones de eliminación para productos individuales y mantiene sincronizados el contador de cabecera y el contador flotante con el número de IDs en localStorage.

Los clientes pueden enviar solicitudes de funciones desde la pestaña de la página de producto cuando el módulo y la visualización en producto están activados. En PrestaShop, el controlador AJAX valida token, producto, título, descripción y campos de identidad de invitado, y luego limita los envíos por producto e IP.

La pestaña de producto solo se añade cuando ENABLED y SHOW_ON_PRODUCT están activos y el módulo puede resolver el ID del producto. La pestaña empieza como un resumen/lista diferida, y el script del front solicita la primera página de elementos cuando la pestaña se vuelve visible, usando el valor configurado REQUESTS_PER_PAGE, que por defecto es 10.

• Seguridad: las acciones de escritura requieren un token CSRF desde Tools::getToken(false). JavaScript obtiene un token con action=getToken si el marcado inicial de la pestaña todavía no contiene uno.
• Validación: el título debe tener al menos 5 caracteres, la descripción al menos 10 caracteres, los invitados deben proporcionar un nombre y email válido, y los clientes conectados usan automáticamente el nombre y email de su cuenta.
• Límite de frecuencia: el controlador permite como máximo 3 envíos para el mismo producto y dirección IP durante el día anterior.
• Datos guardados: la solicitud registra producto, identidad de cliente o invitado, texto de descripción limpiado, tienda, idioma, dirección IP, estado, marcas temporales y un recuento inicial de votos de 1.

Sí, las solicitudes pueden requerir login de cliente y aprobación de administrador. En PrestaShop, REQUIRE_LOGIN bloquea el envío de invitados, REQUIRE_APPROVAL guarda nuevas solicitudes como submitted, y las listas públicas ocultan elementos submitted a quienes no son sus autores hasta que pasen a un estado público.

Los valores predeterminados son cómodos para el comerciante: REQUIRE_LOGIN está desactivado, pero REQUIRE_APPROVAL está activado. Con aprobación activada, el controlador guarda nuevos elementos como submitted; sin ella, los nuevos elementos empiezan como under_review.

La visibilidad se gestiona en el modelo, no solo en la plantilla. Las listas normales de producto excluyen tanto declined como submitted, y luego vuelven a añadir elementos submitted solo cuando el visor actual coincide con el autor por ID de cliente o dirección IP. La consulta de roadmap público indexable también excluye submitted y declined, así que las ideas pendientes no se convierten en contenido SEO público.

Para quien envía la solicitud, JavaScript puede mostrar un aviso pendiente: Your request is pending review and only visible to you. Eso deja claro el flujo de aprobación sin exponer solicitudes sin revisar a otros compradores.

Sí, la votación puede activarse y la votación de invitados puede permitirse o bloquearse. En PrestaShop, el endpoint de voto alterna un voto por solicitud, usa ID de cliente o seguimiento basado en IP y devuelve un requisito de login cuando la votación de invitados está desactivada.

La votación está activada por defecto, mientras que la votación de invitados está desactivada por defecto. Cuando la votación de invitados está desactivada y el visitante no ha iniciado sesión, la respuesta AJAX incluye require_login, y el script del front redirige al enlace de inicio de sesión cuando existe.

El almacenamiento de votos es una tabla separada mprfeaturerequest_vote. Los votantes conectados se emparejan por id_customer; los invitados, cuando se permiten, se emparejan por dirección IP. Llamar de nuevo al endpoint alterna el voto a desactivado eliminando la fila existente, mientras que un voto nuevo inserta una fila y marca el estado devuelto voted como true.

Después de cada cambio, el módulo recalcula el contador de la solicitud incrementando o reduciendo vote_count con una actualización de base de datos que usa GREATEST(0, ...), así que el recuento mostrado no puede bajar de cero. Las solicitudes recién enviadas también reciben un voto automático del propio autor, por eso el recuento inicial empieza en 1.

Sí, el hub principal de roadmap puede ser indexable cuando el módulo Feature Requests está activado, la página de roadmap está activada y el ajuste INDEX_ROADMAP_PAGE permite la indexación. Las páginas de detalle, las páginas de roadmap específicas de producto y los endpoints AJAX se mantienen deliberadamente fuera del índice.

• URL limpia del hub de roadmap, por ejemplo /feature-requests: el tipo de página roadmap usa la política SEO del módulo. Cuando la indexación está activada, robots se resuelve como index, follow.
• Hub de roadmap con parámetros de filtro/ordenación compatibles, por ejemplo /feature-requests?status=planned: el controlador redirige con 301 estos (status, sort, view, search, page) de vuelta al hub canónico /feature-requests, para que los duplicados nunca se indexen. Cualquier otra cadena de consulta no redirigida se renderiza como noindex, follow.
• Página específica de producto, por ejemplo /feature-requests/module/my-product: el tipo de página module está configurado como no indexable, por lo que robots se resuelve como noindex, follow.
• Página de detalle de solicitud, por ejemplo /feature-requests/some-request: el tipo de página detail está configurado como no indexable, por lo que robots se resuelve como noindex, follow. Las respuestas 404 de detalle también envían X-Robots-Tag: noindex, nofollow, noarchive.
• Endpoint AJAX, por ejemplo module/mprfeaturerequest/ajax: el controlador envía X-Robots-Tag: noindex, nofollow, noarchive.

El hook del sitemap sigue la misma lógica: solo añade la URL del hub de roadmap cuando el módulo, la visualización de roadmap, la inclusión en el sitemap y la política SEO lo permiten.

La ruta de código se limita a renderizar el widget de JivoChat desde displayBeforeBodyClosingTag. Comprueba que el módulo esté activado, que exista un WIDGET_ID, que la página actual coincida con el filtro de páginas configurado y que la visualización móvil esté permitida cuando el visitante está en móvil.

Cuando renderiza, la plantilla inyecta el script externo de JivoChat desde //code.jivosite.com/widget/{widget_id}, opcionalmente después del retraso configurado. Si PASS_USER_DATA está activado y el cliente ha iniciado sesión, define jivo_onLoadCallback() y llama a jivo_api.setContactInfo() con el nombre y email del cliente.

No hay tabla, modelo ni controlador del módulo para mensajes o transcripciones de chat en esta fuente. Eliminar o desactivar el módulo de PrestaShop deja de incrustar el widget, pero no exporta, elimina ni gestiona el historial de conversaciones guardado por JivoChat.

hookPaymentOptions() muestra Pay by Invoice solo cuando todas las comprobaciones de elegibilidad se cumplen. El módulo debe estar activo, el ajuste del módulo debe estar activado, el carrito debe pertenecer a un cliente conectado y el objeto cliente debe cargarse correctamente.

• Comprobación de cliente: los carritos de invitados y los registros de cliente inválidos no devuelven opción de pago.
• Comprobación de grupo: el cliente debe pertenecer al menos a un grupo asignado a una condición de pago activa.
• Comprobación de plazo: solo se devuelven condiciones activas enlazadas mediante mpr_payment_term_group, ordenadas por posición y días.
• Comprobación de crédito: el módulo toma el límite de crédito más alto de los grupos del cliente; 0 significa ilimitado. De lo contrario, los pedidos diferidos impagados más el total del carrito actual deben mantenerse dentro del límite.
• Comprobación de validación: el controlador de validación del front repite la comprobación de plazo y crédito antes de crear el pedido, así que una opción de checkout obsoleta no puede saltarse las reglas.

Si alguna comprobación falla, el módulo devuelve una lista vacía de opciones de pago y PrestaShop simplemente no ofrece Pay by Invoice para ese carrito.

Las condiciones disponibles se calculan a partir de los grupos del cliente en el carrito actual. El servicio consulta condiciones activas unidas mediante mpr_payment_term_group, usa el idioma actual para el nombre y la descripción de la condición, y ordena el resultado por position y luego por days. Las condiciones predeterminadas creadas al instalar incluyen Due on Receipt, Net 15, Net 30, Net 60 y Net 90.

La plantilla de checkout renderiza entonces cada condición disponible como una opción de radio, con la primera condición seleccionada, su insignia de color, texto de días hasta vencimiento y descripción opcional. Si el límite de crédito no es ilimitado, también muestra el crédito disponible y el importe diferido pendiente antes de la lista de condiciones.

Cuando el cliente envía la opción de pago, el controlador de validación lee el mpr_pt_term_id seleccionado, recalcula el total del carrito, vuelve a llamar a canPlaceDeferredOrder(), crea el pedido de PrestaShop en el estado configurado OS_AWAITING, recurriendo a bankwire si falta, y luego crea un registro mpr_deferred_order con el importe, cliente, tienda y fecha de vencimiento basada en los días de la condición seleccionada.

La fecha de vencimiento se calcula sumando el número de días de la condición seleccionada a la fecha en que se crea el pedido diferido. Las condiciones instaladas por defecto incluyen Due on Receipt / Net 0, Net 15, Net 30, Net 60 y Net 90.

• Si el pedido se crea el 2026-06-17 con Net 0, la fecha de vencimiento es 2026-06-17.
• Si el pedido se crea el 2026-06-17 con Net 15, la fecha de vencimiento es 2026-07-02.
• Si el pedido se crea el 2026-06-17 con Net 30, la fecha de vencimiento es 2026-07-17.

El módulo guarda el resultado como fecha en formato Y-m-d, no como una marca temporal con hora del día. El cálculo usa la fecha actual de ejecución del servidor/tienda en PHP cuando se crea el pedido diferido, así que los pedidos realizados cerca de medianoche siguen el límite de fecha del servidor en lugar del reloj local del cliente. Los cambios de horario de verano no añaden una hora a la fecha de vencimiento guardada, pero pueden importar indirectamente si el pedido se crea alrededor de un cambio de fecha.

En el checkout, el cliente selecciona una condición de pago mediante mpr_pt_term_id. El módulo valida que la condición esté activa, pertenezca a uno de los grupos del cliente y encaje en el límite de crédito efectivo del cliente antes de crear el pedido de PrestaShop. Solo después de validar el pedido crea el registro de pago diferido con la condición seleccionada, el total del pedido con impuestos y la fecha de vencimiento calculada.

$dueDate = date('Y-m-d', strtotime('+' . (int) $term->days . ' days'));

El valor guardado se copia en mpr_deferred_order.due_date en el momento del pedido. Cambiar después el número de días de una condición de pago no recalcula las fechas de vencimiento de pedidos ya existentes. Las comprobaciones de vencido comparan la fecha de vencimiento guardada con la fecha actual del servidor, así que una factura impagada que vence hoy sigue venciendo hoy; solo pasa a estar vencida después de que esa fecha haya pasado.

El valor de límite de crédito es por grupo de clientes, no por cliente individual. El módulo guarda límites en mpr_pt_credit_limit, donde id_group es la clave primaria, y las propias condiciones de pago también se asignan a grupos mediante mpr_payment_term_group.

Para un cliente en varios grupos, el servicio obtiene todos los grupos del cliente y usa MAX(credit_limit) entre ellos. Ejemplo: si Ana pertenece a Retail sin límite configurado, B2B Silver con 1000.00 y B2B Gold con 2500.00, su límite de crédito efectivo es 2500.00.

Un límite configurado de 0 se trata como ilimitado por el servicio de checkout. Cuando existe un límite real, el módulo resta los pedidos diferidos pendientes de ese cliente en la tienda actual y solo muestra condiciones Pay by Invoice cuando outstanding + cart total se mantiene dentro del límite efectivo del grupo.

Los límites de crédito y la disponibilidad de condiciones están relacionados, pero son independientes. Asignar un límite de grupo no hace por sí mismo que todas las condiciones de pago estén disponibles; la condición también debe estar activa y asignada al menos a uno de los grupos del cliente. Del mismo modo, asignar una condición a un grupo sin un límite de crédito real significa que el grupo puede usar la condición siempre que el límite efectivo se resuelva como ilimitado o que otro grupo aporte suficiente límite.

El importe pendiente se calcula a partir de filas impagadas en mpr_deferred_order para el mismo cliente y tienda actual. Se excluyen las filas ya marcadas como pagadas, y el total del carrito usado para el nuevo pedido es el total del pedido con impuestos. Si el cliente supera el límite efectivo, el servicio de checkout elimina todas las condiciones diferidas de las opciones de pago disponibles y el controlador de validación rechaza un pago diferido enviado aunque alguien publique la condición manualmente.

La instalación crea un estado de pedido llamado Awaiting Deferred Payment, guarda su ID en OS_AWAITING, y el controlador de validación usa ese estado cuando llama a validateOrder() para pedidos Pay by Invoice. Si el estado guardado falta, el controlador recurre al estado de transferencia bancaria de PrestaShop.

• logable = true significa que PrestaShop trata el pedido como un pedido válido realizado para flujos de historial y estadísticas, aunque el pago siga pendiente.
• invoice = true y pdf_invoice = true significan que la generación de factura está activada para el estado de pedido diferido.
• paid = false significa que el estado del pedido no marca el pedido como pagado; el módulo rastrea la liquidación por separado en mpr_deferred_order.is_paid.

Cuando se crea el registro diferido, is_paid empieza en 0. El método markAsPaid() del modelo de pedido diferido establece después is_paid en 1 y registra paid_date, sin cambiar el significado del estado inicial del pedido.

El estado instalado pertenece al módulo, usa la etiqueta Awaiting Deferred Payment en todos los idiomas y se crea con send_email = false, unremovable = false y un valor de color azul. La página de retorno de pago puede mostrar entonces la condición de pago seleccionada, el importe debido y la fecha de vencimiento mientras el pedido permanece impagado desde el punto de vista del estado de pago de PrestaShop.

Hay un seguimiento importante en back office: cuando un administrador marca un pedido diferido como pagado mediante el controlador de pedidos diferidos del módulo, el módulo actualiza primero mpr_deferred_order. Si el pedido de PrestaShop relacionado sigue en el estado de espera del módulo y existe el estado estándar pagado PS_OS_PAYMENT, también mueve el pedido de PrestaShop a ese estado pagado. Si el pedido ya se ha movido a otro estado, el módulo no sobrescribe ese estado a ciegas.

Una notificación real se construye desde pedidos válidos de PrestaShop en la tienda actual, limitada por la antigüedad máxima de pedido configurada y las reglas de inclusión o exclusión de producto. Usa el producto pedido, la ciudad de entrega y el nombre enmascarado.

No. Las notificaciones de ventas generadas no son pedidos reales de PrestaShop y no se escriben en la tabla de pedidos. El módulo tiene tres modos de notificación:

• Solo pedidos reales: muestra pedidos válidos recientes de PrestaShop, usando nombres de cliente enmascarados, ciudad, datos de producto, imagen de producto, precio y tiempo relativo.
• Solo generadas: construye notificaciones de aspecto realista a partir de productos activos del catálogo más grupos configurados o integrados de nombres y ciudades. Son mensajes de visualización, no pedidos.
• Mixto: usa primero notificaciones de pedidos reales y rellena los huecos restantes con notificaciones generadas cuando no hay suficientes pedidos reales recientes.

El modo de instalación predeterminado es mixed. En modo mixto, si las notificaciones reales son menos que el número solicitado, el código genera rellenos automáticamente; no hay un interruptor separado de relleno generado dentro del modo mixto. Si cada notificación debe corresponder a una compra real, cambia el módulo al modo Real orders only y asegúrate de que la antigüedad máxima del pedido y los filtros de producto sean lo bastante amplios para devolver pedidos recientes.

Las notificaciones reales se cargan desde pedidos válidos de PrestaShop en la tienda actual, limitados por la antigüedad máxima de pedido configurada. La antigüedad máxima predeterminada es 72 horas. Las listas de inclusión y exclusión de productos se aplican antes de devolver la notificación, y el nombre de cliente mostrado se enmascara en lugar de mostrar el nombre completo.

Las notificaciones generadas se construyen a partir de productos activos del catálogo. El módulo selecciona datos de producto, calcula un precio mostrado, intenta usar la imagen de portada del producto, elige un nombre y ciudad de sus grupos y crea un tiempo relativo, como un número reciente de minutos atrás. Esto ocurre en tiempo de visualización mediante el endpoint de notificaciones del front office; no crea carritos, pedidos, clientes, detalles de pedido, pagos ni filas de historial de pedido.

La plantilla del toast del front etiqueta las notificaciones como Verified Purchase, incluidas las generadas. Esa etiqueta forma parte de la presentación del pop-up, no es prueba de que una notificación generada proceda de un pedido real. Para tiendas con cumplimiento estricto o sensibles a auditoría, usa el modo Real orders only.

Sí. La configuración acepta listas de IDs de producto a incluir y excluir separadas por comas. Esos filtros se aplican tanto al seleccionar ítems de pedidos reales como al seleccionar productos para notificaciones generadas.

El front controller notifications devuelve JSON con una cabecera de respuesta noindex cuando el módulo está activado. El script del navegador obtiene ese feed y renderiza las notificaciones toast según los ajustes de tiempo.

No, el módulo crea el punto de entrada del escaparate a Telegram. Después de que el comprador hace clic, Telegram gestiona la conversación en la app o experiencia web de Telegram. Eso mantiene el módulo simple y evita crear una segunda bandeja de mensajes dentro de PrestaShop.

El widget renderiza un enlace fijo de Telegram usando el nombre de usuario configurado. Si se configura un mensaje opcional prerrellenado, el módulo lo añade a la URL https://t.me/... y sustituye {url} por la URL de la página actual antes de enviar al comprador a Telegram. El navegador abre Telegram en una pestaña nueva o en contexto de app; el chat en sí no se incrusta en la página de PrestaShop.

El módulo no guarda mensajes entrantes de Telegram, no crea hilos de atención al cliente de PrestaShop y no ejecuta un webhook de Telegram ni una bandeja de bot dentro del back office. El historial de conversación, respuestas, adjuntos y notificaciones permanecen en Telegram.

La visualización se controla desde los ajustes del módulo. El widget solo se renderiza cuando el módulo está activado y hay un nombre de usuario de Telegram válido. También puedes controlar la posición en el escaparate, estilo de icono o barra, texto de llamada a la acción, color, tamaño, margen, tooltip, animación, retraso de visualización, visibilidad móvil y alcance de páginas como todas las páginas, páginas de producto, páginas de categoría o páginas de checkout.

Sí, Weekly Flash Sale puede publicar automáticamente, pero solo mediante módulos publicadores compatibles. La tarea busca mprinstagramintegration con publishToInstagram(), mprfacebookpostsintegration con publishToFacebook() y mprxintegration con publishToX(). Construye cada texto desde las plantillas de Instagram, Facebook y X usando placeholders como {product_name}, {original_price}, {sale_price}, {discount}, {code} y {product_url}.

• ok:... significa que el publicador devolvió un resultado de plataforma, así que el envío se trató como correcto.
• skipped significa que el módulo de esa plataforma falta o está inactivo, que falta el método de publicación requerido o que el texto de esa plataforma está vacío.
• FAIL significa que el método de publicación devolvió false.
• FAIL:message significa que el publicador lanzó una excepción, y el mensaje después del prefijo se guarda para diagnóstico.
• dry-run es un estado general de ejecución de prueba. La tarea vuelve antes de crear la regla de carrito, publicar o escribir el historial de venta.
• disabled se devuelve cuando la venta semanal está desactivada y la ejecución no es dry run.

Para ejecuciones reales, los resultados por plataforma se guardan en mprweeklysale_history como ig_result, fb_result y x_result, junto al producto, descuento, código generado y fechas de venta.

La publicación automática forma parte de la tarea de flash sale. Una ejecución real primero elige un producto activo que no se haya usado recientemente según la ventana de historial configurada, crea una regla de carrito para el descuento y luego llama a los módulos publicadores sociales disponibles. La configuración predeterminada usa un descuento del 50%, una duración de 24 horas, prefijo de código FLASH, una ventana de historial de 12 semanas y una programación semanal de miércoles a las 08:00.

La regla de carrito generada es específica de producto, activa, destacada, limitada a cantidad 1000 y cantidad por usuario 1. Los textos se construyen después de preparar el precio de venta, código de descuento, URL del producto e imagen del producto. El texto de X se acorta para ajustarse al límite de la plataforma, y el texto de Instagram también se limita antes de publicar.

Por tanto, la publicación automática requiere algo más que activar Weekly Flash Sale. El módulo de integración correspondiente debe estar instalado, activo y exponer el método de publicación esperado, y la tarea cron programada debe ejecutarse con el token correcto. Si falta un módulo de plataforma, la venta puede crearse igualmente y la plataforma ausente se registra como skipped.

Usa el slider de página de inicio del módulo para renderizar un carrusel hero en el hook displayHome de PrestaShop. El código resuelve el slider predeterminado por el identificador de homepage, carga sus banners activos, une los campos de texto del idioma/tienda actuales cuando están disponibles y solo genera el carrusel cuando existen imágenes utilizables.

En la instalación, el módulo crea un slider activo con el identificador homepage. Para mostrar un hero en la página de inicio, crea o edita banners para ese slider, sube al menos una imagen válida, mantén el banner activo y asegúrate de que el módulo siga enganchado a displayHome. El hook llama al mismo renderizador de widget con slider = homepage, por lo que la salida de la página de inicio sigue las mismas reglas que los widgets incrustados.

La consulta del carrusel carga banners activos asignados al slider seleccionado y los ordena por posición y luego por ID de banner. La fila de idioma/tienda se une con un LEFT JOIN, así que el título, subtítulo y texto CTA se toman del idioma y tienda actuales cuando esa fila existe, pero un banner no se rechaza solo porque falte la fila de texto de idioma/tienda. Eso significa que un banner solo de imagen sin traducir todavía puede renderizarse.

Si ningún banner activo tiene un archivo de imagen desktop o móvil existente, el módulo devuelve una cadena vacía en lugar de renderizar un área hero rota.

El comportamiento de visualización viene de la configuración del módulo. La velocidad predeterminada es 5000 milisegundos, autoplay está activado, controles e indicadores están activados, la transición es slide, el estilo Ken Burns está activado y la altura predeterminada es 500. La plantilla también da a la primera diapositiva carga eager y prioridad de fetch, mientras que las siguientes se cargan en lazy para reducir el peso inicial de la página.

Sí, cada banner puede guardar una imagen desktop y una imagen móvil opcional para PrestaShop. La plantilla del carrusel genera fuentes picture responsive, usa la imagen móvil en pantallas pequeñas y añade fuentes AVIF o WebP cuando existen archivos correspondientes junto a las imágenes configuradas.

La imagen móvil está pensada para pantallas estrechas y se emite con una condición media max-width: 767px. La imagen desktop sigue siendo la imagen normal de respaldo para la diapositiva, así que lo mejor es subir una imagen desktop para cada banner y añadir una imagen móvil cuando el recorte deba cambiar para teléfonos.

El módulo no convierte imágenes durante el renderizado. Comprueba si existen archivos hermanos con el mismo nombre base y extensiones .avif o .webp, y luego añade esas fuentes cuando están presentes. Si esos archivos optimizados no están en disco, el carrusel recurre a las rutas de imagen originales subidas.

Un banner sin archivo de imagen desktop ni móvil se omite antes de renderizar. Esto evita diapositivas vacías en el carrusel. Si solo existe una imagen móvil, el banner puede pasar la comprobación de archivo, pero los visitantes desktop quizá no tengan una imagen de respaldo desktop adecuada, así que la configuración del comerciante debería tratar la imagen desktop como base y la imagen móvil como un override responsive opcional.

Sí, el módulo implementa renderizado de widgets de PrestaShop para sliders fuera de la página de inicio. Una plantilla puede llamar al widget con un slider_id numérico o con un identificador de slider guardado en la tabla de sliders del módulo.

{widget name='mprbannerrevolution' slider_id=2} {widget name='mprbannerrevolution' slider='homepage'} {widget name='mprbannerrevolution' slider='landing-sale'}

Si no se pasa ningún parámetro, el módulo resuelve el slider predeterminado homepage. El código no asigna automáticamente sliders a páginas CMS; resuelve el slider desde los parámetros del widget y luego renderiza solo banners activos para ese slider que tienen una imagen desktop o móvil disponible.

La versión con identificador solo funciona para sliders activos, porque la búsqueda usa la comprobación activa de la tabla de sliders. La ruta numérica slider_id carga ese ID exacto de slider. Después de resolver un slider, se usa la misma canalización de renderizado que en la página de inicio: idioma actual, tienda actual, banners activos, comprobaciones de existencia de archivo, fuentes responsive, ajustes de carrusel y plantilla de carrusel compartida.

Hay un comentario de código que menciona slider_cms, pero el resolvedor implementado maneja slider_id, slider y el slider predeterminado homepage. Para páginas CMS o landing pages, usa una llamada explícita al widget en el contenido de la página o en la plantilla del tema en lugar de esperar que el módulo asigne automáticamente páginas CMS a sliders.

Puedes configurar el contenido real del banner usado por el carrusel de PrestaShop: título traducido, subtítulo, texto CTA y URL CTA. Cada banner también guarda color de overlay, opacidad de overlay, alineación de texto, estado activo, posición, imagen desktop e imagen móvil opcional.

Los campos de contenido son multilingües, así que el título del banner, subtítulo, texto del botón y URL del botón pueden variar por idioma. El título se usa como encabezado principal de la diapositiva, el subtítulo aparece debajo y el botón CTA aparece solo cuando tanto el texto CTA como la URL CTA están presentes para ese idioma.

Los controles visuales se guardan con el propio banner. El color de overlay usa negro por defecto, la opacidad de overlay es un valor porcentual, y la alineación de texto soporta left, center y right. La bandera activa controla si el banner puede aparecer, y el valor de posición controla el orden dentro del slider seleccionado.

Los campos de imagen son los medios reales usados por el carrusel. La imagen desktop es la imagen principal de la diapositiva, y la imagen móvil opcional da a los teléfonos un recorte diferente. El flujo de subida de administración acepta formatos web comunes como JPG, PNG, WebP y GIF, mientras que el renderizador del front office también puede añadir fuentes AVIF o WebP si existen archivos optimizados correspondientes en disco.

Se permiten campos de texto vacíos. Por tanto, un banner puede usarse como diapositiva puramente visual, hero de texto sobre imagen o diapositiva promocional con botón, según qué campos traducidos se rellenen.

Sí, los mensajes enviados se guardan en PrestaShop. El procesador crea un registro de envío con estado, bandera de spam, dirección IP, user agent, contexto de cliente o invitado, y luego guarda cada valor de campo enviado en la tabla de datos de envío del módulo.

La fila principal de envío se guarda en mprcontactform_submission. Incluye el ID del formulario, ID de tienda, ID de cliente cuando el visitante ha iniciado sesión, nombre del cliente, email del cliente, dirección IP, user agent, estado, bandera de spam, razón de spam y fecha de creación. Los envíos de invitados se guardan con ID de cliente 0.

Las respuestas individuales se guardan por separado en mprcontactform_submission_data. Cada fila guarda el ID de envío, ID de campo, nombre de campo y valor de campo enviado. Esto permite al módulo mantener separados el encabezado del envío y los campos dinámicos del formulario, algo importante porque cada formulario puede tener un conjunto distinto de campos.

El procesador valida el formulario activo y sus campos activos antes de guardar. Los campos obligatorios, formato de email, formato de teléfono, formato de URL, campos numéricos, opciones de select, validadores personalizados y la casilla GDPR pueden rechazar el envío antes de registrarlo. Después se ejecutan las comprobaciones anti-spam; los envíos de spam siguen guardándose con is_spam = 1 y una razón, pero los emails normales de administración y cliente solo se envían para envíos que no son spam.

La dirección IP se toma de cabeceras forwarded cuando existen, y luego de la dirección remota como respaldo, y el user agent se guarda con límite de longitud. Esto crea una pista de auditoría para consultas sin convertir el módulo en un CRM completo; el seguimiento sigue ocurriendo mediante los destinatarios de email configurados o cualquier flujo de back office que use el comerciante para revisar envíos.

Sí, las consultas pueden enrutarse a destinatarios de administración configurados. Cada formulario puede definir direcciones de email de administración y una línea de asunto; el mailer acepta destinatarios separados por comas y recurre al email global del módulo o al email de la tienda cuando el destinatario de un formulario está vacío.

Este enrutamiento es por formulario, así que un formulario de contacto puede enviar consultas de ventas a una bandeja mientras otro formulario envía solicitudes de soporte a otra. El formulario también tiene un ajuste send_admin_email; si los emails de administración están desactivados para ese formulario, el envío puede seguir guardándose sin enviar una notificación de administración.

La alternativa de destinatario se aplica en orden. El mailer usa primero la lista de emails de administración del formulario, luego el ajuste de email de administración a nivel de módulo y después PS_SHOP_EMAIL. Se pueden introducir varios destinatarios como lista separada por comas. Las direcciones de email inválidas se omiten en lugar de usarse para el envío.

El asunto de administración viene del asunto de email traducido del formulario cuando está definido; de lo contrario, recurre a un asunto genérico de nuevo envío. Se añade el nombre de la tienda, y el email del cliente enviado se usa como reply-to cuando está disponible, de modo que responder desde el buzón puede volver al cliente.

La confirmación al cliente es independiente. Si send_customer_email está activado y el envío incluye una dirección de email de cliente, el módulo también puede enviar al visitante un mensaje de confirmación. Los envíos de spam se guardan para revisión, pero no se llama al mailer para ellos, así que el spam normalmente no se reenvía a destinatarios de administración ni a clientes.

Sí. El módulo comprueba los envíos antes de enviar emails, marca el spam detectado en el registro de envío y guarda una razón de spam. La fuente incluye estos disparadores anti-spam:

• Honeypot: el campo oculto website_url_confirm debe permanecer vacío.
• Tiempo de envío: la marca temporal oculta _mpr_ft debe estar presente, ser válida y ser más antigua que el min_submit_time configurado del formulario.
• Límite de frecuencia: la IP del remitente se bloquea cuando ya ha alcanzado el máximo de envíos por hora del formulario.
• IPs bloqueadas: la IP del remitente se compara con la lista de IPs bloqueadas del formulario, separada por saltos de línea.
• Palabras bloqueadas: cada campo enviado se comprueba frente a palabras bloqueadas configuradas usando una coincidencia de subcadena sin distinguir mayúsculas.

Por defecto, los formularios recién instalados activan el honeypot y la comprobación de tiempo con un tiempo mínimo de envío de 3 segundos. Los envíos de spam se guardan para revisión, pero el flujo normal de emails de administración/cliente solo se ejecuta para envíos no spam.

El límite de frecuencia predeterminado a nivel de módulo es 10 envíos por IP por hora. Establecer el máximo de envíos por IP y hora en 0 desactiva esa comprobación de límite. La consulta de límite cuenta envíos guardados desde la misma dirección IP durante la hora anterior, por lo que los intentos repetidos pueden bloquearse aunque el visitante siga reenviando el mismo formulario.

La comprobación de tiempo está diseñada para detectar publicaciones automatizadas que envían inmediatamente u omiten la marca temporal oculta. Un visitante real recibe el campo oculto _mpr_ft con el formulario, mientras que un bot que publica directamente sin cargar la página normalmente fallará el requisito de marca temporal.

Las razones de spam se guardan como etiquetas legibles por máquina, como honeypot, timing, rate_limit, blocked_ip y blocked_words. Puede registrarse más de una razón en el mismo envío, lo que ayuda a distinguir un envío simplemente demasiado rápido de un mensaje que además contiene palabras bloqueadas.

Sí, puede sustituir la página de contacto predeterminada de PrestaShop cuando ese ajuste está activado. El módulo añade rutas de contacto y usa el hook del dispatcher para redirigir el controlador de contacto principal a su propio renderizado de página de contacto, manteniendo disponibles los enlaces normales de visualización del módulo.

El ajuste está desactivado por defecto. Cuando replace_core_contact está activado, el módulo expone rutas de contacto mediante hookModuleRoutes, usando la reescritura de la página de contacto de la tienda cuando es posible, y también gestiona el controlador principal contact mediante el hook del dispatcher.

En términos de implementación, el hook del dispatcher no envía una redirección de navegador 301 o 302. Reescribe los parámetros de la petición actual in situ cambiando el controlador al controlador de visualización del módulo y estableciendo el nombre del módulo en mprcontactform. El comprador permanece en el flujo de contacto, pero PrestaShop renderiza la página de contacto del módulo en lugar del controlador principal de contacto.

El módulo también puede renderizar formularios mediante su propia ruta de visualización de módulo y mediante hooks como displayMprContactForm y displayContactContent. Eso significa que los comerciantes pueden sustituir la página principal de contacto, incrustar un formulario específico en otro sitio o dejar sin cambios la página de contacto principal y usar solo enlaces del módulo.

Si la sustitución no está activada, el hook de rutas no devuelve rutas de sustitución de contacto y la página de contacto principal queda bajo el control normal de PrestaShop. Esto hace que la función sea reversible desde la configuración sin desinstalar el módulo.

El módulo añade una acción de eliminación a la página de detalle de pedido en administración de PrestaShop. Se renderiza mediante los hooks displayAdminOrderMain y displayAdminOrder cuando el módulo está activado y hay un ID de pedido disponible, y luego envía el pedido al flujo de papelera del módulo.

En una instalación estándar, el módulo está activado y se requiere confirmación. La página de pedido muestra un bloque Delete Order con un botón que enlaza al controlador de administración del módulo usando un parámetro trash_order. Si la confirmación está activada, la plantilla añade un aviso de confirmación del navegador antes de enviar la acción.

Cuando el administrador confirma, el controlador pasa el ID de pedido y el ID del empleado actual al servicio de papelera. El servicio carga el Order de PrestaShop, crea la instantánea de papelera, guarda quién lo eliminó y luego llama al método nativo de eliminación de pedidos de PrestaShop. Si el pedido no puede cargarse como objeto válido, la acción de papelera devuelve false en lugar de eliminar nada.

La acción está pensada para pedidos de prueba, duplicados o no deseados que un comerciante decide eliminar deliberadamente del back office. No es una bandera de ocultación suave sobre la fila original del pedido; después de que se completa el flujo de papelera, se ha llamado al método nativo de eliminación de pedido de PrestaShop y el registro restante del módulo es solo la instantánea de papelera.

Antes de eliminar, el módulo carga el Order de PrestaShop, crea un resumen JSON compacto, inserta una fila en mprdeleteorders_trash y luego llama al método nativo de eliminación de pedidos. La tabla de papelera se conserva intencionadamente al desinstalar por seguridad.

{"id_order":1234,"reference":"ABCDEF123","id_customer":42,"total_paid":149.90,"date_add":"2026-06-17 10:15:00","current_state":2}

• id_order: el ID original del pedido de PrestaShop, también guardado como columna de nivel superior de la tabla de papelera para filtrar.
• reference: la referencia del pedido, también guardada como order_reference.
• id_customer: el ID de cliente vinculado al pedido eliminado.
• total_paid: el total del pedido desde total_paid_tax_incl.
• date_add: la fecha original de creación del pedido.
• current_state: el ID de estado del pedido en el momento de la eliminación.
• deleted_by: el ID del empleado de back office que hizo clic en la acción de papelera.
• date_deleted: cuándo se creó el registro de papelera.

Esto es una instantánea de auditoría, no una copia reversible completa de todas las tablas relacionadas con el pedido, factura, mensaje y líneas de producto. Úsala para identificar qué se eliminó y por quién antes de purgar definitivamente.

La propia tabla de papelera guarda id_trash, id_order, order_reference, order_data, deleted_by y date_deleted. El controlador de lista puede mostrar estas filas de papelera para que un administrador revise el ID original del pedido, referencia, empleado que lo eliminó y fecha de eliminación.

El JSON contiene deliberadamente solo un pequeño conjunto de valores de cabecera del pedido. No guarda productos, detalles de pedido, direcciones, pagos, facturas, mensajes, filas de transportista, contenido del carrito, cupones ni historial de movimientos de stock. Por esa razón debe tratarse como trazabilidad de eliminaciones, no como un paquete de restauración.

No, el módulo no reconstruye desde la papelera un pedido eliminado de PrestaShop. Cuando un pedido se mueve a la papelera, guarda una pequeña instantánea JSON con valores como ID de pedido, referencia, ID de cliente, total pagado, fecha de creación y estado actual, y luego llama al método de eliminación de pedidos de PrestaShop.

El método de restauración solo lee la fila de papelera, confirma que existe, elimina esa fila de papelera y devuelve éxito para esa acción de limpieza. No recrea la fila original del pedido, detalles de pedido, pagos, facturas, historial de pedido, datos de carrito ni registros relacionados.

Esa limitación es importante porque el módulo no guarda suficientes datos relacionales para realizar una reconstrucción completa segura de un pedido. Trata la papelera como un buffer de auditoría y limpieza, no como una copia de seguridad completa. Para una recuperación real, usa una copia de seguridad de base de datos o un proceso de restauración manual fuera de este módulo.

La acción de limpieza permanente de papelera también es independiente de la restauración de pedidos. Eliminar una fila de papelera solo elimina la instantánea de auditoría del módulo; no afecta a un pedido de PrestaShop ya eliminado porque los datos originales del pedido ya fueron eliminados por la llamada nativa de eliminación.

Para tiendas en producción, el flujo práctico es usar el módulo para limpiar pedidos conocidos de prueba o no deseados, mantener copias de seguridad de base de datos para recuperación y verificar el pedido antes de eliminarlo. Si un pedido puede necesitar recuperarse con productos, pagos, facturas e historial intactos, no dependas de la fila de papelera del módulo como fuente de recuperación.

No, la desinstalacion conserva la tabla de papelera por seguridad. En PrestaShop el modulo elimina pestañas y configuracion, pero el comentario del codigo indica que mprdeleteorders_trash se mantiene al desinstalar.

Sí. Cuando el seguimiento de compras está activado y el módulo tiene permiso para rastrear al visitante, dispara un evento Hotjar purchase desde el hook de confirmación de pedido de PrestaShop. La plantilla del front office llama a hj('event', 'purchase') en la página de confirmación de pedido.

Esto es útil para el análisis en Hotjar porque puedes filtrar grabaciones, mapas de calor, encuestas o funnels alrededor de sesiones que alcanzaron una compra, y luego inspeccionar el comportamiento antes de que se realizara el pedido. Ayuda a responder preguntas como dónde dudaron los compradores, qué pasos de checkout repitieron o qué patrones de página aparecen en sesiones exitosas.

No sustituye a la analítica de ingresos ni al reporting de pedidos del lado del servidor. Hotjar recibe el evento nombrado para segmentación de comportamiento; los detalles de pedido del módulo se usan principalmente para construir contexto local de evento y no son un feed completo de transacciones.

La función depende de las guardas normales del módulo Hotjar. El módulo debe estar activado, el Hotjar Site ID debe estar configurado como dígitos, el seguimiento de compras debe estar activado y el visitante debe pasar las comprobaciones de seguimiento del módulo, como el manejo de consentimiento cuando el respeto al consentimiento está activado. Si el seguimiento no está permitido, el hook de confirmación de pedido no devuelve nada.

Cuando el hook se ejecuta, el módulo construye contexto local de compra a partir del pedido de PrestaShop, incluyendo valores como ID de pedido, moneda, valor total, número de artículos e identificadores de producto. Ese contexto se asigna a la plantilla de confirmación de pedido y puede ser usado por las herramientas locales de registro/demo de eventos del módulo, pero la llamada Hotjar Events API hecha por la plantilla sigue siendo el evento nombrado simple purchase.

En Hotjar, usa el evento purchase como marcador de comportamiento. Para totales, impuestos, margen, atribución, gestión de reembolsos o reporting de conversiones autoritativo, sigue usando datos de pedidos de PrestaShop o una plataforma de analítica diseñada para reporting transaccional.

No. El módulo envía eventos de PrestaShop y contexto de cliente a Klaviyo, pero la lógica de campañas, segmentos, contenido de email y flows SMS se gestionan en Klaviyo. Esa separación es útil porque los datos de tienda vienen de PrestaShop mientras que la estrategia de marketing permanece en la plataforma de marketing.

En términos de fuente, el lado PrestaShop se limita a la entrega de datos onsite. Cuando ENABLED está establecido y PUBLIC_API_KEY está presente, el hook de cabecera carga el script onsite de Klaviyo con el company id. Los valores predeterminados de instalación dejan el módulo desactivado, mantienen la clave pública vacía y ofrecen interruptores de seguimiento como TRACK_VIEWED, TRACK_CART y TRACK_PURCHASE.

La plantilla del front puede identificar clientes conectados con email y nombre, rastrear una página de producto como Viewed Product y rastrear la página del carrito como Added to Cart. No contiene un constructor de flows de Klaviyo, editor de segmentos, editor de plantillas de email, pantalla de flujos SMS ni capa de API de campañas. La fuente expone un interruptor de compra, pero la plantilla de seguimiento del navegador inspeccionada no genera una llamada de seguimiento de compra, así que la automatización de compras debe verificarse igualmente en Klaviyo en lugar de asumirse solo por el ajuste de PrestaShop.

PUBLIC_API_KEY=YOUR_KLAVIYO_PUBLIC_KEY ENABLED=1 TRACK_VIEWED=1 TRACK_CART=1

En parte. El módulo tiene plantillas de tarjetas de producto y carga de datos de producto, pero la ruta de escaparate implementada no es una columna desplegable independiente product_list. MenuBuilder puede cargar elementos de columna product_list desde un ID de categoría y límite, pero extractChildrenFromColumns() no expone elementos product_list como hijos de menú, así que los comerciantes no deberían confiar en que ese tipo de columna renderice tarjetas de producto hasta que se añada soporte de plantilla/hijos.

La ruta implementada hoy son previsualizaciones de producto bajo hijos de árbol de categorías. Añade una columna desplegable de tipo category_tree, activa PRODUCTS_NB con un valor superior a cero, y el builder puede adjuntar productos de cada hijo de categoría. La plantilla del escaparate renderiza entonces el primer producto adjunto como tarjeta destacada y los productos adjuntos restantes como tarjetas más pequeñas dentro del panel.

SHOW_PRICES y SHOW_DISCOUNTS controlan si aparecen precios e insignias de descuento; ambos están activados por defecto. PRODUCTS_NB controla cuántas previsualizaciones de producto de hijos de categoría se adjuntan. El TTL de caché del menú controla lo rápido que aparecen los cambios estructurales, y se registran hooks de actualización de producto, categoría y CMS para limpiar los datos de menú en caché cuando cambia el contenido de la tienda.

Implemented storefront path:
category_tree child + PRODUCTS_NB > 0 = product previews under that category child.
Not currently implemented as rendered storefront cards:
standalone product_list column.

El módulo renderiza el menú móvil desde la misma configuración de menú de nivel superior, con un parser móvil dedicado. Eso reduce el mantenimiento duplicado y ayuda a mantener alineadas la navegación desktop y móvil. Aun así, conviene revisar el diseño móvil porque las etiquetas largas y los árboles de categoría profundos pueden afectar la usabilidad.

Las salidas desktop y móvil reciben los mismos datos $menu.children para el árbol off-canvas. En móvil, la plantilla renderiza ese árbol, mientras que HtmlMobileTreeParser y el constructor de menú pueden convertir varios diseños de columnas desktop en una estructura móvil más simple, incluyendo árboles de categorías, árboles de categorías CMS, categorías de blog, grupos de enlaces, enlaces CMS, listas de enlaces, árboles móviles derivados de HTML y pestañas visuales.

Eso significa que normalmente mantienes etiquetas, enlaces, árboles de categorías, enlaces CMS, pestañas visuales y contenido móvil personalizado compatible una sola vez en el módulo. La excepción práctica es el contenido que no se extrae en menu.children. En particular, las columnas desktop product_list no se extraen al árbol móvil actual, y la plantilla móvil renderiza solo $menu.children; el contenido de lista de productos necesitaría soporte de plantilla storefront/móvil antes de aparecer en el menú off-canvas.

El HTML personalizado es otra zona que conviene probar. Si una columna contiene marcado inusual y no hay un árbol móvil utilizable, el parser móvil puede recurrir a una estructura simple o vacía, así que prueba etiquetas largas, árboles anidados y HTML promocional en un ancho móvil real antes de depender de ello para la navegación.

No. La plantilla renderizada usa skype:username?chat, que es un enlace de chat. El código no renderiza un enlace ?call ni un botón separado de llamada de voz/vídeo.

El módulo debe estar activado y USERNAME debe estar configurado. El validador de configuración obligatoria permite letras, números, puntos, guiones y guiones bajos, con una longitud de 3 a 64 caracteres.

El hook displayHeader registra views/css/mprskypechatintegration.css solo cuando pasa el guard del chat, así que los widgets inactivos o sin configurar no cargan esa hoja de estilos.

Sí. El guard compartido comprueba SHOW_MOBILE y devuelve false en contextos móviles cuando ese ajuste está desactivado.

No. El módulo conecta PrestaShop con Tidio y controla el comportamiento de carga del escaparate. Los flows de chatbot, gestión de bandeja de entrada y flujos de operadores se gestionan dentro de Tidio, donde corresponden esas herramientas.

Los ajustes de PrestaShop son ajustes de conexión y renderizado: PUBLIC_KEY es obligatorio y se valida, ENABLED usa por defecto 1, y el widget puede retrasarse, ocultarse en móvil, limitarse por tipo de página y recibir opcionalmente email/nombre del cliente conectado mediante PASS_USER_DATA.

PUBLIC_KEY=your_tidio_public_key ENABLED=1 PAGES=all DELAY=0 PASS_USER_DATA=1

En el front office, la plantilla solo define datos opcionales document.tidioIdentify y añade el script alojado de Tidio desde code.tidio.co. No hay constructor de bots del lado de PrestaShop, vista de bandeja de entrada, pantalla de asignación de operadores, tabla de historial de mensajes ni API de flows en este módulo, así que la automatización de ventas/soporte debe configurarse en el panel de Tidio.

La configuración guarda el estado de activación, título, mensaje HTML, visibilidad del campo de newsletter, retraso en segundos, duración de la cookie en días y si debe mostrarse en todas las páginas o solo en la página de inicio.

Después de que el visitante lo cierre, el script establece la cookie mprwpop_seen con el número de días configurado. El script del popup comprueba esa cookie antes de volver a mostrarse.

No. El campo de email es solo visual en este módulo. Cuando SHOW_NEWSLETTER está activado, la plantilla del front renderiza un formulario de newsletter con un input de email y botón Subscribe, pero el módulo en sí no contiene front controller, manejador AJAX, inserción en tabla de suscriptores ni integración con módulo de newsletter que guarde las direcciones enviadas.

El script del popup solo gestiona el tiempo de visualización, cierre del modal, cierre con tecla Escape y la cookie mprwpop_seen. No intercepta el envío del formulario ni envía la dirección a ningún sitio.

Si quieres capturar leads, conecta ese formulario a tu propio handler, un módulo de newsletter, endpoint de Brevo o Mailchimp, o una acción de formulario a nivel de tema que tu tienda procese. Hasta que exista esa integración, activar el campo solo muestra una caja de email; no crea suscriptores de newsletter.

Los ajustes relacionados del módulo solo deciden si el campo se muestra y con qué frecuencia aparece el popup. Los valores predeterminados de instalación establecen SHOW_NEWSLETTER en 0, DELAY en 3 segundos, COOKIE_DAYS en 7 y SHOW_ON en all; SHOW_ON=homepage lo limita al controlador index.

La cookie de visibilidad se define cuando el comprador cierra el popup, hace clic en el overlay o pulsa Escape. Enviar el formulario de newsletter no crea un registro de suscriptor en este módulo, y el formulario de la plantilla no tiene URL de acción, así que el comerciante debería tratarlo como un placeholder de front-end hasta conectarlo a un endpoint real de newsletter.

<form class='mprwpop-newsletter' id='mprwpop-nl-form' method='post'>

Sí. Cuando el ajuste de visualización es solo página de inicio, el hook devuelve contenido únicamente si la página actual del front controller es la página index.

Añade tu Microsoft UET Tag ID numérico y activa el seguimiento del navegador en el módulo. El hook de cabecera de PrestaShop carga el script UET, envía el evento de carga de página y luego envía los eventos de navegador configurados cuando el seguimiento está activo y las reglas de consentimiento lo permiten.

En una instalación nueva, el seguimiento no está activo hasta completar esos ajustes: ENABLED usa por defecto 0, TAG_ID está vacío, y el módulo solo se considera activo cuando el tag ID es numérico. En el formulario de administración, guarda el Microsoft Ads UET tag ID sin letras ni espacios, mantén RESPECT_CONSENT activado si usas un módulo de cookies compatible, y decide qué interruptores de evento deben quedar activos.

TAG_ID=123456789 ENABLED=1 RESPECT_CONSENT=1 TRACK_PAGE_VIEW=1 TRACK_PRODUCT_VIEW=1 TRACK_PURCHASE=1

Cuando se ejecuta el hook de cabecera, también puede capturar msclkid desde la URL de llegada para posterior coincidencia de conversiones. La exclusión de empleados está activada por defecto mediante EXCLUDE_EMPLOYEES, así que las pruebas con sesión de back office iniciada pueden no disparar eventos salvo que tengas en cuenta ese ajuste.

Sí, soporta Microsoft Conversions API para eventos de compra del lado del servidor, pero solo cuando los ajustes requeridos están completos. El módulo necesita seguimiento activado, un TAG_ID numérico, CAPI_ENABLED activado, un CAPI_ACCESS_TOKEN guardado y seguimiento de compras activado.

• Validación de administración: el UET Tag ID debe contener solo dígitos, CAPI no puede activarse sin un tag ID numérico, el bearer token es obligatorio cuando CAPI está activado, y el límite de lote de cola debe ser 1-100.
• Flujo de pedido: en actionValidateOrder, el módulo comprueba canTrack(), TRACK_PURCHASE y la disponibilidad de CAPI antes de encolar nada.
• Flujo de cola: se encola una conversión de compra para el proveedor microsoft_uet, vinculada al ID de pedido, y luego el módulo procesa inmediatamente un lote pequeño de 3 eventos. La tarea cron procesa después el lote configurado normal.

La etiqueta UET del navegador puede seguir gestionando eventos de página, carrito, búsqueda y remarketing; la ruta CAPI en este módulo es específicamente la ruta de compra del lado del servidor.

Para la configuración, los campos CAPI importantes son:

CAPI_ENABLED=1 CAPI_ACCESS_TOKEN=your_microsoft_token CAPI_BATCH_LIMIT=20 TRACK_PURCHASE=1

El cliente API envía eventos a Microsoft UET CAPI usando el tag ID numérico en el endpoint y un bearer token. La carga normaliza nombre/id/hora del evento, URL de origen, consentimiento de almacenamiento de anuncios, datos de usuario y datos personalizados de compra. La coincidencia de usuario puede incluir dirección IP, user agent, msclkid guardado, detalles de cliente hasheados e identificadores anónimos de carrito/invitado cuando están disponibles.

Esto no sustituye del lado del servidor a todos los eventos de navegador del módulo. Page view, product view, search, add-to-cart, wishlist y eventos personalizados de clic/URL/controlador permanecen del lado del navegador en la fuente inspeccionada; CAPI es el complemento de compra del servidor.

El módulo agrupa eventos Microsoft Ads UET alrededor de actividad de comercio en el escaparate, cuenta, búsqueda y disparadores personalizados. Los eventos principales son configurables individualmente en los ajustes del módulo.

• Comercio/escaparate: pageView, productView, addToCart, addToWishlist, initiateCheckout y purchase. Los eventos de producto, carrito y compra incluyen parámetros de comercio como IDs de producto, valores de pedido, moneda y cantidades cuando están disponibles.
• Búsqueda: search se dispara en páginas de resultados de búsqueda con el contexto de la consulta.
• Cuenta: signUp se dispara después del registro de cliente mediante el flujo de hook de registro del módulo.
• Personalizados: se pueden configurar eventos personalizados con disparadores de clic, URL, controlador o evento DOM, con nombres de evento limitados a las reglas de nomenclatura UET permitidas por el módulo.

El evento de compra se envía en la página de confirmación de pedido, mientras que los eventos add-to-cart y wishlist se capturan mediante listeners JavaScript del front office.

La mayoría de esos interruptores están activados por defecto al instalar, incluidos TRACK_PAGE_VIEW, TRACK_PRODUCT_VIEW, TRACK_ADD_CART, TRACK_ADD_WISHLIST, TRACK_INITIATE_CHECKOUT, TRACK_SEARCH, TRACK_PURCHASE y TRACK_SIGNUP. TRACK_CUSTOM_EVENTS usa por defecto desactivado hasta que definas reglas de eventos personalizados.

Las reglas personalizadas están acotadas intencionadamente: el normalizador de configuración acepta hasta 15 nombres de evento distintos, elimina parámetros reservados event_id y soporta selectores de clic, coincidencias de URL contiene, nombres de controlador o eventos DOM personalizados. El JavaScript del front office deduplica eventos de botones add-to-cart y wishlist durante aproximadamente un segundo para que sea menos probable contar dos veces la misma acción.

Sí. Con RESPECT_CONSENT activado, el módulo comprueba el consentimiento de marketing antes de considerar activo el seguimiento Microsoft UET. Primero comprueba mprcookiesrevolution leyendo la cookie mprcr_consent y buscando marketing:1. Si esa cookie no existe, recurre al valor DEFAULT_CONSENT de ese módulo. Si Cookies Revolution no está activo, comprueba mprcookiebanner mediante mprcookie_consent=granted, recurriendo de nuevo al ajuste de consentimiento predeterminado de ese módulo cuando la cookie no existe.

Si no hay ningún módulo de consentimiento MPR compatible activo, la función de consentimiento devuelve permitido, así que el seguimiento no se bloquea solo por consentimiento. Para una restricción GDPR estricta, mantén RESPECT_CONSENT activado e instala/configura uno de los módulos de consentimiento compatibles.

El flujo msclkid se ejecuta en el hook de cabecera. El módulo lee msclkid de la URL de llegada, acepta solo caracteres A-Za-z0-9._:- hasta 500 caracteres, lo refleja en $_COOKIE['mprbuet_msclkid'] y luego escribe una cookie HTTP-only llamada mprbuet_msclkid durante 7776000 segundos. Los datos de usuario de conversiones del lado del servidor posteriores pueden incluir ese Microsoft click ID guardado cuando está presente.

• https://shop.example/?msclkid=abc123 guarda abc123 en la cookie del módulo.
• Una compra posterior puede adjuntar ese valor a los datos de conversión de Microsoft UET si las conversiones del lado del servidor están configuradas.

La comprobación de consentimiento del lado del servidor y la puerta JavaScript del front office trabajan juntas pero no son idénticas. La guarda PHP canTrack() bloquea la construcción de eventos para empleados, módulos desactivados y consentimiento de marketing fallido; la plantilla de cabecera también comprueba cookies del navegador antes de cargar bat.js cuando hay un módulo de consentimiento de cliente compatible.

Si RESPECT_CONSENT se establece en 0, la comprobación de consentimiento se omite. Si no hay instalado ningún módulo de consentimiento MPR compatible, la función PHP permite el seguimiento solo por consentimiento, así que las tiendas estrictas no deberían confiar en el módulo UET por sí solo como su única capa de consentimiento.

La cookie msclkid se escribe antes de la compra posterior, lo que importa porque un comprador puede llegar desde Microsoft Ads, navegar y pedir en una solicitud posterior. El valor solo se acepta si coincide con la whitelist de caracteres del módulo; los valores inválidos o demasiado largos se ignoran en lugar de enviarse a Microsoft.

No. El tag de navegador solo lo inyecta el hook de cabecera de PrestaShop cuando el seguimiento esta activo, es decir, cuando hay un TAG_ID numerico guardado y ENABLED vale 1. La biblioteca de Microsoft se anade entonces con script.async = true desde https://bat.bing.com/bat.js, por lo que se carga sin bloquear el renderizado de la pagina.

Al cargarse, el modulo envia un unico pageLoad a window.uetq y despues solo los eventos que hayas activado, como vista de producto, anadir al carrito o compra, mediante uetq.push('event', ...). Cuando hay un modulo de consentimiento compatible, el pixel se carga solo tras confirmar el consentimiento de marketing en el navegador, de modo que los visitantes que rechazan no generan ninguna peticion a Microsoft.

El envio del lado del servidor mediante la Conversions API se ejecuta en una tarea cron programada, no en la peticion del cliente, y los empleados con sesion iniciada quedan excluidos por defecto mediante EXCLUDE_EMPLOYEES.

Cuando la Conversions API esta activada y hay un token bearer de Microsoft guardado, los eventos de compra se ponen en cola al validar el pedido y se envian del lado del servidor mediante una tarea cron programada, send_bing_uet_conversions, que se ejecuta cada 300 segundos. Cada ejecucion procesa la cola hasta el limite de lote configurado (CAPI_BATCH_LIMIT, por defecto 20, permitido 1–100 y limitado a 100 filas por ejecucion), de modo que los eventos fallidos o pendientes se reintentan en el siguiente ciclo en lugar de perderse.

Los datos de usuario del lado del servidor pueden incluir el id de clic de Microsoft almacenado (msclkid), el correo y telefono con hash, la IP del cliente y el user-agent. Las entradas procesadas y obsoletas se limpian automaticamente, conservando el historial reciente y eliminando las filas antiguas con el tiempo.

Si falta el token bearer o esta vacio, el bloque de disponibilidad del admin muestra una advertencia y no se envia ningun evento del lado del servidor hasta que lo anadas. El UET de navegador puede permanecer activado de forma independiente para vistas de pagina y remarketing mientras configuras la Conversions API.

No, no para el botón básico de contacto de Messenger. El ajuste requerido es el Facebook Page ID numérico; sin App ID configurado, la plantilla del escaparate renderiza un enlace directo https://m.me/{page_id} para que los compradores abran Messenger desde el botón flotante.

• Modo enlace m.me: necesita el módulo activado y un Page ID válido. Es rápido de configurar y funciona como un enlace externo simple de contacto por Messenger.
• Modo SDK: el módulo trata un campo App ID relleno como el interruptor para renderizar el marcado del plugin de chat de clientes de Facebook y cargar el SDK de customer chat de Facebook. El texto de saludo se usa en ese marcado de modo SDK.

Así que los comerciantes que solo quieren un botón fiable de Messenger pueden dejar vacío el App ID. Añade el App ID solo cuando quieras deliberadamente la ruta de chat incrustado basada en SDK y tengas lista la configuración del lado de Facebook.

El requisito de Page ID es estricto: el validador de configuración obligatoria del módulo acepta solo dígitos, de 5 a 32 caracteres, y el widget no se renderiza mientras el módulo está activado pero ese campo está vacío. Los valores predeterminados activan el widget, lo muestran en todas las páginas incluido móvil, usan el estilo de icono inferior derecho y un retraso de visualización de 0 segundos.

Los ajustes de apariencia como POSITION, STYLE, CTA_TEXT, COLOR, SIZE, MARGIN, tooltip y animación se usan en la ruta de botón flotante de enlace. El filtro de páginas y la visibilidad móvil vienen de la guarda de chat compartida, así que puedes mostrar el punto de entrada a Messenger solo en páginas de producto, categoría o checkout si encaja con tu flujo de soporte.

El método fetch comprueba primero RSS_URL. Si está vacía, construye una URL RSS desde BOARD_URL. Las URLs de pins solo se usan cuando la ruta RSS no produce posts.

No. mprpinterestintegration es un módulo de contenido/feed de Pinterest, no el módulo de seguimiento de anuncios de Pinterest. Muestra pins, tableros o contenido basado en RSS de Pinterest en la tienda e incluye gestión de caché para el feed mostrado. La fuente también contiene ajustes opcionales de publicación por API de Pinterest para publicar producto/contenido.

• Pinterest Feed Integration: úsalo para mostrar contenido de Pinterest en el escaparate, configurar nombres de usuario, URLs de pins, URLs de tableros o fuentes RSS, y opcionalmente publicar contenido de la tienda en Pinterest.
• Pinterest Tag: usa el módulo separado Pinterest Tag para medición publicitaria, eventos de etiqueta del navegador y seguimiento opcional Conversions API, como visitas de página, vistas de producto, add-to-cart, checkout, búsqueda y registro.

Si el objetivo es mejorar el merchandising visual o incrustar contenido de Pinterest, usa esta integración de feed. Si el objetivo es atribución de Pinterest Ads u optimización de conversiones, usa el módulo Pinterest Tag en su lugar.

Para la ruta de feed, la fuente requerida puede ser tan simple como una o más URLs de pin guardadas, o una URL de tablero/fuente RSS según cómo quieras curar el contenido. Los ajustes compartidos de feed controlan hook de visualización, número de publicaciones, columnas, diseño grid/slider, botón de seguimiento, visibilidad móvil y duración de caché; la caché usa por defecto 3600 segundos y puede refrescarse desde la administración del módulo.

La ruta opcional de publicación también está separada del seguimiento de anuncios. La publicación en Pinterest requiere credenciales de API de Pinterest como un token de acceso e ID de tablero, y el publicador envía datos de pin basados en imagen a Pinterest. Eso sigue sin instalar la etiqueta publicitaria de Pinterest ni reportar conversiones de anuncios; para eso, la tienda necesita el módulo separado mprpinteresttag.

El config map incluye ACCESS_TOKEN, BOARD_ID, AUTOPUBLISH y AUTOPUBLISH_CAPTION. La publicación se gestiona mediante el PinterestPublisher compartido.

Cada elemento del feed enlaza a la URL del pin, muestra imagen thumbnail, badge de vídeo opcional, texto overlay, nombre de autor opcional y caption opcional según los ajustes del módulo y los datos de origen.

El módulo requiere el Website Key de Smartsupp. Su panel de configuración indica al comerciante que lo copie desde los ajustes de Smartsupp, y el validador de configuración obligatoria trata una clave vacía como inválida.

Si PASS_USER_DATA está activado y el cliente ha iniciado sesión, el trait de chat compartido devuelve customer_email y customer_name. La plantilla los asigna a _smartsupp.email y _smartsupp.name.

No. La plantilla carga el script externo del widget de Smartsupp. La interfaz visible del chat la proporciona Smartsupp después de que se ejecute el cargador.

Sí. Si el ajuste DELAY es mayor que cero, la plantilla envuelve la inicialización de Smartsupp y la inyección del script en setTimeout.

No, no necesitas una cuenta de desarrollador de TikTok solo para mostrar vídeos. El feed de visualización se basa en URLs de vídeo de TikTok pegadas y en el endpoint público oEmbed de TikTok. En los ajustes del módulo, introduce el nombre de usuario de TikTok para el enlace de seguimiento, pega una URL de vídeo de TikTok por línea en el campo Video URLs y guarda.

Cuando se construye el feed, el módulo divide la lista de URLs guardada por líneas, omite entradas que no contienen tiktok.com, llama a https://www.tiktok.com/oembed?url=... y guarda el título, caption, autor, miniatura y HTML embed devueltos para mostrarlos. Esa ruta de visualización no usa token de API, revisión de app ni credenciales de desarrollador.

Las credenciales solo son relevantes para el flujo opcional de publicación. La fuente tiene ajustes de publicación como ACCESS_TOKEN, CLIENT_KEY, AUTOPUBLISH y AUTOPUBLISH_CAPTION, y usa una instancia de publicador de TikTok para esa ruta. Si tu objetivo es solo incrustar vídeos seleccionados de TikTok en la tienda, puedes dejar vacías esas credenciales de publicación.

El módulo de visualización está activado por defecto, con interruptores de caption, icono de vistas e icono de likes activos, mientras que los valores compartidos de feed usan displayHome, 6 publicaciones, 3 columnas desktop, diseño de cuadrícula, lazy loading y una duración de caché de 3600 segundos. El feed se renderiza solo en el hook de social-feed configurado; si el hook configurado no coincide con el hook actual, no se genera nada.

Hay dos casos prácticos: las URLs sin tiktok.com se omiten, y cualquier petición oEmbed que falle se omite en lugar de renderizar una tarjeta rota. La tarjeta del escaparate enlaza a la URL original de TikTok y muestra la miniatura, autor y caption devueltos, así que vídeos eliminados/privados o respuestas oEmbed bloqueadas simplemente reducen el feed.

VIDEO_URLS=https://www.tiktok.com/@brand/video/1234567890 USERNAME=brand SHOW_CAPTION=1 POST_COUNT=6

Sí. El trait compartido de chat comprueba el ajuste móvil antes de renderizar y no devuelve ningún botón cuando la visualización móvil está desactivada para un visitante móvil.

No, el módulo no gestiona agentes, historial de conversaciones ni flujos de soporte. WhatsApp gestiona la conversación en sí, mientras que el módulo gestiona el botón del escaparate y la URL click-to-chat. Eso mantiene la integración ligera y clara.

El único campo de conexión obligatorio es PHONE. Debe contener solo dígitos, de 7 a 20 caracteres, incluyendo el código de país y sin signos más ni espacios. La plantilla del front construye https://wa.me/{phone}, y si se configura un mensaje añade ?text=... para que WhatsApp lo prerrellene.

• Lo que controla PrestaShop: activar/desactivar, número de teléfono, mensaje opcional prerrellenado, posición, estilo icono/barra, texto CTA, color, tamaño, margen, tooltip, animación, visibilidad móvil, retraso de visualización y filtro de páginas.
• Lo que controla WhatsApp: el hilo real del chat, respuestas, asignación de personal, historial de mensajes, notificaciones y cualquier función de bandeja o CRM.

El mensaje opcional soporta {product} en páginas de producto y {url} para la página actual, lo que resulta útil para preguntas de producto. Sigue siendo solo un mensaje WhatsApp prerrellenado, no un ticket ni un registro de soporte guardado en PrestaShop.

El módulo reemplaza {url} por la URL de la página actual. En páginas de producto también puede reemplazar {product} por el nombre del producto actual.

El módulo puede renderizar desde el hook footer o before-body, pero una bandera estática interna evita la salida duplicada. El alcance de página puede ser todas las páginas, páginas de producto, páginas de categoría o páginas relacionadas con checkout.

Añade el código de invitación de Discord en la configuración del módulo y activa el widget. En PrestaShop, el módulo renderiza un botón de front office enlazado a discord.gg con el código de invitación guardado, posición configurable, estilo, texto CTA, color, tamaño, tooltip, animación y margen.

Usa solo el código de invitación, no la URL completa. El validador de configuración obligatoria espera letras, números, guiones y guiones bajos, de 2 a 64 caracteres. Un código de invitación ausente impide el renderizado; un código guardado inválido se marca en el aviso de configuración y puede producir un enlace de Discord incorrecto.

INVITE_CODE=AbCdEfG123 ENABLED=1 STYLE=icon POSITION=bottom-right CTA_TEXT=Join our Discord

En la instalación, los valores predeterminados ya dejan el widget activado, abajo a la derecha, estilo icono, azul Discord #5865F2, tamaño 60px, margen 20px, tooltip activado, animación pulse, móvil activado, todas las páginas y sin retraso. El panel de configuración de administración recomienda crear una invitación permanente y un canal de soporte dedicado, porque el módulo envía a los compradores al flujo de unión al servidor en lugar de gestionar conversaciones de Discord dentro de PrestaShop.

Sí, el widget puede limitarse por tipo de página. En PrestaShop, la guarda de chat compartida soporta todas las páginas, páginas de producto, páginas de categoría o controladores relacionados con checkout, y también comprueba el ajuste separado de visibilidad móvil antes de renderizar.

El filtro de páginas se guarda en el ajuste compartido PAGES. La guarda devuelve true para all, comprueba php_self=product para páginas de producto, php_self=category para páginas de categoría, y trata cart, order, order-opc, orderopc y checkout como controladores relacionados con checkout.

La misma guarda también requiere ENABLED y un INVITE_CODE no vacío, y oculta el widget en móvil cuando SHOW_MOBILE está desactivado. Eso significa que la segmentación por página no es un snippet separado que haya que pegar en el tema; forma parte de la decisión de renderizado del módulo antes de generar el CSS y el botón.

PAGES=product SHOW_MOBILE=1 DELAY=0

Si, el modulo tiene un ajuste de retraso para el boton de la tienda. En PrestaShop la plantilla del hook escribe un valor data-delay y un pequeño script oculta el widget y lo muestra tras los segundos configurados.

No, el módulo no envía texto prerrellenado a Discord. El ajuste de conexión obligatorio es un código de invitación, no un token de API de usuario/mensaje, y la plantilla del escaparate renderiza un enlace a https://discord.gg/{invite_code}.

El campo de administración Pre-filled Message se guarda como referencia y el módulo puede sustituir {url} internamente antes de asignar datos de plantilla, pero la plantilla actual del escaparate no genera ese mensaje ni lo añade a la URL de invitación de Discord.

Eso difiere de plataformas de chat que soportan parámetros URL para una conversación prerrellenada. Los enlaces de invitación de Discord llevan al comprador a un flujo de invitación/unión al servidor, así que la configuración práctica es crear un enlace de invitación permanente y dirigir a los clientes a un canal de soporte después de unirse.

La fuente confirma esa separación. El formulario de conexión de administración etiqueta el campo como Pre-filled Message, pero su descripción dice que no se usa para invitaciones de Discord y que se guarda como referencia. En el hook, el módulo sustituye {url} dentro del mensaje guardado antes de asignar datos Smarty, pero la plantilla solo usa invite_code, posición/estilo/CTA/apariencia, tooltip, animación y retraso.

Para comerciantes, la configuración fiable es la propia invitación: crea un código de invitación estable, evita que caduque y usa reglas de servidor/canal de Discord para guiar a los clientes después de unirse. No dependas de este módulo para abrir un DM directo de Discord, publicar en un canal o pasar un mensaje de checkout/producto a Discord.

No, es un módulo de navegación de idiomas. Ayuda a los compradores a cambiar entre idiomas que ya tienes en marcha y los dirige a URLs localizadas donde PrestaShop tiene datos. La calidad de traducción, segmentación por país y lógica de ubicación del visitante quedan fuera de este módulo.

El módulo lee los idiomas activos de PrestaShop para la tienda actual con Language::getLanguages(true, shop_id). Si la tienda solo tiene un idioma activo, no devuelve selector. Para cada idioma, asigna el ISO del idioma a un SVG de bandera cuando existe, construye una URL de idioma desde las URLs de idioma alternativo del front controller cuando están disponibles, y recurre a getLanguageLink() de PrestaShop.

• Navegación: la salida desktop oculta el selector nativo de idioma desktop y renderiza un desplegable de banderas en displayNav2; la salida móvil puede renderizar un select simple en displayMobileLanguageSelector.
• Etiquetas: SHOW_LABEL controla si se muestra el código ISO actual junto a la bandera, y SHOW_NAMES controla si se muestran nombres completos de idioma en el desplegable. Los valores predeterminados son etiqueta desactivada y nombres activados.
• Límites: no traduce nombres/descripciones de producto, no elige idiomas por geolocalización, no redirige visitantes por país ni crea URLs localizadas faltantes.

Hay limpieza adicional de URLs para alias de páginas principales y un hook de integración para rutas de filtro traducidas de MPR Filter Revolution, pero eso sigue dependiendo de rutas/datos traducidos existentes. Es un selector, no un motor de traducción.

Registra displayHeader, displayOrderConfirmation, actionCustomerAccountAdd y actionValidateOrder.

No. El template de confirmación de pedido y el server conversion builder usan el evento de Pinterest checkout para pedidos completados, incluyendo valor de pedido, cantidad, moneda, ID de pedido y event ID.

CAPI_ENABLED debe estar activado, el Pinterest ad account ID debe contener solo dígitos y el access token no debe estar vacío. El batch limit debe estar entre 1 y 100.

Sí, cuando una custom rule tiene capi habilitado. El front conversion bridge mapea nombres de eventos de navegador conocidos y también acepta nombres de eventos CAPI personalizados configurados.

El módulo lee la cadena de selectores configurada y ejecuta document.querySelectorAll para esos selectores. De forma predeterminada apunta a miniaturas de producto, bloques de categoría y elementos de productos destacados.

El script front termina pronto si IntersectionObserver no está disponible. Eso significa que no añade clases de animación ocultas en navegadores no compatibles.

Sí, puedes activar o desactivar el efecto desde los ajustes del módulo. Es útil si quieres probar si las animaciones ayudan a tu tienda o si una página de campaña necesita un diseño más tranquilo. Como el efecto no está hardcodeado en las plantillas, quitarlo no requiere revertir el tema.

El interruptor on/off es el ajuste ENABLED. El hook de cabecera comprueba primero ese valor; cuando está desactivado, vuelve antes de registrar el CSS del front, JavaScript o configuración inline, así que las plantillas del tema quedan intactas.

Los valores predeterminados de instalación son ENABLED=1, ANIMATION_TYPE=fade-up, DELAY=0, DURATION=600 y selectores para miniaturas de producto, bloques de categoría y elementos de productos destacados. Las opciones de administración también permiten cambiar el tipo de animación a fade-in, slide-left, slide-right o zoom-in, ajustar retraso/duración en milisegundos y editar la lista de selectores.

En el escaparate, el script usa IntersectionObserver. Si no hay selectores coincidentes o el navegador no soporta la API, sale sin aplicar clases ocultas/visibles. Por tanto, desactivar el ajuste del módulo es la ruta limpia de rollback; no se necesita revertir plantilla porque el módulo controla el registro de assets y la inyección de clases.

ENABLED=0

No. Cuando el observer marca un elemento como visible, llama a unobserve para ese elemento, así que el reveal es una transición de una sola vez.

Los valores por defecto de instalación ponen ENABLED en 0 y USERNAME en una cadena vacía. El hook de renderizado sale pronto salvo que el módulo esté activado y exista un nombre de usuario.

No, abre tu perfil de Snapchat mediante el nombre de usuario configurado. El contenido del perfil y las conversaciones permanecen dentro de Snapchat. Esto mantiene el módulo centrado en dar a los compradores una ruta limpia para seguirte o contactarte sin añadir un feed social pesado a la página.

La salida del escaparate es un botón flotante renderizado desde el hook displayBeforeBodyClosingTag. El hook se detiene antes de renderizar si el botón Snapchat no está activado, si el valor USERNAME está vacío, si la visualización móvil está desactivada para un visitante móvil o si el controlador actual está listado en EXCLUDE_PAGES. Cuando renderiza, el destino se construye como https://www.snapchat.com/add/ más el nombre de usuario codificado en URL.

La plantilla confirma que es un enlace normal, no un embed de Snapchat. Genera una etiqueta <a> con la URL configurada, target=_blank opcional, texto de tooltip, estilo de botón, animación y mensaje grabber opcional. No hay iframe, llamada a API de Snapchat, renderizador de feed ni código que lea conversaciones o contenido del perfil desde Snapchat.

Required for output: ENABLED=1
Required account value: USERNAME=yourbrand
Rendered link: https://www.snapchat.com/add/yourbrand

Para comerciantes, eso significa que el módulo tiene bajo impacto: da a los visitantes una ruta visible hacia tu presencia en Snapchat mientras deja todo el contenido, follows, mensajes y privacidad de cuenta bajo la app y web propias de Snapchat.

La definición de configuración lista small, medium y large, etiquetados como 48px, 60px y 72px. El tamaño seleccionado se pasa a la clase del widget como mprchat-size-....

No. Este módulo renderiza un enlace flotante a un perfil de Snapchat. Snapchat Pixel y el seguimiento de eventos publicitarios los gestiona otro módulo de este lote.

Cuando las wishlists de invitado están activadas, el script frontal guarda los ID de producto en localStorage del navegador y devuelve respuestas en modo invitado para acciones de añadir y eliminar. El almacenamiento con sesión iniciada usa las tablas de base de datos del módulo.

La configuración JavaScript marca al cliente como conectado y la acción de sincronización puede enviar los artículos de localStorage al servidor para que se añadan a la wishlist predeterminada del cliente.

Las wishlists de base de datos tienen un token de 32 caracteres. La vista frontal puede cargar productos por token, y la plantilla trata al propietario conectado de forma distinta a un visitante que ve una wishlist compartida.

Cuando un cliente conectado guarda un producto, el módulo almacena el precio del momento de añadirlo. La lista de productos compara ese precio guardado con el precio actual del producto y marca una bajada cuando el precio actual es inferior.

No. Este módulo es principalmente un tracker de automatización de Brevo y sincronización de registro de cliente, no una integración completa de eventos de carrito/pedido/producto.

• Gestiona: displayBeforeBodyClosingTag carga el script de automatización de Brevo, llama a la función de seguimiento de página e identifica al visitante por email cuando un cliente ha iniciado sesión. actionCustomerAccountAdd puede crear o actualizar el nuevo cliente como contacto de Brevo cuando la suscripción automática está activada.
• No gestiona: actualizaciones de carrito, payloads de vista de producto, eventos de compra de confirmación de pedido, eventos de carrito abandonado o eventos de estado de pedido. El módulo no registra hooks de carrito, pedido o producto para esas acciones.

Si necesitas abandono de carrito, ingresos de compra o automatización de comportamiento de producto en Brevo, este módulo necesitaría hooks de evento adicionales o una integración separada que envíe esos eventos específicos de Brevo.

La lista de hooks es el límite importante: el módulo registra solo displayBeforeBodyClosingTag y actionCustomerAccountAdd. La plantilla del escaparate crea window.sib, carga https://sibautomation.com/sa.js?key=..., encola las funciones estándar de Brevo y llama a window.sendinblue.page(). Si un cliente ha iniciado sesión, también llama a window.sendinblue.identify() con la dirección de email. No se añaden IDs de producto, líneas de carrito, referencias de pedido, totales ni estados de pedido a ese payload de navegador.

En la creación de cuenta, el módulo publica al endpoint de contactos de Brevo con el email del cliente, FIRSTNAME, LASTNAME, updateEnabled=true y el LIST_ID configurado cuando se ha guardado uno. Eso es útil para crecimiento de lista y entrada básica en automatizaciones, pero está separado del seguimiento de eventos ecommerce.

Registered hooks: displayBeforeBodyClosingTag, actionCustomerAccountAdd
Contact API: POST https://api.brevo.com/v3/contacts
Tracked browser event here: page view, plus logged-in email identify
Not present here: cart payload, purchase payload, abandoned cart event

Activa el módulo, añade una clave API de Brevo y mantén activada la sincronización automática de registro. Cuando PrestaShop crea una cuenta de cliente, el hook actionCustomerAccountAdd envía el email más los atributos FIRSTNAME y LASTNAME a Brevo, e incluye el ID de lista configurado cuando se ha guardado uno.

Los ajustes relevantes son ENABLED, API_KEY, LIST_ID y AUTO_SUBSCRIBE. En la instalación, el módulo empieza con ENABLED=0, clave API vacía, ID de lista vacío, clave de cliente de tracker vacía y AUTO_SUBSCRIBE=1. Así que la configuración habitual es: activar Brevo, pegar la clave API de Brevo, introducir opcionalmente el ID de lista numérico para nuevos contactos y dejar activado Auto-subscribe New Customers.

La sincronización solo se ejecuta para creación de cuentas nuevas porque el módulo escucha actionCustomerAccountAdd. Primero comprueba que el módulo esté activo, que exista la clave API, que la suscripción automática esté activada y que PrestaShop haya proporcionado un objeto newCustomer cargado. Si cualquiera de esas comprobaciones falla, vuelve sin enviar nada a Brevo.

Cuando envía, el módulo publica JSON en https://api.brevo.com/v3/contacts con timeout cURL de 10 segundos y verificación SSL peer activada. Establece updateEnabled en true, así que un contacto existente en Brevo puede actualizarse en lugar de provocar un fallo por contacto duplicado. Esta versión de la fuente no importa clientes existentes en masa y no sincroniza ediciones posteriores de perfil salvo que PrestaShop cree una nueva cuenta mediante ese hook.

Required: ENABLED=1, API_KEY set, AUTO_SUBSCRIBE=1
Optional: LIST_ID=123
Sent fields: email, FIRSTNAME, LASTNAME, listIds when configured

Sí. El hook del escaparate carga el tracker de automatización de Brevo solo cuando el módulo está activado, la Brevo API Key está configurada y la Client Key está configurada. El campo Client Key en los ajustes del módulo se etiqueta como Client Key (Tracker), y la pista de la fuente dirige a los comerciantes a Brevo > Automation > Settings > Tracking Code.

Para confirmar que el tracker se carga, abre el código fuente del escaparate o las herramientas de desarrollador del navegador y busca https://sibautomation.com/sa.js?key=... con script id sendinblue-js. La plantilla inicializa window.sib.client_key, encola sendinblue.track, sendinblue.identify, sendinblue.trackLink y sendinblue.page, identifica a clientes conectados por email y luego llama a window.sendinblue.page().

Si no ves ese script, revisa primero el interruptor de módulo activado, API Key y Client Key. El hook devuelve una cadena vacía cuando falta cualquiera de esos requisitos.

El requisito de API key importa aunque el tracker de navegador use la Client Key. En este módulo, isActive() es compartido por el hook del tracker y comprueba tanto ENABLED como API_KEY; luego el hook comprueba por separado CLIENT_KEY. Por tanto, una tienda con solo la Client Key guardada seguirá sin generar nada hasta que también se configure la API key.

Required for tracker output:
ENABLED=1
API_KEY=xkeysib-...
CLIENT_KEY=Brevo automation tracker key

La salida del tracker se limita al script de automatización de Brevo, seguimiento de página e identificación por email de clientes conectados. En esta versión de la fuente no añade contenido de carrito, totales de pedido, metadatos de producto ni eventos de compra.

Sí, la sincronización automática de registro puede desactivarse desde la configuración del módulo. El hook actionCustomerAccountAdd de PrestaShop comprueba el interruptor AUTO_SUBSCRIBE antes de enviar un nuevo cliente a Brevo, así que el módulo puede permanecer instalado mientras la sincronización de registro está desactivada.

El ajuste se etiqueta como Auto-subscribe New Customers en las opciones del módulo. Su valor predeterminado es activado en una instalación nueva, pero el hook lo comprueba cada vez que PrestaShop crea una cuenta de cliente. Cuando AUTO_SUBSCRIBE está desactivado, el hook sale antes de validar el nuevo objeto de cliente o llamar a la API de contactos de Brevo.

Desactivar este interruptor solo detiene la sincronización de registro a contacto. No desinstala el módulo, no elimina credenciales API guardadas ni desactiva automáticamente el tracker de automatización del escaparate. Si ENABLED, API_KEY y CLIENT_KEY siguen configurados, el hook del tracker todavía puede cargar el script de Brevo y llamar a la función de seguimiento de página.

Tampoco da de baja ni elimina contactos que ya se crearon en Brevo. Simplemente impide que este módulo envíe futuras creaciones de contacto de nuevas cuentas mientras el interruptor permanezca desactivado.

AUTO_SUBSCRIBE=1: new customer can be posted to Brevo contacts
AUTO_SUBSCRIBE=0: actionCustomerAccountAdd returns before syncContactToBrevo()

Puedes añadir Crisp chat a PrestaShop introduciendo tu Crisp Website ID y activando el módulo. El aviso de configuración del módulo espera el Website ID en formato UUID, pero el módulo solo exige que el campo no esté vacío; no impone el patrón UUID exacto al guardar ni al mostrar el widget. En la práctica, aun así deberías pegar el Website ID real con formato UUID desde Crisp, porque un valor arbitrario no vacío puede guardarse y renderizarse pero quizá no cargue un widget funcional.

Al instalar, el módulo Crisp crea valores de chat con ENABLED=1, WEBSITE_ID vacío, SHOW_MOBILE=1, PAGES=all, DELAY=0 y PASS_USER_DATA=1. Como el Website ID empieza vacío, el módulo puede instalarse correctamente, pero el widget permanece inactivo hasta guardar ese ID.

El aviso de configuración requerida espera formato UUID, por ejemplo xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. La ayuda de configuración apunta a Crisp en Settings > Website Settings > Setup instructions. Una vez guardado un valor no vacío, el escaparate sigue aplicando las mismas reglas de visualización, así que el widget respeta el interruptor de activación, un Website ID no vacío, el ajuste móvil y la segmentación de páginas.

Cuando se cumplen esas reglas, la plantilla define window.CRISP_WEBSITE_ID, opcionalmente envía datos de email/nombre del cliente conectado y añade https://client.crisp.chat/l.js de forma asíncrona al head de la página.

Minimum setup:
Enable Crisp Chat = Yes
Website ID = UUID from Crisp
Show on Pages = All Pages, Product Pages, Category Pages or Checkout Pages

Sí, Crisp chat puede limitarse por tipo de página de PrestaShop. La guarda de chat compartida soporta todas las páginas, páginas de producto, páginas de categoría o controladores de checkout, incluidos cart, order, order-opc, orderopc y checkout, antes de generar el script Crisp.

El ajuste es el campo select compartido Show on Pages. Sus valores guardados soportados son all, product, category y checkout. El valor predeterminado del módulo es all, así que una instalación nueva con un Website ID válido será apta para mostrarse en todas las páginas del escaparate salvo que el comerciante cambie ese ajuste.

La coincidencia de página usa el controlador actual de PrestaShop php_self. El modo solo producto coincide exactamente con product, el modo solo categoría coincide exactamente con category, y el modo checkout coincide con cart, order, order-opc, orderopc o checkout. El interruptor móvil se comprueba por separado, así que una página puede coincidir con la regla de página y aun así ocultarse en móvil si SHOW_MOBILE está desactivado.

Show on Pages = all       -> every page
Show on Pages = product   -> product controller only
Show on Pages = category  -> category controller only
Show on Pages = checkout  -> cart/order checkout controllers

Si se guarda un valor inesperado en PAGES, la rama predeterminada de la guarda compartida permite la página en lugar de bloquearla. Para una segmentación predecible, usa uno de los cuatro valores expuestos por el formulario.

Sí, pero solo cuando la transferencia de datos de cliente está activada y el comprador ha iniciado sesión. El ajuste es el interruptor Pass Customer Data en la configuración del módulo Crisp; establécelo en No para impedir que el módulo envíe datos de identidad del cliente conectado a Crisp.

• Cuando PASS_USER_DATA está desactivado, el helper de chat compartido devuelve campos de cliente vacíos.
• Cuando está activado y el cliente ha iniciado sesión, el helper devuelve el email del cliente y el nombre más apellidos del cliente.
• La plantilla Crisp envía esos datos como user:email y user:nickname antes de cargar https://client.crisp.chat/l.js.

Los visitantes anónimos siguen recibiendo el widget Crisp cuando el Website ID y las reglas de visualización lo permiten, pero no se transfiere ningún email o nombre de cliente de PrestaShop porque no hay objeto de cliente conectado.

En una instalación nueva, PASS_USER_DATA usa por defecto 1, así que los comerciantes que no quieran esta transferencia deberían desactivar el interruptor deliberadamente. El helper solo expone dos valores a la plantilla: customer_email y customer_name. No incluye datos de dirección, números de teléfono, contenido del carrito, historial de pedidos ni ID de cliente de PrestaShop.

El hook Crisp también debe cumplir primero las reglas normales de visualización del módulo. Si el módulo está desactivado, falta el Website ID, la visualización móvil está bloqueada o la regla de página no coincide, la plantilla no se renderiza y no se envían datos de cliente a Crisp.

PASS_USER_DATA=1 + logged-in customer: email and first name + last name can be pushed
PASS_USER_DATA=0 or anonymous visitor: customer_email and customer_name stay empty

Sí, el script de Crisp puede retrasarse un número configurado de segundos. La plantilla actual del hook de PrestaShop envuelve el cargador de Crisp en setTimeout cuando el retraso es superior a cero; no espera scroll, clic, toque u otra interacción de usuario.

El ajuste guardado es DELAY, mostrado en el formulario compartido como Fallback Delay (seconds). En el módulo Crisp actual, el hook pasa ese valor a la plantilla como entero. Si el valor es mayor que cero, la plantilla envuelve todo el bloque de configuración y añadido del script Crisp en setTimeout(..., DELAY * 1000).

Un valor de 0 significa que la plantilla no añade wrapper de timeout, así que la configuración Crisp se ejecuta inmediatamente cuando se analiza la salida del hook. Aunque la descripción del campo compartido menciona primera interacción de usuario y fallback, esta plantilla Crisp implementa solo el comportamiento de temporizador descrito arriba.

DELAY=0  -> no setTimeout wrapper; load immediately
DELAY=5  -> run Crisp setup after 5 seconds
DELAY=15 -> run Crisp setup after 15 seconds

El retraso no omite la cadena normal de guardas. El módulo debe seguir activado, el Website ID debe estar presente, la visualización móvil debe estar permitida para visitantes móviles y la regla de segmentación de páginas debe coincidir antes de imprimir cualquier script retrasado.

Sí. Configura los IDs de producto excluidos en el ajuste de lista de productos del módulo, por ejemplo como lista separada por comas. El override elimina los productos excluidos del paquete pasado al cálculo de reglas de carrito de PrestaShop, así que los descuentos monetarios se calculan solo sobre productos elegibles.

Excluded product IDs: 42,108,315
Cart: #42 $100 excluded + #77 $50 eligible
Voucher: 20% off products
Before exclusion: 20% of $150 = $30 discount
After exclusion: 20% of $50 = $10 discount; #42 stays at full price

La misma lista de exclusión puede combinarse con exclusiones de categoría y fabricante porque el módulo fusiona las tres fuentes en un único conjunto de productos excluidos. Los descuentos porcentuales se aplican solo a productos elegibles. Las reducciones de importe fijo se prorratean mediante el paquete filtrado, mientras que el envío gratuito y el comportamiento de regalo se dejan al manejo normal de reglas de carrito de PrestaShop.

El ajuste de lista de productos se guarda como PRODUCTS. El resolvedor lee el valor separado por comas, convierte cada entrada con intval, elimina valores cero vacíos y luego fusiona esos IDs con IDs derivados de categoría y fabricante. La lista final se cachea para la petición PHP actual, lo que evita repetir las consultas de categoría y fabricante durante el mismo cálculo de carrito.

El override CartRule solo cambia reglas con una reducción monetaria: reduction_percent mayor que cero o reduction_amount mayor que cero. Si el módulo no está activado, si la lista de exclusión configurada se resuelve como vacía o si el paquete de la regla de carrito actual no contiene productos excluidos, delega sin cambios en el cálculo padre de PrestaShop.

Como el filtro comprueba id_product, la exclusión se aplica al producto completo. Si un producto tiene combinaciones, la fuente no distingue una combinación de atributo de otra en este paso de exclusión.

Stored setting: PRODUCTS=42,108,315
Resolver output: [42,108,315,...category matches,...manufacturer matches]
Override input: package products
Override output: package products without excluded id_product values

Sí. Las exclusiones pueden introducirse como IDs directos de producto, IDs de categoría e IDs de fabricante. Los campos de configuración de administración son listas separadas por comas, y el resolvedor las convierte en una lista final de IDs de producto antes del cálculo del descuento.

PRODUCTS=12,15
CATEGORIES=3,7
MANUFACTURERS=1,4

Con esa configuración, los productos 12 y 15 se excluyen directamente. El módulo también consulta category_product para cada producto asignado a las categorías 3 o 7, y consulta product para cada producto cuyo id_manufacturer es 1 o 4. Fusiona esos IDs, elimina duplicados con array_unique y cachea el resultado para la petición actual.

El override CartRule pide entonces al módulo esa lista resuelta de productos y filtra los productos excluidos fuera del paquete antes de que se calcule el descuento de regla de carrito padre. En términos de comerciante: los productos coincidentes permanecen a precio completo, mientras que el resto del carrito puede seguir recibiendo el descuento del cupón.

La regla de categoría se basa en los IDs exactos de categoría guardados en CATEGORIES. La consulta de fuente lee filas de category_product donde id_category está en esa lista; no recorre el árbol de categorías en PHP. Si una tienda necesita excluir también todas las categorías hijas, esos IDs de categorías hijas deberían incluirse salvo que los productos también estén asignados directamente a la categoría padre listada.

La regla de fabricante se basa en product.id_manufacturer. Como ocurre con productos directos, la exclusión final es por id_product, así que todas las combinaciones de un producto coincidente se tratan como excluidas. Las entradas de texto inválidas se reducen efectivamente mediante conversión a entero; los valores vacíos y cero no aportan IDs de producto útiles.

Category source: ps_category_product.id_category IN saved category IDs
Manufacturer source: ps_product.id_manufacturer IN saved manufacturer IDs
Final discount filter: id_product not in resolved exclusion list

No, el override apunta a reducciones monetarias de reglas de carrito, no al beneficio de envío gratuito en sí. Si el módulo está desactivado, no hay productos excluidos configurados o la regla de carrito no tiene reducción porcentual ni de importe fijo, el override delega en el cálculo normal CartRule de PrestaShop.

Ejemplo: un cupón da 10% off plus free shipping, y el carrito contiene solo productos excluidos por este módulo. El descuento de producto se convierte en 0 porque todos los productos están excluidos de la reducción monetaria, pero si la regla tiene free_shipping y PrestaShop está calculando la acción de envío, el override delega en el cálculo padre de envío para que la parte de envío gratuito pueda seguir aplicándose.

Para carritos mixtos, el módulo filtra los productos excluidos antes del cálculo padre. Los descuentos porcentuales se aplican solo a productos elegibles, y los descuentos de importe fijo los calcula PrestaShop contra el paquete filtrado.

La ruta rápida es importante para cupones solo de envío gratuito. Cuando una regla de carrito no tiene reduction_percent ni reduction_amount, el override devuelve el resultado padre de PrestaShop sin filtrar el paquete. Eso significa que un cupón puro de envío gratuito sigue las condiciones normales de cupones de PrestaShop y no se reduce solo porque los productos estén en la lista de exclusión.

Cuando todos los productos están excluidos y una regla combina un descuento monetario con envío gratuito, el override devuelve 0 para la parte monetaria salvo que el filtro actual sea uno de los filtros de acción shipping/all de PrestaShop. Para esos filtros shipping/all llama al cálculo padre con FILTER_ACTION_SHIPPING, que es la razón a nivel de fuente por la que el beneficio de envío puede seguir disponible.

Un detalle práctico: el aviso opcional del carrito está separado de las matemáticas del descuento. El renderizador de aviso comprueba si el módulo y el aviso están activados, si el carrito tiene reglas de carrito y si hay productos excluidos presentes. No inspecciona si la regla de carrito es monetaria o solo de envío gratuito, así que el mensaje puede seguir siendo informativo mientras PrestaShop gestiona el envío normalmente.

Sí, el módulo puede mostrar un aviso en el carrito cuando hay productos excluidos. En PrestaShop, el aviso aparece solo cuando el módulo y el ajuste de aviso están activados, el carrito tiene reglas de carrito y al menos un producto del carrito coincide con la lista de exclusión.

La función de aviso está activada por defecto al instalar con SHOW_NOTICE=1. El texto multilingüe predeterminado del aviso es The following products are excluded from the applied discount:, y los comerciantes pueden editar NOTICE_TEXT desde los ajustes del módulo. El módulo registra tanto displayShoppingCart como displayShoppingCartFooter; el hook footer se mantiene como alias de compatibilidad para tiendas que todavía usan la ubicación de hook antigua.

El renderizador también tiene una guarda contra duplicados. Una vez que un aviso se ha renderizado durante la petición, $cartNoticeRendered impide que el mismo mensaje aparezca dos veces si ambos hooks de carrito se ejecutan en el tema.

El módulo construye la lista de nombres de producto desde los productos actuales del carrito cuyo id_product aparece en la lista de exclusión resuelta. Si product_name no está disponible, recurre a name y luego a una etiqueta genérica de número de producto. La plantilla escapa tanto el texto del aviso como los nombres de producto antes de generar la salida.

Notice shown only if:
ENABLED=1
SHOW_NOTICE=1
cart has at least one cart rule
cart contains at least one resolved excluded product

Si no hay cupón/regla de carrito aplicada, el aviso se oculta intencionadamente aunque haya productos excluidos en la cesta. Eso mantiene el mensaje ligado al momento en que un cliente espera un descuento y podría preguntarse por qué algunos artículos quedaron a precio completo.

El campo obligatorio es el HubSpot Portal ID. El aviso de configuración requerida del módulo permanece activo mientras el campo esté vacío.

La plantilla de HubSpot revisada identifica a los clientes conectados por e-mail cuando pass-user-data está activado. No envía datos de visitantes anónimos desde PHP.

El trait compartido del chat admite todas las páginas, páginas de producto, páginas de categoría o páginas relacionadas con el checkout, como cart, order, order-opc, orderopc y checkout.

No. El código utiliza un timeout configurado en milisegundos antes de renderizar el widget. Es un retraso temporal, no un cargador activado por interacción.

No hay ningún motor de reglas automáticas en los archivos leídos aquí. La asignación de insignias se guarda por producto en mprproductbadges, y el formulario admin requiere un producto seleccionado.

La tabla guarda id_product, badge_name, badge_color, badge_bg_color, position y active, además del ID de insignia autoincremental.

La consulta del storefront filtra por producto y estado activo, y después ordena los resultados por position ASC. Los números de posición más bajos se muestran primero.

Sí. MprProductBadgesConfig expone un interruptor ENABLED. Cuando está desactivado, renderBadges() devuelve una cadena vacía antes de leer datos del producto.

El módulo debe estar activado y debe existir un Pixel ID. El validador de configuración obligatoria acepta Pixel IDs con letras, números, guiones bajos o guiones, con longitud de 8 a 128 caracteres.

displayOrderConfirmation renderiza el evento purchase del navegador. actionValidateOrder encola un evento purchase server-side cuando Conversions API está configurada y el seguimiento purchase está activado.

Los eventos header y purchase reciben un event_id desde PrestaShopConversionBuilder::buildEventId, y el mismo valor se copia a client_dedup_id. La cola Purchase CAPI usa el mismo event ID basado en el pedido.

Las reglas pueden activarse por clics CSS, coincidencias de URL, coincidencias de controller/module o eventos DOM con nombre. El normalizer valida requisitos de trigger, limita la longitud del selector y sanea parámetros personalizados antes de guardar el JSON.

El feed necesita un bearer token y un username cuando el módulo no está gestionado por Social Revolution. El módulo puede llamar a X API para resolver el user ID a partir de ese username.

La configuración controla texto del post, fecha, likes, reposts, respuestas, medios y detalles del autor. El código también crea permalinks y gestiona expansiones de medios devueltas por la API.

No. Los requisitos difieren. YouTube puede usar URLs manuales de vídeo sin API key, mientras que Facebook, Instagram y X requieren credenciales de plataforma antes de poder obtener posts desde sus APIs. Cada módulo muestra su propio aviso de configuración requerida.

Los módulos de feed usan datos cacheados y obtienen desde su plataforma/fuente configurada cuando las reglas de caché lo permiten. Algunos también ofrecen controles de limpiar caché o sincronizar, así que el comportamiento real de refresco depende de credenciales, duración de caché y ajustes del módulo de plataforma.

No. Las opciones de layout son similares, pero no idénticas. Facebook y X incluyen opciones grid, slider y lista; Instagram y YouTube incluyen opciones grid/slider; Pinterest y TikTok tienen sus propias plantillas de feed y post-item.

Los módulos de integración individuales incluyen visualización de feeds y algunos hooks o secciones de auto-publicación en el código, pero el pack debe describirse principalmente como integraciones de visualización de feeds salvo que la configuración de publicación de un módulo de plataforma concreto esté configurada y probada.

El módulo asigna páginas y hooks del front office de PrestaShop a eventos Criteo OneTag, con ajustes separados para cada evento estándar.

Todos los eventos de navegador siguen dependiendo de que el módulo esté activo, haya un partner ID de Criteo configurado, el visitante pase las comprobaciones de tracking/consentimiento del módulo y el toggle correspondiente por evento esté activado.