13 versions
Woocommerce Gravity Forms Add-Ons history.
Every release of Woocommerce Gravity Forms Add-Ons is archived here with its changelog, file size, and security scan result. Use the archive to roll back to a stable release or audit what changed between updates.
12 of 13 releases scanned clean
v3.8.4Latest
September 3, 2026121.3 KBScanned
Fixed
- 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.
- 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.
- 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.
- 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.
v3.8.2Unavailable
August 25, 2026115.5 KBScanned
Fixed
- On themes that add products to the cart via AJAX, a single click of Add to Cart could add a quantity of 2. Affected products used any attached form, including forms with no pricing fields. These themes (BeTheme is one, when WooCommerce's "Enable AJAX add to cart buttons on archives" setting is on) take over the Add to Cart button, serialise the whole form with FormData and post it to admin-ajax.php as a woocommerce_add_to_cart request. FormData omits submit buttons but includes hidden inputs, so the hidden "add-to-cart" field we add to the form travelled with that request - and WooCommerce then added the product twice from the one request, once through its form handler (which runs on any request carrying an add-to-cart value) and once through its AJAX handler. WooCommerce's own templates already carry that value on every purchasable product type - on the submit button for simple products, and on WooCommerce's own hidden input for variable and grouped ones - so our copy was redundant on a normal product page. It is only needed on the pages of a multi-page form, where we remove the submit button and move between pages by submitting the form in the background. It is now emitted only in that case, so the AJAX request no longer triggers the second add.
v3.7.10Unavailable
July 18, 2026104.1 KBScanned
Fixed
- Cart quantity management (the "cart quantity field" feature) stopped working for products with "Sold individually" / "Limit purchases to 1 item per order" enabled. WooCommerce 10.7 added a cart check that force-resets any sold-individually product back to a quantity of 1 on every cart render, which clamped the quantity our feature had set from the form field (showing an incorrect total and a "You can only have 1 ... in your cart" notice). We now re-apply the form-driven quantity and price after WooCommerce's cart check and suppress that false notice, without disabling "Sold individually" (so the quantity input stays locked and the product still cannot be added twice). Products without cart quantity management, and manually-edited quantities on products that are not sold individually, are unaffected.
v3.7.7Unavailable
June 17, 2026101.9 KBScanned
Fixed
- wp_enqueue_script() was called with a 'defer' key in the $args array, which has not been a recognized key since WordPress 6.3. This triggered a "called incorrectly" notice and left the scripts un-deferred. Switched to the supported 'strategy' => 'defer' argument.
- Compatibility with Gravity Forms 2.9+. GF's submission module binds a guard to #gform_ that blocks any native form submit it doesn't recognize ("Unsupported submission flow detected"), which could prevent Add to Cart on some themes (e.g. Flatsome) depending on script load order. We now neutralize that guard for our add-to-cart submit using a capture-phase listener, independent of load order, without affecting other submit paths.
- The frontend script and stylesheet cache-buster was not tied to the plugin version, so returning visitors could be served stale JS/CSS after an update. Asset versions are now derived from the plugin version automatically.
v3.7.5Unavailable
May 4, 2026100.3 KBScanned
Improved
- Tested up to WordPress 6.9
- Tested up to WooCommerce 10.7
Why archive
Sometimes the latest release isn't the one you need. The archive lets you pin Woocommerce Gravity Forms Add-Ons to a known-good version, or roll back while a bug is investigated. Every release stays scanned and reachable.