Módulo Visual Search No SaaS: El Buscador Inteligente autoalojado con opción meilisearch

v1.4.382026/10/08

Al escribir, los resultados salen arriba y no debajo de la bienvenida

Visto en iogenixdise (PS 8.2) al buscar «Isolate»: con la consulta escrita, el panel seguía enseñando «Búsquedas populares» y «Más vendidos», y los resultados, con la coincidencia exacta en cabeza, quedaban a ~1.580 px de la parte de arriba.

Era una carrera. Al abrir el panel se pide la bienvenida al servidor, y si el cliente escribía antes de que llegara, la respuesta pintaba la bienvenida encima de los resultados. Ahora esa petición se cancela en cuanto hay consulta, y si ya estaba en camino no se pinta. Con la bienvenida retrasada 4 s a propósito, los resultados quedan a 192 px y la primera ficha a 236 px, sin CSS del tema.

El bloque de mensaje propio, enlaces y «Categorías más encontradas», que solo sale con consulta, pasa de encima de los resultados (169 px) a detrás de ellos.

Una búsqueda, una petición

• Cada consulta salía dos veces al servidor. rkrfreevisualsearch-nav.js envolvía executeSearch con _origExecute(query).then ? _origExecute(query)…: la comprobación ya lanzaba la búsqueda y la rama la lanzaba otra vez.
• Al abrir el panel salían 2 o 4 búsquedas vacías. Una pedía «productos destacados» con featured_only, un parámetro que el servidor no ha leído nunca, y la respuesta no traía nada que pintar: se ha quitado. Además, el tema llama a open() con el foco y con el clic de su caja, y la segunda llamada repetía la bienvenida y borraba lo escrito: ahora no hace nada si el panel ya está abierto.
• Filtros, orden y límite no cancelaban la búsqueda anterior y dos respuestas podían llegar en cualquier orden. Ahora toda búsqueda cancela la que esté en camino, y una respuesta vieja se descarta aunque llegue (también las de «cargar más» y las del autocompletado).

El autocompletado tardaba lo que una página entera

autocomplete.php llamaba a parent::initContent(), que en PrestaShop asigna las variables de página y ejecuta displayHeader con los ganchos de todos los módulos de la tienda. En iogenixdise eran 3,6 s de cada petición, también con el autocompletado apagado, porque la comprobación iba después. Ahora 0,1–0,2 s (0,9 s la primera vez). search.php nunca lo hizo. addcart.php hacía lo mismo y también deja de hacerlo: añadir al carrito desde el panel, 0,17 s.

La tira de autocompletado, con miniatura y sin tapar nada

Flotaba sobre el panel (position: absolute), tapaba las búsquedas populares y solo llevaba texto. Ahora va en el flujo, arriba de la columna de resultados, en una sola fila que se desplaza en horizontal (~70 px), y cada producto lleva su miniatura: el servidor ya mandaba image_url. Intro sobre una sugerencia marcada con las flechas no hacía nada (la lista que leía estaba siempre vacía) y ahora la abre.

El buscador tardaba segundos en tiendas con historial de pedidos

Medido en maesalv9 (PS 9.1.4, 1.083 productos, 535.838 líneas de pedido):

• Fichas de producto (ProductDataProvider::getProducts): las unidades vendidas se sumaban de order_detail + orders en cada petición, ~1 s por producto vendido. Al abrir el buscador (consulta vacía) los 12 «más vendidos» tardaban 9,8 s. Ahora salen de rkrfreevisualsearch_index.total_sold, que el Indexer ya calcula con la misma suma (mismos números); solo lo no indexado se calcula como antes. Consulta vacía: 10,1 s → 0,22 s; «ceramico»: 2,4 s → 0,4 s. Las respuestas son idénticas byte a byte.
• Autocompletado: se montaban las fichas de hasta 80 candidatos para enseñar 8 y luego se descartaban los que no casaban (1,7 s). Ahora se filtra antes con nombre, referencia y EAN de una consulta y solo se montan limit * 2 fichas. 2,2 s → 0,15–0,4 s, mismas sugerencias. En iogenixdise (PS 8.2, 346 productos, 578.153 líneas de pedido), «Isolate» pasa de 12 s a 0,3 s sin caché, y la consulta vacía de 5 s a 0,24 s. La búsqueda difusa (FUZZY, umbral 60) y MAX_PRODUCTS_QUERY=100 no eran el cuello de botella: una consulta sin resultados, que recorre la difusa, tarda 0,49 s.

Actualizar

upgrade-1.4.38.php solo llama a Media::clearCache(): con «Smart cache» de JS/CSS activado, la tienda seguiría sirviendo el paquete combinado viejo.

v1.4.372026/10/05

Un banner de imagen o vídeo tiraba la tienda entera en PrestaShop 9.2

Con un banner de tipo imagen o vídeo activo, la portada y las fichas de producto daban un error fatal en PrestaShop 9.2, no solo el buscador: SmartyException: Template './_banner-overlay.tpl' cannot be relative to template of resource type 'module'. _banner-media.tpl incluía el texto del banner con una ruta relativa (./_banner-overlay.tpl), y el Smarty de 9.2 ya no admite rutas relativas dentro de una plantilla cargada como module:.

