How to interact with a customer wish list in Magento 2

The customer wish list in Magento 2, today part of Adobe Commerce, is a store feature that lets shoppers save products they like, and it gives the business something rare in ecommerce: a voluntary, first-party signal of what each customer wants to buy. Used well, it improves the shopping experience, supports sales and feeds the data needed to model and analyze preferences.

Picture the marketing review of an online retailer of home goods. The chief marketing officer opens a report showing that thousands of products sit in customers' wish lists, many of them for months. The sales director asks how many of those customers received a message when the product went on sale. Nobody knows. The operations manager adds that the same products ran out of stock last week, and no one told the shoppers who had been waiting for them. The wish list exists, customers use it, and the company treats it as a storage box instead of a conversation.

The customer wish list is an important tool to offer a better user experience, to increase sales and to obtain more data from the customer, so as to model and analyze their preferences. This article explains what a wish list is worth to the business, how it is configured in Adobe's documentation, and how a development team can read and modify it programmatically, using the sample code that accompanies the original guide. It is written for executives who must decide whether the feature deserves attention, and for the technical leads who will implement what they decide.

What is a customer wish list worth to the business?

A wish list is a declaration of intent that the customer makes without being asked. A shopper who adds a product to a list is saying that the product matters, that the time is not yet right and that the store is the place where they intend to buy it later. Compared with the data that a company has to infer from browsing behavior, that is a clean signal, and it comes from a logged-in customer whom the company can identify and contact with consent.

Digital optimization practitioners point to several uses. An article from the agency The Good on ways to drive more ecommerce wish list conversions notes that wish list data can inform email marketing such as sale alerts, remarketing, product trend analysis and cross-sell, up-sell and down-sell ideas, and that a list can reveal hesitations such as a need for more information or a wait for a promotion. The same source warns against using a wish list as a bandage for weak product information pages, and its evidence is largely the author's experience and a 2018 abandonment statistic, so the sensible reading is that wish lists are a hypothesis to test, not a guaranteed lift.

For a retailer, the clearest value lies in three decisions. The first is communication: a price drop, a restock or a limited-time offer on an item the customer has saved is a relevant message, and relevance is what separates useful marketing from noise. The second is merchandising: the products that are saved often but rarely purchased show where price, information or availability is failing. The third is demand planning: a count of saved items per product is an early indicator of interest that complements sales history. Our article on four benefits of ecommerce wish lists explores the commercial case in more detail.

How is a wish list configured in Adobe Commerce?

Before any code is written, the feature has to be configured, and that is a business decision. According to Adobe's guide to configuring wish lists, the options sit under Stores, Settings, Configuration, Customers, Wish List. There the administrator enables the module, decides whether customers can share their lists by email, chooses the sender and template of those emails and sets limits on how many can be sent, and defines how the wish list summary is shown in the customer's account. In Adobe Commerce, customers can also be allowed to have multiple wish lists, and a search widget lets shoppers find public lists by owner name or email.

The same documentation notes that buying from a public wish list does not remove the item from the original list, and that shipping addresses are not part of wish lists. These details matter for gift scenarios such as weddings or birthdays, where the owner of the list and the buyer are different people. Administrators can also see and assist with a customer's list from the customer record, as Adobe's page on wish list assistance in the admin explains, which makes it possible for service teams to help a customer move an item from the list to the cart. The previous article in this series, how to configure the wishlist in Magento, covers the administration side step by step.

How can a developer read and modify the wish list in Magento 2?

In Magento 2, the customer's wish list can be obtained and modified programmatically with the following code, a helper class that the original guide provides as a starting point.

<?php
namespace ICX\Wishlist\Helper;
use \Magento\Framework\App\Helper\AbstractHelper;
use \Magento\Framework\App\Helper\Context;
use \Magento\Customer\Model\Session;
use \Magento\Wishlist\Model\Wishlist;
use \Magento\Catalog\Api\ProductRepositoryInterface;

class WhishlistHelper extends AbstractHelper {
  private $session;
  private $wishlist;
  private $productRepository;

  /**
  * @param \Magento\Framework\App\Helper\Context $context
  * @param \Magento\Wishlist\Model\Wishlist $wishlistHelper
  * @param \Magento\Customer\Model\Session $session
  * @param \Magento\Catalog\Api\ProductRepositoryInterface $productRepository
  */
  public function __construct(
    Context $context,
    Wishlist $wishlist,
    Session $session,
    ProductRepositoryInterface $productRepository
  ) {
    parent::__construct($context);
    $this->wishlist = $wishlist;
    $this->session = $session;
    $this->productRepository = $productRepository;
  }

