WooCommerce Wishlists

WooCommerce Wishlists 2.3.23

Register or Log in for Free Download
* Update: WordPress 6.5 is now the minimum supported version
* Fix: Empty wishlists were being created for requests that could not add anything. On a variable product, following the add-to-wishlist link without choosing options created the list first and only then discovered there was nothing to put in it, leaving it behind - so search engine crawlers, which follow that link, produced one empty temporary list per visit. One store accumulated 11,000 of them. The product is now resolved and checked before any list is created, so a request that cannot add anything leaves nothing behind. Existing empty lists are not removed by this update; they can be deleted safely.
* Fix: Choosing a variation through the add-to-wishlist link failed with "Please choose product options" even when the options were named in the URL. The variation lookup read only posted data, while the link is a normal link and carries its attributes in the query string. It now reads both, matching the validation immediately after it, which always did.
* Fix: On single-site WordPress, deactivating WooCommerce while Wishlists was active caused a fatal error on both the front end and wp-admin instead of the "requires WooCommerce" notice, locking the site out entirely. The load-order check added in 2.3.18 called wp_get_active_network_plugins(), which WordPress only defines on multisite. Affects 2.3.18 and 2.3.19.
* Refactor: The extension now initializes on the 'plugins_loaded' hook and checks for WooCommerce with class_exists(), replacing the custom active-plugins scan. Every active plugin has been loaded by that point, so the check is reliable regardless of plugin load order without inspecting WordPress internals. The 'Requires Plugins: woocommerce' header governs activation, but WordPress still loads the plugin when WooCommerce is deactivated by other means, so the runtime check remains.
* Fix: The view-a-list page answered 200 with an empty list body for any wlid value, which let crawlers enumerate list IDs indefinitely and leaked whether a given list existed. Requests for a list that does not exist, or that the visitor is not allowed to view, now return a real 404. Filterable via 'wc_wishlists_404_invalid_list'.
* Update: The wishlist pages now send noindex, nofollow via both an X-Robots-Tag header and the robots meta tag, so they are excluded from search indexes by default. Filterable via 'wc_wishlists_noindex_pages'.
* Add: WC_Wishlists_Pages::is_current_page() to test whether the current request is a wishlist page (is_wishlist_page() returns the configured page ID and is not a request-context check).
* Tweak: WC_Wishlists_Wishlist::get_wishlist() no longer writes to the object cache when a list ID does not resolve. The stored value could never be read back (wp_cache_get() cannot distinguish a cached false from a cache miss), so it cost a cache write per request without ever saving a query - noticeable when a crawler requests many invalid list IDs.
* Fix: Restored the $wishlists global used by the [wc_wishlists_button] shortcode; a 2.3.18 change stopped setting it, causing a fatal error (method call on null) wherever that shortcode rendered the wishlist button.
* Fix: Removed an invalid WooCommerce feature compatibility declaration ('product_blocks') that was triggering memory exhaustion during HPOS configuration on WordPress 7.0 / WooCommerce 10.8. The plugin now only declares its valid HPOS ('custom_order_tables') compatibility.
* Refactor: Replaced the legacy is_woocommerce_active() bootstrap shim with the standard 'Requires Plugins: woocommerce' header and a class_exists( 'WooCommerce' ) runtime guard.
* Update: Tested up to WordPress 6.9
* Update: Tested up to WooCommerce 10.7
* Update: Tested up to WordPress 6.9.1
* Update: Tested up to WooCommerce 10.6
* WP and WC compatibility tags. PHPCS fixes
* Fix: Fix WordPress 6.7 translation loading warning by loading textdomain on plugins_loaded hook instead of init hook.
* Fix: Fix a critical issue where updating a wishlist in the admin backend would delete all wishlist items. This was caused by overzealous PHPCS fixes in version 2.3.7 that incorrectly included wishlist_items in the explicit POST data array when it's not part of the admin form.
* Update: Basic source code cleanup.
* Update: WordPress 6.9 compatibility.
* Dev - Bump WooCommerce "tested up to" version 10.3.
* Dev - Bump WooCommerce minimum supported version to 10.1.
* Dev - Bump WordPress "tested up to" version 6.9.
Back
Top