SaveTo Wishlist Lite – WooCommerce Wishlist

Why should I use this wishlist plugin?

We aim to create the easy-to-use wishlist experience for WooCommerce — one that helps store owners grow. It’s a feature-rich wishlist plugin that comes with everything you need to give your customers a great experience saving products to lists.

Is there a limit to the number of wishlists?

No, you and your customers can create as many wishlists as you like.

Does this plugin support variable products?

Yes, it does.

How do I add the wishlist to a page I build with Flatsome’s UX Builder?

Open the page in UX Builder, click to add an element, and choose “Save to Wishlist” from the Content category. The element has two optional settings: a Wishlist ID, to pin the element to one specific wishlist, and a “Show the default wishlist only” toggle. Leave both alone and the element behaves exactly like the [saveto_wishlist] shortcode.

This matters because a UX Builder page stores its own layout. If you rebuild your wishlist page in UX Builder without adding this element, the page has no wishlist on it to show. Adding the element puts it back.

One limit worth knowing: place the element on the page itself. If you put it inside a reusable UX Block and then pull that block into a footer, a menu, or a custom product layout, the wishlist still appears but its scripts and styles will not load with it.

Can my customers have multiple wishlists?

Yes, they can! Your users can create and name as many wishlists as they like to help them organize their shopping on your store.

Is it easy for users to save their favorites?

Yes! With a single click, shoppers can bookmark items and curate a list of their favorite products to save for later.

Does this support a guest user wishlist?

Yes! Guests can save products without logging in. When they eventually create an account, all of their saved items are automatically merged, so they don’t lose anything.

Does it work with the Divi theme?

Yes, and SaveTo Wishlist adds a native “Save to Wishlist” module to the Divi Builder so you can place the wishlist exactly where you want it.

Divi builds pages with its own layout system rather than the WordPress page content, so a page you have built with the Divi Builder — or a page covered by a Divi Theme Builder template — may no longer run the [saveto_wishlist] shortcode that the plugin’s Wishlist page normally uses. (A Theme Builder template that includes Divi’s own Post Content module still runs it.) If your Wishlist page looks empty under Divi, that is why.

To fix it, open the page in the Divi Builder, add the “Save to Wishlist” module wherever you want the wishlist to appear, and save. The module also works inside Divi Theme Builder templates, so you can build one wishlist layout and reuse it across your site. Leave the module’s “Wishlist ID” field empty and it shows each visitor their own wishlist.

The module needs Divi 4, either the theme or the Divi Builder plugin. It appears in the builder’s module list under its own name, alongside Divi’s other modules. Divi 5 uses a new module system and is not supported yet.

Does it work with the Woostify theme?

Yes. The wishlist button works out of the box with Woostify, and the plugin ships Woostify-specific styling so the button looks native on Woostify’s shop, archive and single-product templates — no custom CSS needed. Because Woostify rebuilds the WooCommerce product loop and uses its own product gallery, a couple of button placements are best avoided on Woostify. You’ll find these options under SaveTo Wishlist → Settings → Button.

Shop page — “Button Placement”:

• Recommended: “Top Right of the Product Image” (the plugin default), “Top Left of the Product Image”, “Above the Product Title”, “Below the Product Title”, or “Above the Add to Cart Button”.
• Avoid “Below the Add to Cart Button”. Woostify renders that row inside a fixed-height, animated area on desktop, so the button is clipped from view. If your shop is set to this placement, switch to one of the recommended options above for Woostify.

Product page — “Button Placement”:

• Recommended: “Above the Add to Cart Button”, “Below the Add to Cart Button”, “Above the Product Title”, or “Below the Product Title”.
• Avoid “Top Right of the Product Image” (the plugin default) and “Top Left of the Product Image”. Woostify’s custom product gallery does not display the on-image button reliably, so Woostify stores should switch away from the default to one of the recommended options above.

Does it work with the Blocksy theme?

