Zum Inhalt springen

Using the wishlist

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

This walkthrough takes a fresh install to a working wishlist: a button in your loops, a place for shoppers to view saved items, and guest lists that survive until login.

Open the Shortlist menu, confirm Enable wishlist is on, and pick your placements, shop loop, single product page, My Account tab. Most stores enable all three. If you want logged-out shoppers to keep a list, leave Allow guests on; turn it off to send them to login instead.

Set the add and remove button labels to your store voice. Set the variation hint too, on variable products the button stays disabled with this hint until the shopper picks options, so they save the exact variation rather than the generic product.

Shoppers need somewhere to view their list. You have two options that work together:

  • The My Account → Wishlist tab (turn on the placement), optionally with a live item count next to the menu label.
  • A dedicated wishlist page, pick an existing page from the dropdown, or click Create wishlist page to publish one with the [shortlist] shortcode in a click.
  1. Open Shop and click Add to wishlist on a simple product, the button toggles to the remove state and the change is announced via aria-live. Every button for that product on the page stays in sync.
  2. Open a variable product, the button shows your hint and stays disabled until options are picked, then saves that variation.
  3. Open the My Account tab or the dedicated page, saved items appear in the grid with the columns you enabled.

If guests are allowed, log out, save a product, then log back in. The guest list, kept in a cookie, merges into the account automatically, there is no manual import step for shoppers.

Show the current shopper’s list anywhere with the shortcode:

[shortlist]

It takes no attributes, there is no per-list ID; it always renders the viewing shopper’s own list. The Shortlist Wishlist block (shortlist/wishlist) produces the same server-rendered output in the block editor, so the editor preview matches the front end. If your dedicated page already contains [shortlist], turn off Show list on page so the grid is not output twice.

A click posts the product ID to admin-ajax.php (action shortlist_wishlist_toggle, guarded by the shortlist_wishlist nonce); the server adds or removes the row and returns the new state, label and saved-item count. Logged-in customers are keyed by their user ID; guests by the session cookie. The button is disabled and marked aria-busy while the request is in flight, so a double-click cannot submit twice. The toggle is a real <button> with aria-pressed, and because the script matches on the product ID, every button for that product on the page (a loop card and the single-product button, say) flips together after one toggle. If guests are not allowed, an anonymous click instead sends the visitor to the login page.

On a variable product the button starts disabled. Shortlist loads WooCommerce’s own wc-add-to-cart-variation script and listens (through jQuery) for its found_variation / reset_data events: picking a valid variation enables the button and swaps in that variation’s ID; clearing the selection disables it again and shows the hint. This is the one place Shortlist relies on jQuery, the add/remove toggle itself is plain JavaScript.

The add/remove toggle script is vanilla JavaScript, deferred and loaded in the footer, and uses event delegation so buttons rendered after page load (infinite scroll, quick-view, AJAX filters) keep working. The button reserves its space, so switching between the add and remove states never reflows the page, no Cumulative Layout Shift. Outcomes (added, removed, or an error) are announced through a polite aria-live region, the My Account count updates live without a reload, and an empty list shows a friendly state with a Browse products link rather than a blank panel. Shortlist’s stylesheet and script load only on the shop, product, product-archive, account and dedicated-wishlist pages, nowhere else.