WooCommerce Wishlists Version 2.3.20 Changelog

* 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.

WooCommerce Anti Fraud Version 8.0.3 Changelog

* Fix: ANTIFRAUD-240 – reCAPTCHA checkout placement still unresolved on block checkout after ANTI-FRAUD-184
* Update: ANTIFRAUD-253 – AI Fraud Prevention does not run during manual Fraud Check and silently skips when setup is incomplete
* Fix: ANTIFRAUD-254 – Anti-Fraud PayPal Verification email can trigger with blank recipient when PayPal-specific payer email is unavailable
* Update: ANTIFRAUD-258 – Wording on the setting page/License Management is confusing and should be updated
* Fix: ANTIFRAUD-260 – PHP 8 Fatal Error Risk When wc-af-check Uses Associative WP-Cron Arguments
* Fix: ANTIFRAUD-268 – Anti-Fraud repeatedly enables “Adjust status from fraud score†after plugin upgrades
* Fix: ANTIFRAUD-269 – Anti-Fraud 8.0.1 upgrade can disable Checkout reCAPTCHA
* Fix: ANTIFRAUD-279 – Investigate orphaned Anti-Fraud checks in 8.0.2

@WPspringcom Facebook
Item added to cart.
0 items - $0