Yes. The wishlist button works out of the box with Blocksy, and the plugin ships Blocksy-specific styling so the button looks native on Blocksy’s shop, archive and single-product templates — no custom CSS needed. Every placement shows the button on Blocksy; the notes below tell you what to expect from each one. You’ll find these options under SaveTo Wishlist → Settings → Button.

Shop page — “Button Placement”:

• All six placements show the button, but two of them sit in a different spot than their name suggests (see below). “Top Right of the Product Image” (the plugin default) is the best fit, because Blocksy keeps the card’s top-left corner for its own Sale badge.
• “Top Left of the Product Image” shares that corner, so on a product that shows a badge there — Sale, out of stock, or a custom Blocksy badge — the wishlist button is moved down to sit under the badge instead of covering it. If your badge is unusually large, or you show more than one badge in that corner, use “Top Right of the Product Image”.
• “Above the Product Title” and “Below the Product Title” both show the button between the product image and the title, because Blocksy renders its own title. “Above the Add to Cart Button” shows it directly below the title. “Below the Add to Cart Button” shows it after the Add to Cart button. All four follow your Blocksy card alignment, whether your cards are set to left, centre or right.

Product page — “Button Placement”:

• All seven placements work. “Inline with the Add to Cart Button” sits beside the Add to Cart button on desktop and moves under it on narrow screens, where Blocksy’s own button already fills the row.
• “Top Left of the Product Image” is moved down on a product that shows a badge in that corner, for the same reason as on the shop page.

Blocksy is a classic theme, so your shop and product pages use the WooCommerce templates rather than blocks. If you build a page with the WooCommerce Product Collection block instead, the wishlist button still renders — see the block theme answer below for which block each placement attaches to.

Does it work with Ultimate Store Kit product grids?

Yes. The wishlist button shows on every card of the Ultimate Store Kit widgets that have their own “Add to Cart” action button: the Glossy, Shiny and Florence grids and carousels, the Heaven, Mentor and Showcase sliders, Product Accordion, Product Image Accordion and Image Hotspot. You’ll find the button settings under SaveTo Wishlist → Settings → Button.

Ultimate Store Kit has its own wishlist icon, which each grid controls with a “Wishlist” switch that is turned on by default. To make sure a card never shows two hearts, SaveTo Wishlist keeps its own button hidden while that switch is on. To use the SaveTo Wishlist button instead, open the grid in Elementor and turn the “Wishlist” switch OFF. The SaveTo Wishlist button then appears on every card of that grid. Each grid has its own switch, so you can use Ultimate Store Kit’s icon in one grid and the SaveTo Wishlist button in another.

A few things to know:

• Ultimate Store Kit gives the plugin only one place to add the button: next to the card’s “Add to Cart” action. The “Top Right” and “Top Left” placements keep the button with the card’s icons, without covering them or the sale and “New” badges. The other placements show the button next to the “Add to Cart” action, because the title placements cannot move it.
• Inside Ultimate Store Kit cards, the button always shows as an icon, without its text, so it matches Ultimate Store Kit’s own icons. Your icon shape and colors still apply, with two adjustments: an icon larger than 20 px is shown at 20 px so it fits beside the card’s icons, and on a solid button style, a light icon on a dark button (such as the white icon of the Classic Red preset) takes the button’s background color, so it stays visible on the product image.
• If your shop button uses the “Theme Default” mode, the cards show the standard red heart icon, because that mode has no icon settings of its own.
• If you turn off the grid’s own “Add to Cart” action button, Ultimate Store Kit no longer offers that place, so the grid shows no wishlist button. Keep the “Add to Cart” action turned on to show the SaveTo Wishlist button.
• Choosing “Don’t show” for the shop page placement hides the button in Ultimate Store Kit grids too.
• Some Ultimate Store Kit widgets build their cards without an “Add to Cart” action at all — Product List, Product Table, Product Category and Sub Category among them. Those widgets show no wishlist button, whichever way their “Wishlist” switch is set.

The wishlist button is missing from my shop page on a block theme. Why?

On a block theme, WooCommerce builds the shop and category pages out of blocks, and SaveTo Wishlist attaches the button to the block that matches your chosen placement. Each placement uses a different block:

• “Top Right of the Product Image”, “Top Left of the Product Image” and “Above the Product Title” attach to the Product Image block.
• “Below the Product Title” attaches to the Product Price block.
• “Above the Add to Cart Button” and “Below the Add to Cart Button” attach to the Add to Cart Button block.

If you have edited the Product Catalog template in the Site Editor and deleted the block your placement needs, the button has nothing left to attach to and will not appear. This only affects edited templates. The template WooCommerce ships includes all three blocks, so a store that has not customised it is unaffected.

Two ways to fix it:

• Pick a placement whose block is still in your template. For example, if you removed the Add to Cart Button block, switch from “Below the Add to Cart Button” to “Below the Product Title”.
• Or add the missing block back to the Product Catalog template in Appearance > Editor > Templates.

This applies to WooCommerce 9.5 and later. Classic themes are not affected, because they do not build the shop page from blocks.

Can I trigger a Popup Maker popup when a product is added to a wishlist?

Yes, and you do not need to write any code. With Popup Maker active, SaveTo adds four things to Popup Maker’s own screens:

• A trigger called Product Added to Wishlist (SaveTo Wishlist). Add it to any popup and the popup opens the moment a customer saves a product, with an optional delay. It works for guests and logged-in customers alike.
• A targeting condition called Customer Has Wishlisted Products, under the SaveTo Wishlist group. Use it to show a popup only to shoppers who already have something on their list — perfect for exit-intent reminders. Logged-in customers are matched from their saved wishlists, and guests from the wishlist cookie described below.
• The SaveTo Wishlist shortcode in Popup Maker’s shortcode picker, so you can show a customer’s wishlist inside the popup itself.
• A View Wishlist (SaveTo Wishlist) call to action, which sends the shopper straight to your wishlist page and records the click as a Popup Maker conversion.

If your popups run on a full-page cache, exclude the stwlite_wishlist_added cookie in your caching plugin so the Customer Has Wishlisted Products condition is evaluated per visitor.

If you switch the wishlist add signal off (see Can I stop SaveTo from setting the wishlist cookie? below), two of these stop working. The Product Added to Wishlist trigger stops opening popups for everyone, guests and logged-in customers alike, because it listens for the event the signal carries. The Customer Has Wishlisted Products condition stops matching guests once their existing cookie is gone, because that cookie is the only thing that tells your server a guest has saved anything. Logged-in customers still match the condition, because they are matched from their saved wishlists.

Which client-side signals does SaveTo emit on add to wishlist?

On every successful add, SaveTo emits two generic browser-side signals — for both guests and logged-in customers, and whether or not Popup Maker is installed. Both can be switched off; see Can I stop SaveTo from setting the wishlist cookie? below. Use these if you want to build your own behaviour on top of a wishlist save:

• A DOM event on document named stwlite_added_to_wishlist, carrying event.detail = { productId, collectionId }. Use it for instant triggers. productId is the variation ID for variable products, and 0 when several products were saved at once (the “save cart to wishlist” button). collectionId is 0 for guests, whose items are stored in the browser rather than in a wishlist.
• A cookie named stwlite_wishlist_added, whose value is the URL-encoded product ID — run it through decodeURIComponent() before using it. Use the cookie for cross-page-load targeting such as exit-intent. It lasts 30 days and is cleared once the customer removes their last wishlisted product, or as soon as you switch the signal off.

To open a popup from the event yourself (Popup Maker exposes PUM.open()):

document.addEventListener( 'stwlite_added_to_wishlist', function ( e ) { PUM.open( 123 ); } );

Note: when Wishlist > Settings > General > Add to wishlist button is set to Redirect, the page navigates away immediately after the add, so use the cookie rather than the event in that mode.

How do I change the wishlist total on the wishlist page?

The wishlist page shows the total value of the wishlist below the items. You can hide it with Wishlist > Settings > Wishlist Page > Show Wishlist Total.

To change it in code, use two JavaScript filters from wp.hooks. Both run in the browser, so add them from a script that loads on the wishlist page.

