* Update: WordPress 6.5 is now the minimum supported version
* Fix: 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.
* Fix: On Gravity Forms 3.0, the product subtotal and total stopped displaying on the product page for forms that do not contain a Gravity Forms "Total" field. Gravity Forms 3.0 moved price calculation into a new module that only recalculates — and fires the gform_product_total filter our display relies on — when the form contains a form-specific total field. Forms built without a Total field (relying on our subtotal/total display) therefore showed blank prices, even though the correct price was still added to the cart. We now register the element Gravity Forms 3.0 requires so our totals display on load and update on every option change again, with no need to add a Total field to the form.
* Fix: A conflict with third-party Gravity Forms add-ons (such as GP Nested Forms) that could cause a fatal error (ArgumentCountError) when adding a product to the cart. While building the cart and order data we re-fire Gravity Forms' gform_pre_render filter, but were passing only the form object and not the additional arguments (ajax flag and field values) that Gravity Forms core supplies. Callbacks written to core's documented signature then received too few arguments. We now match core's signature at all three call sites.
* Update: Tested up to WooCommerce 11.0
* Fix: A false "Gravity Forms Not Found" admin notice appeared after updating to Gravity Forms 3.0, even though Gravity Forms was installed and working. Our admin check tested for the legacy RGForms class, which Gravity Forms 3.0 removed. We no longer perform our own runtime dependency detection — the plugin already declares WooCommerce and Gravity Forms via the WordPress "Requires Plugins" header, which WordPress 6.5+ enforces on activation. This removes the false notice and prevents this class of breakage from recurring on future Gravity Forms releases.
* Update: Requires at least WordPress 6.5 (required for the "Requires Plugins" dependency header).
* Fix: 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.
* Fix: Dynamic price calculation stopped updating when selecting product options after 3.7.7 (priced option fields such as checkboxes could stay at $0.00). Deferring the frontend script in 3.7.7 caused it to load after Gravity Forms 2.9+ initializes its price-field recalculation, so option changes no longer recalculated the total. The script now loads in the header (non-deferred), as it did before 3.7.7. The original WordPress 6.3 enqueue notice remains resolved (the invalid argument is no longer passed).
* Fix: 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.
* Fix: Compatibility with Gravity Forms 2.9+. GF's submission module binds a guard to #gform_<id> 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.
* Fix: 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.
* Fix: Compatibility with Gravity Forms 2.9.29+. Updated calls to GFCommon::get_lead_field_display() to pass the entry array as the third parameter instead of the currency string, resolving PHP warnings on cart, checkout, and order creation. Backward compatible with older Gravity Forms versions.
* Update: Tested up to WordPress 6.9
* Update: Tested up to WooCommerce 10.6
* Update: Tested up to WordPress 6.9.1
* Update: Tested up to WooCommerce 10.5
* Update: WP and WC compatibility
* Include better readme information about the extension and its features.