Wishlist for PrestaShop: Why It Matters for Both Customers and Your Marketing

A wishlist looks like a courtesy: a little heart icon that lets a customer save something for later. But on a PrestaShop store it does two jobs at once that almost no other feature does. It removes a reason to leave without buying — "I'll lose this if I close the tab" — and it quietly hands you a list of exactly which products which customers want, before they've spent a cent. That second job is the one most merchants never use. This guide is specifically about getting a real wishlist working on PrestaShop and turning the data it captures into follow-up that sells, rather than letting it sit as decoration.

Last updated: June 2026.

What PrestaShop gives you out of the box (and where it stops)

PrestaShop has never shipped a wishlist in core. The classic answer was the old blockwishlist module bundled with 1.6, which PrestaShop later rewrote and re-released — again named blockwishlist — for 1.7.7+ (the 1.7.0–1.7.6 line shipped without a wishlist module at all). Availability is module- and distribution-dependent rather than guaranteed by version, so check Modules → Module Manager — search "wishlist" — and install or enable the official wishlist module if it's available for your version, or reach for a third-party wishlist module. It does the basics: a logged-in customer saves products, sees them under My account → My wishlists, and can share a list by link.

The "and where it stops" is the important part, because it's where orders and data leak away:

• Login required. The stock module only works for registered, logged-in customers. The first-time visitor — the exact person who isn't ready to buy and most needs a save button — gets nothing.
• No follow-up. It stores the list. It does not tell the customer when a saved item drops in price or comes back in stock, and it doesn't tell you what's piling up on lists. The marketing value is captured and then thrown on the floor.
• Listing-page friction. Out of the box the save action lives mainly on the product page. The category and search results — where people browse fastest and compare most — often don't carry an obvious heart, so the save never happens.

None of this means the native module is useless. It means a wishlist is one of those features where the gap between "technically present" and "actually earning" is wide, and closing it is cheap relative to what it returns.

Why customers actually use a wishlist

It helps to be precise about the jobs a wishlist does, because each one maps to a setting you control. Customers save for a handful of distinct reasons:

• Deferred intent — "not now, but yes." Browsing on a commute, waiting for payday, talking it over with a partner. Without a save button the product has to be re-found from scratch, and on a phone that usually means it never is.
• Building a set over time. Someone kitting out a home office adds a desk one week, a chair the next, a monitor arm later — then buys the lot. Miss the save and you sell the desk while a competitor sells the chair.
• Gifting and sharing. A shared wishlist is a customer recommending your products to their own circle by name. Each shared link is a tiny, targeted referral you didn't pay for.
• Comparison shortlisting. Some shoppers use a wishlist as a holding pen while they decide between options. That's a related-but-different job — when the real question is "which of these two," a side-by-side is the better tool. We cover that in the product compare feature.

The thread through all four: a wishlist exists to defeat forgetting. Its whole value depends on the customer being able to save in one tap, from anywhere, and on something reminding them later. A wishlist that requires an account and never follows up has been built to fail at its own job.

The marketing data most merchants throw away

Here is the part that separates a wishlist as a feature from a wishlist as an asset. Every add is a recorded statement of intent attached to a specific product and, when the customer is known, a specific email address. That gives you signals you otherwise have to guess at:

• Price sensitivity. When someone saves instead of buying, price is frequently the held breath. That makes a "an item on your wishlist just dropped in price" message one of the most relevant emails you can send — it reaches a person who already chose the product and was waiting on the number. (How you set those prices in the first place is its own craft: see the psychology of pricing.)
• Demand and stock signals. A product wishlisted heavily but rarely bought may be priced past where your audience will go. One that's wishlisted and then sells out fast is a reorder flag. The aggregate list tells you what your catalogue's demand looks like ahead of the sales report.
• Re-engagement that isn't generic. "You have 3 saved items" beats "check out our latest offers" because it names things the customer already wanted. A returning visitor with a stocked wishlist is a far warmer lead than a cold one.

The mechanics of acting on these signals — segmenting customers, building the actual email sequences — sit in your marketing toolset rather than the product page, so we won't rebuild that here. The point for this guide is upstream: if your wishlist can't capture the signal in the first place, there's nothing to act on.

Doing it properly on PrestaShop

A wishlist that earns its keep comes down to four decisions. Each maps to something you can verify in your back office or a module's configuration.

On a practical level, the first thing to check is where the button renders. The product-page area is commonly reached through displayProductActions (the button slot beside add-to-cart) and displayProductAdditionalInfo, but listing-page support isn't a single guaranteed hook across themes — older modules lean on displayProductListFunctionalButtons, which is legacy and theme-dependent, so the reliable check is whether your active theme's product-list templates actually expose a slot the module can render into. If a wishlist module only hooks the product page, your category and search pages — usually your busiest browsing surfaces — stay heartless. When you evaluate any wishlist tool, that's the single most useful thing to confirm: does the save appear on a category grid, or only after the customer has already committed to one product?