• stwlite_wishlist_total runs first. It receives the total as a number and the wishlist items as an array. Return a number. If you return anything that is not a finite number, SaveTo ignores it and keeps the calculated total.
• stwlite_wishlist_total_html runs second. It receives the formatted total as a string, the total as a number (the value the first filter returned), and the wishlist items. Return the HTML to show. SaveTo removes scripts and unsafe markup from the result before it renders.

Register both filters before the wishlist app renders, so enqueue your script with wp-hooks as a dependency and load it before the SaveTo wishlist script. A filter added later does not take effect until something else makes the page render again.

The total covers every item that matches the search, not only the current page. Items with no price are left out. On the logged-in wishlist page, the total is not shown when more than 200 items match. The total is also not shown when SaveTo Pro hides the Price or Subtotal column.

The items array holds every item that matches the search, with each item’s current quantity. Each item has a product object. On the logged-in wishlist page, item.id is the wishlist item ID. On the guest wishlist page, item.id is the product ID.

wp.hooks.addFilter( 'stwlite_wishlist_total', 'my-plugin', function ( total, items ) { return total * 0.9; } );

wp.hooks.addFilter( 'stwlite_wishlist_total_html', 'my-plugin', function ( html, total, items ) { return '<strong>' + html + '</strong>'; } );

Can I see wishlist activity in Independent Analytics?

Yes. Once both plugins are active, SaveTo records wishlist activity as events in your Independent Analytics reports, named after the product — for example Wishlist added: Blue Hoodie. Sort your report by views and the products at the top are the ones shoppers want most.

A save is recorded when a customer clicks the wishlist button. A removal is recorded when a customer removes a product: from the wishlist button, from the wishlist page, or automatically after adding it to the cart. Removals on the admin Wishlists screen, saving the whole cart to a wishlist, and deleting a whole wishlist are not recorded.

SaveTo also adds a Wishlist demand widget to your WordPress Dashboard, next to the Independent Analytics widget. It lists the products saved to the most wishlists, so you can see demand at a glance without opening a report. The list refreshes every 15 minutes.

Two things are worth knowing before you go looking for the data:

• Turn on “Track logged in users” in Independent Analytics first. Wishlists in the free version belong to logged-in customers, so if Independent Analytics is set to ignore logged-in visitors — which is how it ships — there is nothing for it to record. You will find the setting under Analytics > Settings.
• Wishlist events are counted as views, because that is the only kind of row Independent Analytics keeps. So each saved product adds one view to your totals, exactly as Independent Analytics’ own checkout event does. Every wishlist row is labelled “Wishlist added” or “Wishlist removed”, so they are easy to spot and easy to filter out.

Saving a product you have already saved is counted again, so read the Visitors column rather than Views when you want to know how many different shoppers want a product. Removing SaveTo leaves your past wishlist events in Independent Analytics untouched — we do not delete another plugin’s data.

Can I stop SaveTo from setting the wishlist cookie?

Yes. Go to Wishlist > Settings > General > Privacy and set Enable wishlist add signal cookie to No. Your store then stops writing the stwlite_wishlist_added cookie and stops firing the stwlite_added_to_wishlist event, and any cookie already on a shopper’s browser is cleared the next time they load a page. Customers can still save products to their wishlists exactly as before.

This is the setting to use if your store needs consent before it writes a marketing cookie, for example under the German TDDDG or the GDPR.

Developers can do the same in code with the stwlite_enable_wishlist_add_signal_cookie filter, which defaults to true:

add_filter( 'stwlite_enable_wishlist_add_signal_cookie', '__return_false' );

The filter name mentions the cookie, but it controls the DOM event as well — the two always travel together.

The filter runs while the page is built on your server, so the answer is baked into the page that is sent to the browser. Two things follow from this. If you run a full-page cache, flush it after you change the setting, because cached pages keep the old answer until they are rebuilt. And if you want to tie the signal to a consent banner, make the page bypass your cache, or vary it on your consent cookie — otherwise one shopper’s consent is cached and served to the next shopper.

Still have questions? Please do not hesitate to reach out to our team via the support forums.