  public function getCustomerId(){
    if(!$this->session->isLoggedIn()){
      return false;
    }
    return $this->session->getCustomerId();
  }

  public function isInWishlist($productId){
    $customerId = $this->getCustomerId();
    if(!$customerId){
      return false;
    }
    $wishlistCollection = $this->wishlist->loadByCustomerId($customerId)
->getItemCollection();
    $inWishlist = false;
    foreach ($wishlistCollection as $wishlist_item) {
      if($wishlist_item->getProduct()->getId() == $productId){
        $inWishlist = true;
        break;
      }
    }
    return $inWishlist;
  }

  public function addProductToWishlist($productId){
    if(!$this->isInWishlist($productId)){
      return false;
    }
 $product = $this->_productRepository->getById($productId);
 if($product == null){
 return false;
 }
 $wishlist = $this->wishlist->loadByCustomerId($customerId);
 $wishlist->addNewItem($product);
 $wishlist->save();
   return true;
  }

  public function removeProductFromWishlist($productId){
    if(!$this->isInWishlist($productId)){
      return false;
    }
 $product = $this->_productRepository->getById($productId);
 if($product == null){
 return false;
 }
 $wishlist = $this->wishlist->loadByCustomerId($customerId);
 $items = $wishlist->getItemCollection();
 foreach ($items as $item) {
 if ($item->getProductId() == $productId) {
 $item->delete();
 $wish->save();
 }
 }
 return true;
  }
}

The functions in the class do the following. The first, getCustomerId, obtains the identifier of the current customer, and its behavior can be overridden depending on how the customer should be selected. The second, isInWishlist, finds out whether the product with the specified identifier is in the wish list. The third, addProductToWishlist, adds the product with the specified identifier to the customer's wish list, and the fourth, removeProductFromWishlist, removes it. Together they cover the four operations that any integration needs: identify the customer, check a product, add it and remove it.

A word of caution is appropriate for readers who intend to reuse the listing. It is an illustrative sample from the original guide, and any code of this kind must be reviewed, adapted to the project's module structure and tested by the development team before it reaches a production store. In particular, the add and remove functions rely on a customer identifier and a product repository property that the developers should confirm are defined as they expect in their own version of the class. Treating sample code as a starting point and not as a finished component is standard practice, and it is the reason this kind of work belongs in a code review process.

How can the wish list be shown in the storefront?

It is also possible to display the information of the customer's wish list in the storefront with JavaScript. Magento keeps a browser-side cache of customer data, and the wish list can be read from it with these two lines.

var wishlist = JSON.parse(localStorage.getItem('mage-cache-storage')).wishlist;
var items = wishlist.items;

A more structured alternative is to use the following file as a base, which is the wish list view component that ships with the module, located at vendor/magento/module-wishlist/view/frontend/web/js/view/wishlist.js. It defines a component that requests the wish list from the customer data service when it initializes.

define([
    'uiComponent',
    'Magento_Customer/js/customer-data'
  ], function (Component, customerData) {
  'use strict';

  return Component.extend({
    initialize: function () {
      this._super();
      this.wishlist = customerData.get('wishlist');
    }
  });
});

For the business, the practical meaning is that the storefront can show a customer's saved items in the places where they matter: in the header as a reminder, on product pages to indicate that an item is already saved, or in a recommendation block that reorders content by interest. Our article on content personalization in Magento Commerce describes how this kind of signal can feed more relevant pages.

How do you add a wish list button to the product listing?

If the store wants a button to add products to the wish list, it can be created in the template, for example Magento_Catalog/templates/products/list/addto/wishlist.phtml, with the following code.

<?php
echo $block->getLayout()
->createBlock('Magento\Wishlist\Block\Catalog\Product\ProductList\Item\AddTo\Wishlist')
->setProduct($_product)
->setTemplate("Magento_Wishlist::catalog/product/list/addto/wishlist.phtml")->toHtml();
 ?>

The snippet creates the add-to-wish-list block for the product being displayed and renders it with the wish list module's own template. It is a small piece of code with an outsized commercial effect, because the placement and visibility of that button decide how many shoppers leave a signal at all. A store that hides the button on its product listings, or requires too many steps to use it, will collect less demand data than its customers would willingly provide.

How should wish list signals connect to the rest of the commercial stack?

