Visual Search Module (No SaaS): The self-hosted Intelligent Search Engine with Meilisearch option

v1.5.42026/11/12

• A product that was out of stock and had "Allow orders" enabled appeared in the search results as sold out and without a purchase button, even though it could be purchased from the product page. The search engine was reading that option from a source that the PrestaShop 8 and 9 product page no longer updates. Now it reads it from the same source as the product page, and the same applies to "Hide out-of-stock" items and the Meilisearch index.
• With stock management disabled in the store, every product can be ordered, just like on the product page.

v1.5.32026/11/11

• The search engine prices now reflect the VAT rate of the customer group, just like the product page and listings in PrestaShop. A group configured to display prices without tax (for example, the professional group) was seeing prices with tax in the search engine. Now, the prices are consistent across the product pages, the price filter, and the combination selector.
• The "Show prices with taxes" option is as follows: when turned on, it follows each customer's group; when turned off, it always excludes taxes.

v1.5.22026/11/11

• Quick checkout: the quantity and add button are on a single row, with a single icon button, like the listings in most themes. Even when the product is already in the cart, it still displays "− N +".
• The button's hover color used to be pure red on a black background. Now it's dark gray; stores that hadn't changed it automatically hover over it during the update, and a color chosen in Appearance is retained.
• "On Sale" filter: a fixed price without a discount (such as a group rate for professionals) no longer counts as a sale. In a store with group rates, this filter used to mark almost the entire catalog. Now it counts the same as the discount tag on the card.

v1.5.12026/11/11

• Products hidden from visitors by another module no longer appear in the search results: not in the dropdown menu, the results page, or featured products, and they are not included in the total results or filters. The search engine uses a hook to ask the question. actionRkrFilterVisibleProductIds (receives ids by reference and removes those that are not visible); it is used, for example, by RKR Private Products to show certain products only to a list of clients.
• The search engine's Add button rejects those products even if their ID is sent manually.
• With such a module installed, the results cache is saved per client: what one client sees from the list is not served to another visitor, and vice versa.

v1.5.02026/11/11

For stores whose customers make purchases directly from the search engine. The new options are located in Appearance, in the "Buy from search engine" section.

