Magento 2 Wishlist Performance Bug: Fix #41151 Explained

As e-commerce migration experts at Shopping Mover, we constantly scrutinize the intricate workings of Magento 2 (both Adobe Commerce and Open Source editions) to identify and resolve performance bottlenecks. Our mission is to ensure seamless transitions and optimal operation for online businesses. A recent deep dive into the Magento GitHub repository brought to light a significant, yet subtle, performance issue within the core Wishlist module that could be silently impacting countless stores.

Magento 2 developer analyzing Wishlist Helper Data PHP code for performance issues

The Hidden Recalculation Bug in Magento 2 Wishlist: Issue #41151

The issue, meticulously reported by Eddcapone as GitHub Issue #41151, details a critical flaw in the Wishlist\Helper\Data::getItemCount() method. This method, fundamental for displaying the number of items in a customer's wishlist (e.g., in the header mini-wishlist), is designed to leverage caching for efficiency. However, a logical error causes it to bypass its own caching mechanism, leading to a full recalculation of the wishlist item count on virtually every request for logged-in customers, irrespective of whether any changes have actually occurred.

Root Cause: A Flawed Caching Condition and Unconditional Session Update

The core of the problem lies within a specific conditional check in the getItemCount() method. Let's break down the problematic logic:

// vendor/magento/module-wishlist/Helper/Data.php
public function getItemCount()
{
    // ... other code ...
    if (!$this->_customerSession->hasWishlistItemCount() ||
        $currentDisplayType != $storedDisplayType ||
        $this->_customerSession->hasDisplayOutOfStockProducts() ||   // <- always true after the first calculate()
        $currentDisplayOutOfStockProducts != $storedDisplayOutOfStockProducts
    ) {
        $this->calculate();
    }
    // ... other code ...
}

public function calculate()
{
    // ... other code ...
    $this->_customerSession->setDisplayOutOfStockProducts(...);   // <- sets it unconditionally every time
    // ... other code ...
}

As you can see, the calculate() method unconditionally calls setDisplayOutOfStockProducts(). This action permanently sets a session variable. Consequently, after the very first call to calculate(), the condition $this->_customerSession->hasDisplayOutOfStockProducts() will always evaluate to true for the remainder of that customer's session. This effectively short-circuits the caching mechanism, forcing a full recalculation every single time the wishlist count is requested.

This bug has been consistently reproduced across a wide range of Magento versions, including 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8, and 2.4.9, indicating its long-standing presence in the core codebase and its potential impact on a vast number of e-commerce stores.

Significant Performance Impact: More Than Just a Minor Glitch

The implications of this seemingly minor bug are far-reaching, especially for stores with active customer wishlists. Every AJAX call that includes the wishlist section (e.g., customer/section/load?secti>, which is common for updating customer data sections after any user interaction) triggers this full, uncached recalculation. For customers with a non-trivial wishlist (meaning a real product collection query, price rendering, and other resource-intensive operations), this can translate into a significant performance hit.



    Slow AJAX Calls: Measured on production-like environments, this bug can add 1.7 to 2.4 seconds per call consistently. This directly impacts the responsiveness of your website for logged-in users.
    Increased Server Load: Repeated, unnecessary database queries and PHP processing strain your server resources, leading to higher hosting costs and potential slowdowns for all users during peak times.
    Degraded User Experience: Slow loading times for dynamic content can frustrate users, leading to higher bounce rates and abandoned sessions.
    PHP Session Lock Contention: Each such AJAX call holds a PHP session lock for an extended period. Under concurrent requests, this can lead to users experiencing delays as their requests queue up, further compounding the performance problem.

For e-commerce businesses, these performance degradations can directly translate into lower conversion rates, reduced customer satisfaction, and scalability challenges as your store grows.

Why This Matters for Magento Migrations and Existing Stores
At Shopping Mover, we understand that successful Magento migrations aren't just about moving data; they're about optimizing the entire platform for peak performance. Hidden issues like this wishlist bug can undermine even the most meticulously planned migrations, negating expected performance gains or introducing new bottlenecks post-migration.
Even for established Magento stores that haven't undergone a recent migration, this bug represents a silent drain on resources. It's the kind of subtle flaw that often goes unnoticed without deep profiling and expert analysis, yet it can significantly impact the overall user experience and operational efficiency.

The Proposed Solution: A Simple Yet Effective Fix
Fortunately, the suggested fix for this issue is straightforward and aligns with best practices for caching logic. The core idea is to change the third conditional check from merely verifying if a session value exists to checking if its value has changed, consistent with the sibling condition right after it. The hasDisplayOutOfStockProducts() check becomes redundant when a value comparison is in place.
The proposed fix involves modifying the conditional statement as follows:
if (!$this->_customerSession->hasWishlistItemCount() ||
    $currentDisplayType != $storedDisplayType ||
    $currentDisplayOutOfStockProducts != $storedDisplayOutOfStockProducts
) {
    $this->calculate();
}

By implementing this change, the calculate() method will only be invoked when a relevant condition (like the wishlist item count itself, display type, or out-of-stock product display preference) truly changes, allowing the cached value to be reused efficiently in all other scenarios. This restores the intended caching behavior and significantly reduces unnecessary processing.

Actionable Insights for Merchants and Developers
If you're running a Magento 2 store on any version from 2.4.4 to 2.4.9, we strongly recommend investigating this potential bottleneck:

    Profile Your Store: Utilize tools like Blackfire, New Relic, or Magento's built-in profiler to identify if Wishlist\Helper\Data::getItemCount() is a frequent and time-consuming call in your customer/section/load requests.
    Apply a Patch: While waiting for an official Magento core fix, consider creating and applying a Composer patch for the vendor/magento/module-wishlist/Helper/Data.php file. This is a robust way to implement the fix without directly modifying core files.
    Custom Module Override: Alternatively, a custom module can be developed to override the getItemCount() method in the Wishlist\Helper\Data class, incorporating the suggested fix.
    Monitor GitHub: Keep an eye on the official Magento 2 GitHub repository for updates on Issue #41151 and the release of an official patch or inclusion in a future Magento update.
    Test Thoroughly: Always apply any code changes first in a staging environment and conduct comprehensive testing to ensure stability and functionality.

Addressing such core performance issues is crucial for maintaining a fast, scalable, and user-friendly e-commerce platform. For complex scenarios, or if you're planning a Magento migration, partnering with experienced Magento development and migration experts like Shopping Mover can provide the deep technical insight and implementation capabilities needed to optimize your store effectively.

Conclusion
The discovery of Issue #41151 highlights the importance of continuous vigilance and deep technical expertise in managing and optimizing Magento 2 stores. What appears to be a minor logical error can have a cascading effect on performance, impacting user experience and operational costs. By understanding the root cause and implementing the proposed fix, merchants can reclaim valuable server resources and deliver a snappier experience for their logged-in customers.
At Shopping Mover, our commitment extends beyond just migrations; we empower businesses with robust, high-performing e-commerce solutions. If you're encountering performance challenges or planning your next Magento migration, reach out to our experts for unparalleled support and strategic insights.