A wish list only creates value when its events travel to the systems that act on them. The first connection is the email or marketing automation platform, which needs to know which customer saved which product so that a restock or price message can be triggered with the right content. The second is the inventory and pricing sources, because a message that announces availability or a discount must be accurate at the moment of sending, and an error here costs more trust than silence. The third is the CRM, where the saved products enrich the customer profile and help sales and service teams understand intent when the customer makes contact.

The fourth connection is analytics. Counting saves, removals and purchases per product, and linking them to campaigns, allows the business to see whether the wish list is a real conversion path or only a place where products are forgotten. Teams that do this well define the metric before building the integration, for example the share of saved items bought within a stated period, and review it in the same meeting where they review other commercial indicators. A short list of owners helps: marketing owns the messages, merchandising owns the assortment decisions, and technology owns the reliability of the data flow.

What are the trade-offs and risks?

The most important caution concerns privacy and trust. A wish list reveals preferences and sometimes sensitive purchases, and communications built on it must respect consent and local regulation. A customer who receives a message about an item they saved will usually welcome it, and one who feels followed will not. Our article on effective personalization in CRM while protecting customer privacy sets out a practical framework.

A second risk is technical debt. Custom code that reads the browser cache or manipulates wish list objects can break when the platform is upgraded, and every customization has a maintenance cost. The third risk is operational: messages triggered by wish list events, such as a price drop, require accurate price and stock data and clear rules about frequency, or they become a source of complaints. The last is organizational. A wish list produces insight only when someone in marketing or merchandising owns the question of what to do with it.

What does this mean for the C-level?

For the chief marketing officer and the chief commercial officer, the wish list is a way to attract and convert customers who have already shown interest. It enables communications that are timely and relevant, such as alerts for price changes and availability, and it provides a source of insight for assortment and promotions. The decision is whether to treat it as a channel with an owner, a set of rules and measurable objectives, or as a passive feature.

For the chief customer officer, the wish list is part of loyalty. It allows the customer to plan purchases and to share lists with family and friends, and it creates a reason to return to the store. For the chief financial officer, the relevant question is the return on the effort: how many purchases can be traced to a wish list reminder, and at what margin. For technology leaders, the discipline is to keep customizations small, documented and reviewed, and to prefer configuration and standard components wherever they are sufficient.

How should a director start next week?

Ask the team for three numbers: how many customers have a wish list, how many items are saved on average, and how many saved items were purchased within thirty days. If the team cannot answer, the first project is measurement. If it can, review the five most saved products that do not sell and decide, product by product, whether the barrier is price, information, stock or something else.

Then agree on one automated message, such as a restock or price drop alert for saved items, with a clear consent basis and a frequency limit. Run it for a month on a part of the customer base and compare purchases with a control group. If the result is positive, extend the program and invest in the storefront improvements described above. If it is not, the business has learned something inexpensive about its customers. In both cases, the technical team's sample code should go through a review before it touches the live store.

How ICX helps

ICX Consulting approaches customer data as a commercial asset. Our digital ecommerce for B2C practice designs the journeys and signals, such as the wish list, that drive conversion and loyalty, and our customer analytics and insights work turns that data into decisions about assortment, pricing and communication. When Adobe Commerce is the platform, our team implements the integrations and the automation that connect the wish list with email, CRM and inventory.

To map the moments when a customer considers, hesitates and decides, use the Customer Journey Toolkit. Are your customers telling you what they want to buy without anyone listening? Request a diagnostic with an ICX consultant.

Frequently asked questions

Does a wish list require the customer to be logged in?

In the sample helper, the customer must be logged in, because the list belongs to a customer account and the code returns false when there is no active session. That requirement is also what makes the data valuable, since the preference is tied to an identified customer.

Can the wish list be shared with other people?

Yes. Adobe Commerce lets administrators enable sharing by email and set the sender, template and limits. Buying an item from a shared list does not remove it from the owner's list, so the owner needs a clear way to manage purchased gifts.

How should a company use wish list data in marketing?

For relevant, consent-based messages such as availability and price alerts, for merchandising decisions about products that are saved but not bought, and for demand signals. Avoid sending frequent generic reminders, which erode the trust that made the customer save the item.

Is custom code always necessary to work with wish lists?

No. The standard module already offers configuration, sharing and display options. Custom code is justified when the store needs behavior that the standard features do not provide, and it should be reviewed, tested and kept as small as possible to ease upgrades.

The companies that grow with their customers are the ones that notice what shoppers quietly ask for and answer it at the right moment. If your wish list data is waiting to become a conversation, we would be glad to help you design it.