WooCommerce Gravity Forms Product Add-ons v3.8.4
2026.09.03 - version 3.8.4
* Fix: Deactivating WooCommerce while this plugin was still active took the whole front end down with a critical error instead of a notice. WordPress checks a plugin's required plugins when it is activated, but not when one of those requirements is later switched off, so this plugin was left running with WooCommerce gone and called a WooCommerce function on every page. It now stops loading when WooCommerce is not present and starts again by itself once WooCommerce is back. This also covers a WooCommerce update that fails part way through.
* Fix: A product with a form attached could not be added to the cart by anything using WooCommerce's Store API, including saved wishlist rows and other extensions that re-add a previously configured item. The shopper was told only that the product "is not available for purchase". Adding a configurable product requires the form to have been filled in, and the check for that looked for a posted form - but a Store API request carries its data as JSON, so there was never a posted form to find and the item was refused. Where the request carries the entry that was already filled in and validated when the item was saved, that entry is now checked instead: it must belong to the form the product actually offers, and that form must still exist, still be active and not be in the trash. A genuinely unconfigured product carries no entry and is still refused, exactly as before.
* Fix: Gravity Forms' anti-spam checks could reject an add to cart with "there was a problem with your submission" and no field marked as wrong, so nothing the shopper corrected made any difference. A form on a product is not submitted the way Gravity Forms expects - WooCommerce's add to cart form is used as the form and posted directly - and the honeypot, the source URL check, the submission speed check and reCAPTCHA v3 can all read that as bot activity. Those checks are now switched off for forms attached to a product; forms used anywhere else keep their protection. The plugin has claimed to do this since the honeypot was introduced, but the setting it changed was never the one Gravity Forms reads.
* Fix: A required file upload field could report "there was a problem with your submission" even though the shopper had chosen a file, on themes that render their own add to cart form. A browser only sends the file itself when that form is marked enctype="multipart/form-data"; without it the field posts the file NAME as ordinary text and Gravity Forms sees the upload as missing. WooCommerce's own product templates set the attribute, so this only affected themes supplying their own markup - Divi's add to cart module is the reported case. The form is now given the attribute whenever it contains a file field. Multi-file upload fields were never affected, because they upload separately and do not depend on the enclosing form, which is why switching a field off multi-file mode appeared to cause the problem.
2026.08.29 - version 3.8.3
* Update: WordPress 6.5 is now the minimum supported version
