Registro de búsquedas en PrestaShop sin modificar el core

nuriadeco

¡Hola a todos!

Estoy intentando implementar una funcionalidad de registro de las búsquedas que hacen los clientes en la tienda. La idea es sencilla: cada vez que alguien busca algo, quiero guardar ese término para analizarlo después. He intentado hacer un override de SearchController y añadir una línea para insertar el término en una tabla, pero no estoy seguro de que sea la forma más robusta, sobre todo pensando en futuras actualizaciones de PrestaShop. Además, me gustaría que considerara el id_shop y id_lang.

Este es el fragmento de código que he puesto en override/controllers/front/SearchController.php:

class SearchController extends SearchControllerCore
{
    public function postProcess()
    {
        parent::postProcess();
        if (($query = Tools::getValue('s'))) {
            Db::getInstance()->insert('ps_busquedas_registradas', ['termino' => pSQL($query)]);
        }
    }
}

¿Alguna idea de cómo mejorar esto o si hay una forma más adecuada de hacerlo? Con mi método actual, siento que me faltan datos importantes de contexto y podría estar creando entradas duplicadas.

maria96

Hola @nuriadeco,

Entiendo tu problema. Ese override funciona, pero como dices, te faltan datos clave y es muy probable que tengas duplicados. En PrestaShop, el contexto de id_shop y id_lang es fundamental para cualquier dato relacionado con la tienda. También podrías necesitar un contador para saber cuántas veces se busca un término, en lugar de una entrada por cada búsqueda.

Para poder ayudarte mejor, ¿en qué versión de PrestaShop estás trabajando exactamente? ¿Es PrestaShop 1.7.x o alguna más reciente?

Milo

Hola @nuriadeco y @maria96,

@nuriadeco, tu enfoque de override en SearchController::postProcess() es correcto para capturar el término de búsqueda, pero como bien señaláis, la implementación de la inserción es demasiado básica para un sistema robusto.

Para un registro adecuado que considere el contexto de PrestaShop (especialmente si usas multitienda o varios idiomas, lo cual es casi estándar), necesitas incluir el id_shop y el id_lang. También es una buena práctica añadir un contador para evitar entradas duplicadas y tener un registro más eficiente. Aquí te muestro cómo podrías modificar tu Db::getInstance()->insert() para incluir estos campos y un contador inicial. Asumo que tu tabla ps_busquedas_registradas (o ps_search_words como la llamaría yo) tiene columnas para id_shop, id_lang, word, counter y date_add.

// override/controllers/front/SearchController.php (fragmento)
// ... dentro de public function postProcess()
        if (($query = Tools::getValue('s'))) {
            $id_shop = (int)Context::getContext()->shop->id;
            $id_lang = (int)Context::getContext()->language->id;
            Db::getInstance()->insert('ps_search_words', [
                'id_shop' => $id_shop, 'id_lang' => $id_lang,
                'word' => pSQL($query), 'counter' => 1,
                'date_add' => date('Y-m-d H:i:s')
            ]);

Este snippet corrige la inserción, pero para una solución más completa que maneje incrementos del contador si el término ya existe, necesitarías una lógica de SELECT antes del INSERT o UPDATE. Estas modificaciones manuales, aunque funcionan, pueden ser frágiles en futuras actualizaciones. Si buscas una solución más limpia y mantenible que te permita automatizar registro de palabras clave en la tienda sin tocar el core o crear overrides, un módulo dedicado es la mejor opción. Ofrecen una gestión más completa desde el Back Office y mayor compatibilidad.

nuriadeco

¡Muchísimas gracias @Milo! La verdad es que tienes toda la razón con lo de id_shop y id_lang. No había caído en lo fundamental que es eso para el contexto. He aplicado el fragmento de código que me has dado y he ajustado mi tabla para incluir esos campos y el contador, y ahora el registro se ve mucho más útil.

Estoy en PrestaShop 1.7.8.8, por cierto, @maria96. Así que la solución de @Milo me viene perfecta. Tomo nota también del módulo para futuras mejoras, ya que la idea de no depender de overrides manuales suena muy bien a largo plazo. ¡Problema resuelto!