• Visible offers: Discounted products display a "-20%" label (or "-€5.00" if the discount is a fixed amount) above the photo, along with the previous price crossed out, as shown in the product details. Products that only have the PrestaShop "On Sale" label display "On Sale!". Specific prices and catalog rules applicable to the customer are taken into account; the discount for their product group is not, as it is their regular price. This indicator is enabled upon updating (it is disabled in "Discount and Previous Price").
• "On Sale" filter in the search engine filter panel and on the results page, showing the number of discounted products among those found. It only appears if there are any. It's checked during search, not during indexing, so a sale that starts or ends today is counted without being reindexed. Enabled upon update.
• Quick Checkout (disabled upon update): The quantity and Add button are always visible on each product, not just when hovering. As soon as the product is in the cart, the button changes to "- quantity +" with the number of units already in the cart: changing it leaves that quantity in the cart (entering 12 leaves 12, it doesn't add 12), and changing it to 0 removes it. If the cart is updated from the header, it will be updated. This applies to products without combinations; others still display "Choose option."
• Stock as a traffic light (off when updated): a green dot indicates stock, amber indicates few units ("Last units"), and red indicates out of stock. "Few" means below the number set in "Few units from", or, if set to 0, below the PrestaShop setting "Show remaining quantities when less than".
• Fixed: The "Add" option used to say "Added to cart" even though the store hadn't actually added it (another module removes it immediately). Now it notifies the user that the cart couldn't be added.
• Fixed: With debug mode enabled, notifications from other modules appeared before the cart response, and the button displayed a "Connection Error." No action is required during updates: the search cache is automatically cleared.

v1.4.642026/11/11

• Fixed: On the search results page, the "Show price" Appearance setting was not being respected, and the price was always displayed. The dropdown search box did respect it. Customer groups without permission to view prices were already covered from the 1.4.58, in both views. No action is required when updating.

v1.4.632026/11/10

• Full product name on hover: If the name doesn't fit on the card and is cut off by "...", hovering the mouse over it displays a bubble with the full name at the bottom of the image. It doesn't cover the price or move the grid. This feature is only available on computers (there's no "hover" function on mobile). In shoe stores, for example, the model and color didn't fit on two lines.
• In the Clean and Superclean styles, the name goes up to 3 lines (previously 2): without a frame around the product, the fact that some names take up an extra line is not noticeable, and thus many fewer are cut off, also on mobile.
• Fixed: In the suggestions above, the full text displayed when hovering over the name showed "&" instead of "&" for names containing that symbol. No action is required after updating.

v1.4.622026/11/09

• Fixed: Out-of-stock products that can be ordered ("Available on request": the product, or the store, accepts orders for items not in stock) previously had a "Check" button, and clicking it resulted in an "Insufficient stock" error without adding anything. Now they have an "Add" button and are added as in the product details. This is particularly relevant for stores that sell a lot of made-to-order items (as seen in...). lacasadelassetas.com: 912 out of 1,519 products) the button did not work in more than half of the catalog.
• Fixed: In the "Choose option" window, a variant that was out of stock but available to order was showing as "Out of stock" and could not be added. Now it shows as "Available on request" and can be added.
• The mobile's floating "Filters" button can be painted with the store's color: read --rkfvs-filter-toggle-bg and --rkfvs-filter-toggle-text (By default, as before: the main color and white text). Previously, the color was fixed inline and there was no CSS to change it.

v1.4.612026/11/09

• New option "Remember search on back" (General). If a customer selects a product from the search bar and returns using the Back button, the panel reopens exactly as it was: the same search results, filters, sort order, products already loaded, and positioned at the same level as the product they viewed. Previously, they would return to the page with the panel closed and have to search again. If they manually close the panel, it won't reopen upon returning. This option is disabled by default after the update; toggle it, go to Settings > General.

v1.4.602026/11/07

• A single letter alongside other words counts: "vitamin C" prioritizes the C vitamins (previously, searching for just "vitamin" would return D3, B12, etc.). The same applies to "vitamin E," "vitamin K," and so on. The letter must be part of a complete word in the name: "C" doesn't match "complex." A single letter still isn't searched for. No action is required during the update.

v1.4.592026/11/07

• The stock status ("In stock", "Available on request", "Out of stock") reappears on the panel cards for groups that do not see prices. 1.4.58, Hiding the price per group also meant getting the stock label.
• "Clean" and "Superclean" styles: the filter block is much more compact, both in the panel and on the results page (each closed filter takes up half the height). No action is required after updating.

v1.4.582026/11/07

Prices only for those who can see them

• The search engine respects the "Show prices" setting for customer groups (Customers > Groups). In a B2B store with the Visitor group (without prices), the results panel and page displayed the price and the "Add to Cart" button. Now, for those groups, neither the price, nor the price filter or sorting, nor the cart button appear, and the search engine's cart feature rejects the request.
• The results cache is stored by customer group and currency: it no longer serves prices from one group to another.

The first letter is no longer lost

• When you tap the theme's search box and type immediately, the first letter would stay in that box ("protein" searched for "rotein"). The focus shifts to the panel's search box with the same tap, and if anything appears in the theme's search box, it's brought to the panel. No action is required when updating.

v1.4.572026/11/05

JavaScript error when adding a form to the page

• If another module or theme added a form to the page with a field called id, the console displayed node.id.startsWith is not a function, And the search engine stopped removing the native autofill that appeared with that form. No action is required after updating.

v1.4.562026/11/04

PrestaShop Addons Validator Ready

Code review with no new features. No further action is required during the update.

• The warning about unindexed languages never appeared: your query carried a LIMIT Too much. With debug mode active, that SQL error broke the screens of the module that displayed it. It comes from the 1.4.39.
• The sorting of results uses the language and store of the current search, not those of the global context. This is noticeable in the cache warm-up task, which iterates through all languages and stores: it now sorts each one by its synonyms and weights.
• The warning about unindexed languages comes from a template, not from PHP.
• The examples in this log and the code comments no longer name specific stores.

v1.4.552026/11/04

Multistore: each store is searched using its own text

If a product had a different name in two different stores, the search engine would use the name and description from the latter for all of them: renaming it in one store would prevent it from appearing in that store, and the same applied to category names. Now, each store has its own text index, with its own weights and excluded characteristics, regardless of which store the product is saved from.

It also fixes what depended on the store from which it was saved:

• Deactivating or hiding a product in one store used to remove it from search results across all stores. Now it only appears in that specific store.
• A product saved from a store where it is not available would disappear from the search engine of the stores where it was available.
• "Available" is taken from each store's stock. With stock shared between stores, products were indexed as out of stock in all of them.
• Rebuilding the index includes products from all stores, not just the store from which the update is launched. After updating, in a multi-store setup, products are automatically reindexed in batches using cron. If you don't use cron, click "Rebuild Index." With a single store, no action is required, and no index rows will change.

The same order in each search

Products with the same rating could change order between two identical searches, and a product could be repeated or missing when browsing the page. Now, in cases of a tie, the most recent product appears first.

v1.4.542026/11/04

Saving a product without changes no longer rewrites the index

A connector to the ERP system used to store thousands of products even when nothing had changed, and each save would delete and reinsert all the product's rows into the search index. Now, the search engine saves a single record of each product, and if nothing has changed, it doesn't write anything. The index table stops growing, and saving is much faster.

When something does change, only the difference is written: renaming a product affects two or three words, not hundreds of rows. If only sales or stock change, those columns are updated. After updating, reindexing is unnecessary: the first time each product is saved, it's compared to what's already in the index.

Saved searches stop being emptied for no reason

The search cache used to be cleared every time a product, category, or manufacturer was saved, and also every time any module cleared one of its templates, which many theme sliders do when saving a product. Now it's only cleared if something has changed that affects the results: text, price, categories, manufacturer, combinations, features, or if the product is available for purchase. The "Clear cache" button in the back office also clears it, which it didn't do before.

The reindexing queue does not lose products

Products not currently indexed (imports, large batches) used to wait in a list of 500, which, when full, would skip the oldest ones, leaving them with the old index. Now they're in their own table, without a limit, and the cron job advances based on time (25 seconds per run) instead of a fixed 100 products. Upon completion, it clears the cache if anything has changed and sends the changes to Meilisearch.

Faster multi-word searches

The weight of each word counted the products in the index for every search of two or more words, even when serving from the cache. Now that total comes from a direct query: in a catalog of 10,000 products, it's the difference between seconds and milliseconds when the database is running low on memory.

v1.4.532026/10/28

Mobile results page

On screens smaller than 768px, filters no longer appear next to products at a fixed 280px (preventing the list from being squashed in all styles). Now they appear on top, folded behind a "Filters" button that opens and closes them; they remain open when a filter is applied, and products are displayed two at a time. Nothing changes on desktop.

v1.4.522026/10/28

"Clean" and "Superclean" styles for results

Two new styles in Appearance → Quick Design Presets, for the search panel and for the results page:

• CleanEverything is white, with no border around each product. The photo, along with the name and price, appears against a very light gray background. When you hover over the photo, it fades slightly, and the name is underlined, without any gaps or shadows. The filters no longer have their boxes and are separated by a thin line. In the panel, the button that appears when you hover over it is now at the bottom of the photo and no longer covers the price.
• SupercleanThe same applies, but without banners or a welcome message, and without the store's color scheme: labels, buttons, price bars, and separator lines (filters, "Exact Match") are all changed to black and light gray. Stores already using a different style remain unchanged.

v1.4.512026/10/28

With several words, the most specific one commands.

When searching for two words, one very common in catalog names and the other unusual ("cotton t-shirt" in a store where almost everything is a t-shirt), products that only had the common word ranked higher than those with the unusual word, simply because they started with the first word. Now, each word is weighted according to how many product names it appears in: the unusual word counts more than the common one. Products with both words still rank higher. There's no need to rename products.

Empty words ("with", "for", "of", "the", "with"...) have no weight and alone do not put a product in the results: a product with "(with gift)" in the name no longer rises because of that, and a search like "collared t-shirt" stops returning half the catalog.

Variants window without a horizontal bar and without repeated names

• The name of each variant used to appear once for each image in the combination ("Color: Red / Color: Red / Color: Red…"). Now it appears once and only with what distinguishes the variant: the value, without the group name, and without the groups that have the same value in all of them ("Red" and not "Color: Red / Size: One Size").
• On mobile, the window had a horizontal scroll bar: the name was on a single line. Now it spans two lines, and the quantity and "Add" are below, so each row fits across the width. The upgrade removes the combined CSS/JS from the store and the search cache.

v1.4.502026/10/28

The cards respect "Show price" and "Available for order"

A product with "Show price" disabled appeared in the search results at €0.00, with "Available on request" and an "Add to cart" button: what a store simply wants to showcase (a catalog of machines, a custom-made product) seemed like a gift and could be purchased. Now the card behaves like a PrestaShop product page: without "Show price" (or in catalog mode without prices), it displays no price, stock level, or purchase button; without "Available on request," it shows the price, but not the stock level or the button.

Price 0: "Request price and availability"

A product with a price of 0 and the price displayed shows text instead of €0.00, without a stock label or a buy button. The text can be configured by language in Appearance → Card Details.

The stock label no longer covers the price

The label used to move up 25px to position itself next to the price, and a long text ("Available on request") covered it up. Price and stock are now in a row, and if there isn't enough space, the label moves underneath.

A feature under the name, which is searched for as the reference

In Appearance → Card Details, you select a feature (for example, the manufacturer or OEM reference) that the card displays below the name (two lines maximum). Its values are also indexed with reference codes and are represented as "Ref:": searching for one of these codes brings up the product first. You must reindex after selecting it.

Type label by feature

You choose a feature and one or more of its values (for example, Family = Machine). Your products will display the value as a label above the name and, instead of a buy button, a label will link to the product page with the configured text ("See compatible products" if left blank).

"Go to…": first the category that has the same name as what you are looking for

The categories used to be determined by depth and position: a model code would more readily reveal categories that contained it within another word ("MX2000", "FMX200S") than those that contained it entirely ("Office MX200"). Now, name similarity is key: same, whole word, starts with, contains it.

The desired model is released before its consumables

Searching for a model code would give an exact match to a product whose name began with that code followed by another number ("MX2000" for "MX200"). And the product with that name ("Office MX200") would score the same as the hundreds of consumables "for Office MX200..." and, all else being equal, sales figures would prevail, which a catalog product doesn't have. Now, adding another number means it's no longer the same code, and a short name ending with the searched code comes first.

Updating clears the search cache, which stored the cards with the old price.

v1.4.492026/10/26

The search engine's magnifying glass is no longer hidden from screen readers.

By converting the theme search magnifying glass into a button (with focus, role="button" and his aria-label), the module left the aria-hidden="true" that comes with the ps_searchbar template. An element that receives focus cannot be hidden: Lighthouse marked it as "The elements [aria-hidden=true] "They contain selectable descendant elements," and the accessibility score would drop. Now, that attribute is removed upon conversion. Only the JS changes; there's nothing to update in the database.

v1.4.482026/10/21

Find what is written by ear

A misspelled word that isn't in the index is also searched for by how it sounds in Spanish: "kolageno" finds "collagen", "proteyna" finds "protein", "kafeina" finds "caffeine", and "bitamine" finds "vitamin". Previously, it would fall into the trap of approximate search, which accepted words from descriptions that only resembled each other in letters ("oxigeno" for "kolageno") and filled the results with unrelated products.

Rules: h is silent; w and hu sound the same; k, c, and qu also sound the same; ce, ci, and z; ge, gi, and j; b and v; y and i; double letters count as one, and the final vowel doesn't matter. A correctly spelled word is searched as is, so what already worked doesn't change. Synonyms of the found word also count ("kolageno" → "colageno" → "collagen").

A search with no match doesn't get filled with just anything.

The last-resort search method compared three-letter snippets to names: "biscuit" would bring up products with "bis" in the name, followed by eight more in the same category. Now it only uses near-complete variations of the word; if nothing matches, there are no results and popular searches appear.

The upgrade creates the phonetic key table and fills it with the words that are already in the index, without reindexing, and empties the search cache.

v1.4.472026/10/21

A complete model reference comes first

When searching for a model reference using letters and numbers ("et-14100", "ET 14100", "et14100"), products containing it in their name could rank hundreds of places lower, for two reasons:

• The short part held hundreds of products. Just like the short number in the 1.4.46, A one- or two-letter part ("et") matched as a prefix with labels and any other "ET-..." model. Now, if the search has a longer part, a product has to match at least that part.
• The sold-out items went to the very end of the list., ...even behind "You might also like." Now they're at the end of their own block: an out-of-stock exact match still ranks ahead of related matches. Furthermore, a model reference that's in full in the name counts as an exact match, with or without the hyphen: "et14100" matches "ET-14100," but not "ET-141000." The upgrade clears the search cache.

v1.4.462026/10/20

A short number is no longer enough to get into the results

The 1.4.45 It stopped counting isolated short numbers when sorting, but the query still included any product with that number in the description or features in the results: "whey 80" would bring up products with "80 capsules" or "800 mg," and since the names didn't match, they would appear in "You might also like." Now, if the search includes words and a one- or two-digit number, a product must match at least one of the words. With few results, the block is filled with products from the same category, as in the 1.4.45.

The upgrade clears the search cache.

v1.4.452026/10/20

Synonyms also count when ordering

The search already looked for synonyms ("protein" → "protein"), but the step separating exact matches, related matches, and "You Might Also Like" only compared the typed word with the product name. Everything found as a synonym fell into "You Might Also Like" and was sorted by sales, so the best-selling product appeared first even if it was unrelated, and a search with a misspelling would show that label at the top. Now, a word matches the product if it matches itself or one of its active synonyms, and "protein" sorts the same as "protein." Enabling "Promote Exact Matches" on and off is sufficient.

A single short number no longer relates to a product

With several words, matching just one or two digits was enough to get you into related items and score points: with "omega 3" you'd get a "Pack 3" of something else or a "30g" format ahead of the omega ones. Now the number only counts if it also matches a word.

"You might also like" with few results, without Meilisearch

A search with fewer than 8 results is supplemented with up to 8 products that share the same category: first the most specific category they share (a subcategory before its parent category; the root and home categories are not counted) and then the best-selling products. It respects excluded categories and manufacturers and the "Hide out-of-stock" option. Only relevance ordering is used, without filters. Previously, only Meilisearch offered this functionality, and only when no results were available.

The upgrade clears the search cache, which stores the final order.

v1.4.422026/10/15

Broken images from other modules no longer disappear

The search engine was listening for loading errors all The page's images were hidden, and any that failed, even if they weren't its own, were also marked with a "no image" icon. An image that another module creates empty and then fills in—the QR code for a shopping cart sharing modal, for example—remained hidden forever.

Now, only images within the search engine, its results page, or its banners are processed. Nothing changes within the module itself: a product image that fails to load is still replaced by the icon.

v1.4.412026/10/15

Other modules can now save the shopping cart after saving a product.

When you save a product, the search engine indexes it and needs a shopping cart in the context to calculate the price (without it, Product::getPriceStatic() does die() in PrestaShop 1.7.8, 8.2 and 9.0). If the context cart did not yet have an ID, it was changed to a new Cart() Empty, without currency. In the shop window, that cart without an ID is the one PrestaShop prepares for the visitor, so any module that saved a product from the store and then the cart failed with "The Cart->id_currency property is empty." Seen with a garment customizer: the first design of each product didn't fit into the cart.

Now a cart is only created when there is none (console, web service), and it is filled in as the core does: language, currency and store.

The "add to cart" button on the panel also saves the cart that the store had already prepared instead of creating another one, so it retains the visitor (id_guest) like the normal PrestaShop shopping cart.

v1.4.382026/10/08

When typing, the results appear above, not below, the welcome message.

Seen on iogenixdise (PS 8.2) when searching for "Isolate": with the query typed, the panel continued to show "Popular Searches" and "Best Sellers", and the results, with the exact match at the top, were ~1,580 px from the top.

It used to be a race. When the panel opened, the server would request a welcome message, and if the client typed before it arrived, the response would overlay the welcome message on top of the results. Now, that request is canceled as soon as a query is received, and if it was already in progress, it wouldn't be overlaid. With the welcome message intentionally delayed by 4 seconds, the results are now 192px wide and the first tab is 236px wide, without the theme's CSS.

The block containing your own message, links, and "Most Found Categories," which only appears with a search, moves from above the results (169 px) to behind them.

One search, one request

• Each query was sent to the server twice.rkrfreevisualsearch-nav.js wrapped executeSearch with _origExecute(query).then ? _origExecute(query)…The check already launched the search and the branch launched it again.
• When I opened the panel, 2 or 4 empty searches appeared. One asked for "featured products" with featured_only, a parameter the server has never read, and the response was irrelevant: it was removed. Furthermore, the topic calls for open() with the focus and with the click of its box, and the second call repeated the welcome and erased what was written: now it does nothing if the panel is already open.
• Filters, order, and limit did not cancel the previous search. And two responses could arrive in any order. Now every search cancels the one that's in progress, and an old response is discarded even if it arrives (including "load more" and autocomplete responses).

Autocomplete took as long as a whole page

autocomplete.php I was calling parent::initContent(), which in PrestaShop assigns page variables and executes displayHeader with the hooks of all the store modules. In iogenixdise it was 3.6 s for each request, also with autocomplete turned off, because the check came later. Now it's 0.1–0.2 s (0.9 s the first time). search.php He never did. addcart.php It used to do the same thing and it also stopped doing it: adding to cart from the panel, 0.17 s.

The autocomplete strip, with thumbnail and without covering anything

It floated above the panel (position: absolutePreviously, it covered popular searches and only displayed text. Now it's in the flow, above the results column, in a single row that scrolls horizontally (~70px), and each product has its own thumbnail: the server was already sending image_url. The input on a suggestion marked with arrows did nothing (the list it read was always empty) and now it opens it.

The search engine took seconds to find stores with order history.

Measured in maesalv9 (PS 9.1.4, 1,083 products, 535,838 order lines):

• Product sheets (ProductDataProvider::getProducts): the units sold totaled order_detail + orders Each request takes approximately 1 second per product sold. When opening the search engine (empty query), the 12 "best sellers" took 9.8 seconds. Now they appear in rkrfreevisualsearch_index.total_sold, The indexer already calculates the same sum (same numbers); only the non-indexed data is calculated as before. Empty query: 10.1 s → 0.22 s; "ceramico": 2.4 s → 0.4 s. The responses are identical byte by byte.
• AutocompletePreviously, files were compiled for up to 80 candidates to show 8, and then those that didn't match were discarded (1.7 seconds). Now, the system filters beforehand using name, reference, and EAN from a query, and only the following are compiled: limit * 2 cards. 2.2 s → 0.15–0.4 s, same suggestions. In iogenixdise (PS 8.2, 346 products, 578,153 order lines), "Isolate" goes from 12 s to 0.3 s without caching, and the empty query from 5 s to 0.24 s. Fuzzy search (FUZZY, threshold 60) and MAX_PRODUCTS_QUERY=100 They were not the bottleneck: a query without results, which travels through the diffuse, takes 0.49 s.

Update

upgrade-1.4.38.php just call Media::clearCache()With JS/CSS "Smart cache" enabled, the store would still serve the old bundled package.

v1.4.372026/10/05

A single image or video banner crashed the entire store in PrestaShop 9.2

With an active image or video banner, the homepage and product pages in PrestaShop 9.2 would produce a fatal error, not just the search function: SmartyException: Template './_banner-overlay.tpl' cannot be relative to template of resource type 'module'. . _banner-media.tpl included the banner text with a relative path (./_banner-overlay.tpl), and Smarty 9.2 no longer supports relative paths within a template loaded as module:.

Now included with your full route (module:rkfreevisualsearch/views/templates/hook/_banner-overlay.tpl), like the rest of the front-end templates. No upgrade is needed: it's just the template. Reproduced in 9.2.0 with the previous version and tested with the new one in 9.2.0, , 9.1.5, , 9.0.0, , 8.2.8 and 1.7.8.11 (Homepage with an image banner at the top and a video banner on the side, and the results page). The include The back-office relationships don't change: those templates are loaded via file path and also work in 9.2.

v1.4.362026/09/30

The Meilisearch key "was not saved"

A customer reported this. The password was saved, but the screen said otherwise and it ended up shutting down Meilisearch. 1.4.33 The saved key no longer travels to the browser—the field always appears empty—and the screen's JavaScript continues to infer "no key" from an empty field: upon loading, it disables and blocks the switch and displays "API Key is required." Since a disabled checkbox is not sent, the next saved checkbox sends the 0 from the hidden field and deactivated Meilisearch. And if it was forced, PHP would reject the saving for the same reason, because it was also only looking at the field.

Now the template says if there is a saved key (data-key-setJavaScript takes this into account, while PHP only requires the key if the field is empty. and None saved. Played on 9.2.0 With the previous version and tested with the new one: saving with a password, reloading and saving again without writing it leaves Meilisearch activated and the password intact.

v1.4.332026/09/28

Cleanliness. No functionality changes for the merchant; what changes is what the module does under the hood and what travels within the package.

Each "add to cart" action sends an HTTP request from the server to itself

When adding a product from the search engine, the controller requested the mini-cart HTML via cURL. to the store itself, with a two-second delay, within the purchase path. It was useless: it pointed to the module. blockcart, that It has not existed since PrestaShop 1.7 —the native cart block is ps_shoppingcart—, so the request returned a 404 error and the HTML always arrived empty. Measured in 8.2.8: HTTP 404 and 47 bytes.

What was costly was time. In a store that can't reach itself due to its public domain—Cloudflare in the way, split-horizon DNS, a load balancer, or a certificate that cURL doesn't validate—it was a full two seconds with each click, right on the screen where the customer decides.

The browser, which manages the buyer's session, already handled the refresh: the two JavaScript files were dropped into their own fetch When that HTML comes empty, which is always the case, nothing is lost by removing it.

Also measured what No To avoid going into too much detail: that request didn't create fake visitors in the statistics. Before and after five calls, ps_guest and ps_connections They remain stuck at 416 and 446.

Code that no one was running.

• 176 lines of indexer JavaScript (from 530 to 354). Two entire screens—reindexed with progress bar and statistics refresh—were glued to eleven identifiers that no module template defines, checked one by one. With them go her three assistants, whom no one else called, and the eleven CSS rules of that progress bar.
• 49 lines of the General ControllerCopies of two hooks from the module and a second implementation of the reindex queue. These are methods hookXxx() within a controller, and PrestaShop dispatches the hooks to modules, so they were never executed. The proof that they had been dead for a while is that this copy was still looking _PS_MODE_IMPORT_, the constant that the 1.4.32 It's already been fixed in the actual hook. The live implementations in the main file are not touched; neither is the queue used by cron and the module.
• config/services.yaml, which nobody read: PrestaShop literally searches services.yml, verified in 1.7.8.11 and 8.2.8. And it couldn't simply be renamed, because activating it would have attempted to autowire classes with dependencies it couldn't resolve. With it goes the Twig extension that only existed to register that file: the module doesn't even have a Twig template.

Showcase in six languages

What the buyer sees (the 141 labels in the search engine) now also appears in French, German, Italian, and Polish, In addition to English and Spanish. Previously, in a store in those languages, the overlay appeared in English. The module's back office remains in English and Spanish.

And three texts that escaped translation in any language: «Go to…» was written in Spanish in the JavaScript, and the «N results» counter and its accessible label, in English.

Multistore: repeated categories with the name of another store

Six consultations united category_lang Without filtering by store. In a multi-store, each category appeared once. per store in the shortcuts of the results, and with the name of the one that was selected: in the Polish test store, both "Tonery" and "Tóner" appeared. It affected the shortcuts, "most frequently found categories", the facets, and the category name of each listing.

The popular searches that were manually set never came up.

The entries the merchant adds to Import/Export count as zero searches, and the list was sorted by search volume before being cut off at the limit: as soon as the statistics showed anything, the manual entries were dropped without warning. They come first, in order.

The Addons validator was misreading the module name.

I registered it as «Rekire Free Visual Search - Smart SearchModules.Rkfreevisualsearch.Admin»: extracts the name by combining all the letters in the assignment of $this->displayName, The translation call was using the domain name literally. The domain name is now a constant. Confirmed by uploading the ZIP file: submission 3767735 now uses the correct name, with 0 errors and 0 warnings.

The screenshots in the guide showed our laboratory

Three of the eighteen images in the guide contained names from our test environment: a Meilisearch host and an index name in one, and a local domain in the example URL in the other two. These aren't credentials or anyone's data—they're local machine names—but they're included in the package the client buys and are completely irrelevant. They've been replaced with neutral values.

v1.4.142026/09/08

• New User guide within the back-office, in Spanish and English, with screenshots and help on each screen.
• Corrected Activating Meilisearch can no longer leave your store without service if your server is unresponsive or outdated.
• Corrected Banner links, welcome message, dark designs, and multi-store weights have been corrected.
• Security Security fix, encrypted saved API keys and all libraries within the module, without external CDN.

v1.4.132026/09/01

• Corrected The price filter once again allows filtering by the lowest price.

v1.4.122026/08/26

• Corrected The configured colors are applied to the shopping cart button and the combinations window.

v1.4.82026/07/23

• New Banners support images, videos, or products, and can be generated using AI.
• New Mail campaigns to those who searched for a term, with their consent recorded the first time they searched.
• Corrected The window and permissions for the entire page have been corrected, as well as a bug in the text editor.

v1.3.72026/07/11

• Improved More refined search, even when the product name contains numbers.
• New Option to switch to the PrestaShop search engine by pressing Enter or the magnifying glass.
• New New Classic presentation mode, without a full-screen overlay, and a fully functional full-page mode.
• Improved Best choice between infinite scrolling and pagination.

v1.2.332026/06/13

• Corrected Fixed the index update when saving a product.

v1.2.82026/04/11

• Corrected Filters corrected and improved.

v1.2.72026/04/10

• Improved Module fully translated into English, with all texts translatable.
• Improved Visual touch-ups in the back office and in the store.
• Security Security improvements.

v1.2.52026/04/09

• New Configurable background color for predictive search labels.
• Improved Color and size adjustments.

v1.2.42026/04/07

• New "You might be interested in" section with suggested products when there are few results.
• Improved Improved approximate search with the MySQL engine and visual enhancements.

v1.1.02026/04/05

• New Programmable banners at the top or side of the search engine.
• New Option to exclude brands from the search.
• Improved Notice regarding out-of-stock products that can still be purchased.
• Improved Visual improvements and minor fixes.

v1.0.272026/03/30

• New New or edited products are automatically reindexed.
• New Price with or without taxes, your choice.

v1.0.252026/03/29

• New Exclusion of categories and characteristics in the search.
• New Automatic indexing by scheduled task, which detects unindexed products and synchronizes Meilisearch.
• Improved Automatic preloading of the most searched terms and improved statistics.
• Improved Refiner approximate search, which ignores excessively short terms, and better presentation on 2K and 4K screens.

v1.0.242026/03/26

• Improved Visual improvements and bug fixes.

v1.0.232026/03/19

• New Module launch.