Ahora se incluye con su ruta completa (module:rkfreevisualsearch/views/templates/hook/_banner-overlay.tpl), como el resto de plantillas del front. No hace falta upgrade: es solo la plantilla. Reproducido en 9.2.0 con la versión anterior y comprobado con la nueva en 9.2.0, 9.1.5, 9.0.0, 8.2.8 y 1.7.8.11 (portada con un banner de imagen arriba y uno de vídeo en el lateral, y la página de resultados). Los include relativos del back-office no cambian: esas plantillas se cargan por ruta de fichero y funcionan también en 9.2.

v1.4.362026/09/30

La clave de Meilisearch «no se quedaba guardada»

Lo reporto un cliente. La clave SI se guardaba, pero la pantalla decia lo contrario y acababa apagando Meilisearch. Desde 1.4.33 la clave guardada ya no viaja al navegador —el campo sale siempre vacio—, y el JavaScript de la pantalla seguia deduciendo «no hay clave» de un campo vacio: al cargar apagaba y bloqueaba el interruptor y mostraba «API Key is required». Como un checkbox deshabilitado no se envia, el siguiente guardado mandaba el 0 del campo oculto y desactivaba Meilisearch. Y si se forzaba, el PHP rechazaba el guardado con el mismo motivo, porque tambien miraba solo el campo.

Ahora la plantilla dice si hay clave guardada (data-key-set), el JavaScript lo tiene en cuenta y el PHP solo exige la clave si el campo llega vacio y no hay ninguna guardada. Reproducido en 9.2.0 con la version anterior y comprobado con la nueva: guardar con clave, recargar y volver a guardar sin escribirla deja Meilisearch activado y la clave intacta.

v1.4.332026/09/28

Limpieza. Ninguna funcionalidad cambia para el comerciante; lo que cambia es lo que el modulo hace por debajo y lo que viaja dentro del paquete.

Cada «anadir al carrito» hacia una peticion HTTP del servidor a si mismo

Al anadir un producto desde el buscador, el controlador pedia por cURL el HTML del mini-carrito a la propia tienda, con dos segundos de plazo, dentro del camino de compra. No servia para nada: apuntaba al modulo blockcart, que no existe desde PrestaShop 1.7 —el bloque de carrito nativo es ps_shoppingcart—, asi que la peticion contestaba 404 y el HTML llegaba siempre vacio. Medido en 8.2.8: HTTP 404 y 47 bytes.

Lo que si costaba era tiempo. En una tienda que no se alcanza a si misma por su dominio publico —Cloudflare delante, DNS de horizonte partido, un balanceador, o un certificado que cURL no valida— eran los dos segundos enteros en cada pulsacion, justo en la pantalla donde el cliente decide.

El refresco lo hacia ya el navegador, que es quien lleva la sesion del comprador: los dos ficheros de JavaScript caen a su propio fetch cuando ese HTML viene vacio, o sea siempre. No se pierde nada al quitarlo.

Medido tambien lo que no pasaba, para no contarlo de mas: esa peticion no creaba visitantes falsos en las estadisticas. Antes y despues de cinco llamadas, ps_guest y ps_connections se quedan clavadas en 416 y 446.

Codigo que no ejecutaba nadie

• 176 lineas del JavaScript del indexador (de 530 a 354). Dos pantallas enteras —reindexado con barra de progreso y refresco de estadisticas— se enganchaban a once identificadores que ninguna plantilla del modulo define, comprobado uno a uno. Con ellas se van sus tres ayudantes, que no llamaba nadie mas, y las once reglas de CSS de esa barra de progreso.
• 49 lineas del controlador General: copias de dos hooks del modulo y una segunda implementacion de la cola de reindexado. Son metodos hookXxx() dentro de un controlador, y PrestaShop despacha los hooks a modulos, asi que no se ejecutaban nunca. La prueba de que llevaban tiempo muertas es que esa copia seguia mirando _PS_MODE_IMPORT_, la constante que la 1.4.32 ya corrigio en el hook de verdad. Las implementaciones vivas, en el fichero principal, no se tocan; la cola que usan el cron y el modulo tampoco.
• config/services.yaml, que no leia nadie: PrestaShop busca literalmente services.yml, comprobado en 1.7.8.11 y 8.2.8. Y no se podia simplemente renombrar, porque activarlo habria intentado construir por autowiring clases con dependencias que no sabe resolver. Con el se va la extension de Twig que solo existia para que ese fichero la registrara: el modulo no tiene ni una plantilla Twig.

Escaparate en seis idiomas

Lo que ve el comprador (los 141 rotulos del buscador) sale ahora tambien en frances, aleman, italiano y polaco, ademas de ingles y español. Antes, en una tienda en esos idiomas el overlay salia en ingles. El back-office del modulo sigue en ingles y español.

Y tres textos que se escapaban de la traduccion en cualquier idioma: «Ir a…» estaba escrito a fuego en español en el JavaScript, y el contador «N results» y su etiqueta accesible, a fuego en ingles.

