WooCommerce Wishlists v2.3.20
2026.08.12 - version 2.3.20
* 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.
