15 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.
14 of 15 releases scanned clean
v4.0.3Latest
October 25, 2026191.4 KBScanned
Fixed
- Product fields inside Repeater rows price the cart item and the order.
- Editing a cart item restores every Repeater row with its values.
September 27, 2026123.6 KBScanned
Improved
- Tested up to WooCommerce 11.1
Fixed
- After a form attached to a product was edited, viewing the cart or checkout could send that form's notifications and create a Gravity Forms entry for every affected cart item, on every page view, and ordering again with the "revalidate" setting did the same. Checking whether a saved entry is still valid submitted the whole form. It now only validates it, and nothing is saved or sent.
- That check also rejected cart items that were still valid - list fields, numbers in a decimal-comma format, and fields set to allow no duplicates (the value matched the item's own entry) - and on a form with several items in the cart, one item's result could carry over to the next. An item whose form had been deleted caused a fatal error instead of asking to be reconfigured.
- Ordering again with the "resubmit" setting rejected valid items (list fields, email confirmation, decimal-comma numbers), could fatal on list fields with columns or a deleted form, ran the form's feeds from the second item on, lost the customer's single-file uploads and added a broken link to multi-file uploads. The order's own values and files are now carried into the cart.
- Editing a cart item and saving it without changing anything doubled its quantity. The saved quantity now replaces the old one.
- Choosing a variation on a product with a form filled the browser console with around 250 Gravity Forms deprecation warnings, and relied on a Gravity Forms function that is removed in Gravity Forms 4.0. The totals are now recalculated through Gravity Forms 3's products module.
v3.8.4Unavailable
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.3Unavailable
August 29, 2026115.5 KBScanned
Improved
- WordPress 6.5 is now the minimum supported version
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.
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.