Where MPR Wishlist fits

This is exactly the gap our MPR Wishlist module was built to close, on PrestaShop 1.6.1 through 9, configured from the back office rather than a developer invoice. So what does that actually change?

• Guests can save. The save works before login (toggleable via the guest-wishlist setting), so the first-time visitor — the one who isn't buying today — keeps the product instead of forgetting it. The list persists when they later create an account.
• The heart shows up where people browse. It registers on the product-list functional-button hook, so the save sits on category and search pages, not just the product page — closing the listing-friction leak above.
• Price-drop alerts are built in. When a saved product's price falls, the customer who saved it can be notified — turning stored intent into the high-relevance "your saved item is now cheaper" nudge, automatically, without you exporting lists by hand.
• Sharing without a login wall. Shared lists open from a link, so a gift recipient or friend sees the products without being forced to register first.
• GDPR-clean. It plugs into PrestaShop's customer data export and erasure hooks (actionExportGDPRData, actionDeleteGDPRCustomer), so saved-item data is included in a data request and wiped on deletion — peace of mind you don't have to engineer yourself.

It also keeps its footprint light — the front-end assets load through actionFrontControllerSetMedia rather than being dumped into every template — so the save button doesn't drag on the page-speed score you've worked to protect.

Wishlist, compared to its neighbours

A wishlist is one of several "help the customer not lose the thread" features, and it's worth being clear on which does which so you don't bolt on three modules that overlap:

They're complementary, not competing: recently-viewed catches the in-session forget, compare resolves the tie, and the wishlist owns the across-sessions save plus the marketing data. Used together they cover the full "I'm interested but not buying right now" spectrum.

How a wishlist earns its place beyond the save

Two second-order benefits are worth naming because they affect revenue, not just convenience. First, basket size: a customer assembling a set on a wishlist over time often buys several of those items together when they finally convert, which is precisely the kind of multi-item order you're trying to encourage elsewhere — see growing average order value. Second, it gives your cross-sell and upsell suggestions somewhere useful to land — a "goes well with your saved items" prompt is welcome in a way a random recommendation isn't, because it's anchored to something the customer chose.

How to tell whether it's working

Don't judge a wishlist on installs or save counts alone — a saved item that never converts is a stored regret. Watch three things over a meaningful window (at least 30 days, so you're seeing a trend and not week-to-week noise):

• Wishlist-to-purchase rate — of items saved, how many eventually get bought. A low number points at pricing, weak follow-up, or stock problems, not at the wishlist itself.
• Guest-save adoption — if you've enabled guest saving, how much of your wishlist activity comes from not-yet-registered visitors. This is usually the biggest hidden source of saved intent the login-walled native module was discarding.
• Alert-driven return rate — when a price-drop or back-in-stock alert goes out, what share of recipients come back. This is the lever that converts the stored list into actual orders.

Read together, those three tell you whether your wishlist is doing both of its jobs — keeping interested customers from forgetting, and feeding you the intent data to win the sale back. Most stores treat it as the heart icon and stop there. The ones that wire up guest saving, listing-page buttons and price-drop alerts turn a courtesy into one of the few features that helps the customer and the marketing team in the same click.

Frequently asked questions

Does PrestaShop include a wishlist by default? Not in core. The classic blockwishlist module shipped with 1.6, was dropped from 1.7.0–1.7.6, then rewritten and re-released (again as blockwishlist) for 1.7.7+. Availability depends on your version and distribution, so check Modules → Module Manager and search "wishlist" before assuming you have one.

Why does the native wishlist need a login? Because the stock module only stores saves against a registered, logged-in customer — which excludes the first-time visitor, the exact person who isn't ready to buy and most needs a save button. Guest saving (storing against a cookie until they register) is the single biggest source of saved intent the login-walled module discards.

Why doesn't my save heart show on category and search pages? Out of the box the save action lives mainly on the product page. Listing-page support depends on whether your active theme exposes a slot the module can render into — older modules lean on the legacy, theme-dependent displayProductListFunctionalButtons hook. If a wishlist only hooks the product page, your busiest browsing surfaces stay heartless; confirm listing-page rendering before you trust any wishlist tool.

What's the most valuable thing a wishlist captures? Recorded intent tied to a product and, for known customers, an email. That powers the highest-relevance follow-up you can send — a "your saved item just dropped in price" or "back in stock" alert reaching someone who already chose the product. The aggregate list also reads as a demand signal ahead of your sales report.

Is saved wishlist data covered by GDPR? It should be. A wishlist that plugs into PrestaShop's actionExportGDPRData and actionDeleteGDPRCustomer hooks includes saved-item data in a customer's data request and wipes it on deletion — so you're not engineering compliance for it separately.