PRESTASHOP + TYPESENSE
Indexing PrestaShop
in Typesense.
Typesense is an open-source search engine, written in C++, that answers a query in milliseconds because it keeps the index in memory. This page explains what it takes to put a PrestaShop catalogue inside it: which fields go into the collection, how it stays in sync, and what happens to combinations and per-customer-group prices.
Wiring PrestaShop to Typesense by hand is a few weeks of work: the schema, the syncing, the combinations, the prices. Dropfind is that bridge, already built. You can run it against your own Typesense server or against ours, and what gets indexed is exactly the same either way.
The field names and parameters on this page are the module's real ones, not an example.
THE PROBLEM
What's wrong with native search
PrestaShop's own search runs LIKE
'%text%' against MySQL, over tables that grow with the
catalogue. Three limits follow, and none of them is fixed by tuning
the database.
«lightbub» will not find «lightbulb». There is no edit distance, only substring matching. A typo is a lost sale, and the merchant never finds out it happened.
The code the customer is actually holding — the one for that size,
that colour — lives in product_attribute, and native
search does not look there. Search by it and you find nothing.
And so is every category filter: native facet counts are queries. A crawler walking filter combinations takes real shops down.
Typesense does not fix MySQL: it takes it out of the path. The index lives apart, in memory, and search queries stop touching the shop's database.
THE COLLECTION
Which fields go into the index
One collection per language. A product's name, its categories and its description all change with the language, so mixing them into a single collection would ruin relevance for every one of them.
Name, reference, EAN-13, combination references, combination text, manufacturer, categories and short description. Eight fields, each with its own weight.
query_by · query_by_weights
Category, manufacturer, attribute and feature-value ids, plus price and whether there is stock. All marked as facets, which is what lets counts happen without a query.
facet_by
Formatted price, product path, image path, quantity and how many combinations it has. That is enough to draw the result card without going back to PrestaShop.
Two fields nobody sees: the word count of the name, and a sort key with numbers zero-padded, so that «3W» comes before «12W» instead of after it, which is what plain alphabetical order gives you.
name_words · sort_key
The module creates the collection and maintains the schema. If an older install is missing a newer field, sorting degrades instead of failing: search keeps answering.
KEEPING IT CURRENT
When it reindexes, and what that costs
A separate index is only useful if it does not go stale. There are two paths here and both are automated.
The module hooks PrestaShop's events and queues the product that changed. Editing one price does not reindex the whole catalogue.
A cron drains the queue in rounds and stops before it runs out of execution time, so it leaves no hanging requests and no half-done work. Whatever is left stays queued for the next pass.
One button in the back office. Required when first connecting a shop and when the schema gains a new field.
THE PARTS THAT ARE NOT OBVIOUS
Combinations, prices and relevance
This is where the time goes if you build it yourself, which is why each one gets its own box.
Every variant's references and codes travel as a list inside the parent product's document. So searching one size's code returns the product, not a duplicate card per variant.
combination_references · combination_searchable
The indexed one is instant and right for a shop with one customer group and one currency, which is most of them. With per-group pricing (B2B), several currencies or dated promotions, the price is computed from the visitor's context and cached. The merchant picks, and the choice governs search and filters together so a product never shows two different figures.
In a catalogue with families — «Panel 3W round», «Panel 24W square» — dozens of records score exactly the same on text match. Typesense takes at most three sort fields; if all three tie, it returns its internal order and the shopper sees a list with no pattern. That is why the natural sort key exists.
sort_by · 3 fields max
Summing every field's score puts an accessory that mentions the term
in its name, description and categories ahead of the actual product.
With max_score, the best field wins.
text_match_type
TWO WAYS
Your Typesense, or ours
Same module either way. What changes is where the index lives and who keeps the server running.
Put protocol, host, port and admin key in the back office and the module creates the collection and maintains it. You handle the server, the memory the index needs, and the backups.
Connect with a key and it starts indexing. No server to stand up, no memory to size, no Typesense releases to follow. The key the shop receives is read-only, over its own collection.
Verified on PrestaShop 1.7.6 through 9.0.3 with PHP 7.3 through 8.4, against real installs at both ends of the range.
Run it yourself, or have it handed to you?
Both editions index exactly the same thing. Start wherever suits you and switch later if you want.