Multitienda: categorias repetidas y con el nombre de otra tienda

Seis consultas unian category_lang sin filtrar por tienda. En una multitienda cada categoria salia una vez por tienda en los accesos directos de los resultados, y con el nombre de la que tocara: en la tienda polaca de pruebas salian a la vez «Tonery» y «Tóner». Afectaba a los accesos directos, a «categorias mas encontradas», a las facetas y al nombre de la categoria de cada ficha.

Las busquedas populares fijadas a mano no salian nunca

Las que el comerciante pone en Importar / Exportar cuentan cero busquedas, y la lista se ordenaba por numero de busquedas antes de cortar por el limite: en cuanto las estadisticas tenian algo, las manuales quedaban fuera sin avisar. Van primero, en su orden.

El validador de Addons leia mal el nombre del modulo

Lo registraba como «Rekire Free Visual Search - Smart SearchModules.Rkfreevisualsearch.Admin»: saca el nombre juntando todos los literales de la asignacion de $this->displayName, y la llamada a la traduccion llevaba el dominio como literal. El dominio va ahora en una constante. Comprobado subiendo el ZIP: el envio 3767735 ya sale con el nombre bueno, 0 errores y 0 avisos.

Las capturas de la guia ensenaban nuestro laboratorio

Tres de las dieciocho imagenes de la guia llevaban dentro nombres de nuestro entorno de pruebas: un host de Meilisearch y el nombre de un indice en una, y un dominio local en URL de ejemplo en las otras dos. No son credenciales ni datos de nadie —son nombres de maquinas locales— pero viajan en el paquete que compra el cliente y no pintan nada ahi. Sustituidos por valores neutros.

v1.4.142026/09/08

• Nuevo Guía de uso dentro del back-office, en español y en inglés, con capturas y ayuda en cada pantalla.
• Corregido Activar Meilisearch ya no puede dejar la tienda sin servicio si su servidor no responde o es antiguo.
• Corregido Corregidos los enlaces de los banners, el mensaje de bienvenida, los diseños oscuros y los pesos en multitienda.
• Seguridad Corrección de seguridad, claves de API guardadas cifradas y todas las librerías dentro del módulo, sin CDN externos.

v1.4.132026/09/01

• Corregido El filtro de precio vuelve a permitir filtrar por el precio mínimo.

v1.4.122026/08/26

• Corregido Los colores configurados se aplican al botón de carrito y a la ventana de combinaciones.

v1.4.82026/07/23

• Nuevo Los banners admiten imagen, vídeo o productos, y se pueden generar con IA.
• Nuevo Campañas por correo a quien buscó un término, con su consentimiento registrado la primera vez que busca.
• Corregido Corregidos la ventana y los permisos de la página completa, y un fallo del editor de textos.

v1.3.72026/07/11

• Mejorado Búsqueda más afinada, también cuando el nombre del producto lleva números.
• Nuevo Opción de pasar al buscador de PrestaShop al pulsar Intro o la lupa.
• Nuevo Nuevo modo de presentación Classic, sin capa a pantalla completa, y modo de página completa operativo.
• Mejorado Mejor elección entre scroll infinito y paginación.

v1.2.332026/06/13

• Corregido Corregida la actualización del índice al guardar un producto.

v1.2.82026/04/11

• Corregido Filtros corregidos y mejorados.

v1.2.72026/04/10

• Mejorado Módulo traducido por completo al inglés, con todos los textos traducibles.
• Mejorado Retoques visuales en el back-office y en la tienda.
• Seguridad Mejoras de seguridad.

v1.2.52026/04/09

• Nuevo Color de fondo configurable para las etiquetas de la búsqueda predictiva.
• Mejorado Retoques de colores y tamaños.

v1.2.42026/04/07

• Nuevo Sección «Puede que te interese» con productos sugeridos cuando hay pocos resultados.
• Mejorado Búsqueda aproximada mejorada con el motor MySQL y mejoras visuales.

v1.1.02026/04/05

• Nuevo Banners programables en la parte superior o en el lateral del buscador.
• Nuevo Posibilidad de excluir marcas de la búsqueda.
• Mejorado Aviso en los productos sin stock que se pueden seguir comprando.
• Mejorado Mejoras visuales y correcciones menores.

v1.0.272026/03/30

• Nuevo Los productos nuevos o editados se reindexan solos.
• Nuevo Precio con o sin impuestos, a tu elección.

v1.0.252026/03/29

• Nuevo Exclusión de categorías y características en la búsqueda.
• Nuevo Indexación automática por tarea programada, que detecta productos sin indexar y sincroniza Meilisearch.
• Mejorado Precarga automática de los términos más buscados y estadísticas mejoradas.
• Mejorado Búsqueda aproximada más fina, que ignora términos demasiado cortos, y mejor presentación en pantallas 2K y 4K.

v1.0.242026/03/26

• Mejorado Mejoras visuales y corrección de errores.

v1.0.232026/03/19

• Nuevo Lanzamiento del módulo.