WooCommerce Gravity Forms Product Add-ons Changelog
Todas as versões registradas, da mais nova para a mais antiga, com o que mudou em cada uma.
Última 4.0.315 versões
Sem data · 15 versões
4.0.3
Última
2 correções
Corrigido
Product fields inside Repeater rows price the cart item and the order.
Editing a cart item restores every Repeater row with its values.
4.0.2
1 melhoria3 correções
Melhoria
The woocommerce_gforms_item_meta_rows filter receives a fifth argument, $context: 'cart' for the cart and checkout, 'order' for the order line.
Corrigido
Cart and order item details show without a deprecation notice under Gravity Forms 3.0 and later.
Repeater fields show one line per row under the field's label in the cart, checkout, order screen, emails and My Account, without a PHP warning.
The Item meta field pickers list only fields that hold entry data, and their selections are readable.
4.0.1
1 correção
Corrigido
Product pages built with WooCommerce's Add to Cart with Options block, as in the Purple theme: totals follow the options and the chosen variation, a form with a Total field adds priced options to the cart, and editing a cart item keeps its quantity.
4.0.0
8 novos9 melhorias11 correções
Novo
Form settings. Set a form's WooCommerce options once, on the form's new WooCommerce tab. Each section of a product can follow the form or use its own settings; existing products keep their own, so nothing changes on update.
Attach a form to product categories and tags. The form's tab lists every product using it, and a Form column for the Products screen (Screen Options) shows and filters by form.
Choose which form fields show with the item in the cart, checkout, emails and the order screen, or show one line built from merge tags.
Product field map. Set the cart item's weight, dimensions and quantity from form fields; the values reach the order, so shipping labels use them.
Add products with a form through WooCommerce's Store API, for headless stores and AI shopping assistants.
Cart items show an Edit link, and the block cart shows each answer on its own line.
Structured data takes a flat price or a price range, added to the product price or replacing it.
Hide the form's Gravity Forms Total field on the product page (Display: Total field).
Melhoria
Requires WooCommerce 11.0, WordPress 6.9 and Gravity Forms 2.9.
The Gravity Forms panel in the product editor is rebuilt. Custom admin CSS or JavaScript written for the old panel needs updating.
Gravity Forms Total fields no longer show under cart and order items. To show them: add_filter( 'woocommerce_gforms_hide_total_field', '__return_false' ).
Product page totals include tax the same way the product price does.
Multi-part fields marked wc-gforms-hide-from-email are hidden in the cart as well as on the order.
No database query on every page load to find products with forms.
woocommerce_gforms_field_display_text receives ( $display_text, $display_value, ... ) on orders as in the cart; a snippet written for the old order-side order needs its first two arguments swapped.
New filter woocommerce_gforms_resolved_settings( $settings, $product_id, $context ) filters a product's final settings after product and form settings are merged.
Removed the WooCommerce 2.x compatibility layer (WC_GFPA_Compatibility, wc_is_21x, is_wc_version_gte_2_2, is_wc_version_gte_2_3, is_woocommerce_active, WC_Dependencies) and the JavaScript function get_gravity_forms_price.
Corrigido
A product can only be added to the cart with its own form filled in: not with an inactive or deleted form, another form's submission, or a bare add-to-cart link or Store API request.
Order Again: a guest order's answers need its order key, a product without a saved entry asks for its options, and "resubmit" mode works without errors.
Editing a cart item keeps its quantity, including products sold individually and quantities set by a form field.
Saving an order's items keeps stock reduced by a form field.
Redirect and page confirmations no longer stop the item reaching the cart.
Theme add-to-cart buttons without WooCommerce's button class add the item to the cart.
Items in carts update when a form's prices, choices or conditional logic change, and country conditional logic saved before Gravity Forms 3.0.3 matches again.
Product page totals on variable, grouped and page-builder products and multi-page forms.
The text before and after the price shows once, and only on the storefront.
Errors with a non-numeric structured data price, and with merge tags whose order was deleted.
Dynamic Pricing live prices, Quick View and WooCommerce Bookings.
3.8.6
3 melhorias1 correção
Melhoria
Tested up to WooCommerce 11.2
PHP 7.4 is now declared as the minimum supported version, matching WooCommerce
Dynamic Pricing 4.0 compatibility: product-page totals use Dynamic Pricing's public function, so product and category tiers now apply at quantity 1. On Dynamic Pricing 3.6.x the existing behaviour is unchanged.
Corrigido
The "Enable Dynamic Pricing?" setting is no longer hidden or reset to No when Dynamic Pricing 4.0 is active.
3.8.5
1 melhoria5 correções
Melhoria
Tested up to WooCommerce 11.1
Corrigido
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.
3.8.4
3 correções
Corrigido
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.
3.8.3
1 melhoria
Melhoria
WordPress 6.5 is now the minimum supported version
3.8.2
1 correção
Corrigido
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.
3.8.1
2 novos4 melhorias2 correções1 alteração
Novo
attached form IDs are mirrored to indexed meta so products using a given form can be queried directly.
PHPUnit test suite.
Melhoria
product settings are now defined in one place, replacing duplicated declarations across the save and read paths.
cart item meta rows are now built by a single component, extracted from the cart class.
stock quantity handling now shares the plugin's single conditional logic evaluator rather than a second copy of it.
Tested up to WordPress 7.1
Corrigido
Products could be added to the cart at $0.00 when a Gravity Forms Product field was shown or hidden by a third-party conditional logic add-on (such as MCG Advanced Conditional Logic). When rebuilding a cart line item we evaluate the form's conditional logic to decide which product fields count toward the price, but that evaluation did not run Gravity Forms' gform_rule_pre_evaluation filter. Add-ons that express their rules through that filter had them left unprocessed, so a product field that was actually visible was treated as hidden and dropped from the price calculation, leaving the line item at $0.00. Conditional logic is now evaluated through Gravity Forms' documented extension points (gform_rule_pre_evaluation and gform_rule_source_value), so these add-ons behave the same way on the product page and in the cart.
Conditional logic rules using "greater than" or "less than" against a currency-formatted value were compared as text instead of as numbers, so a rule such as "greater than 1000" did not match a value of 1,234.00. Numeric comparisons now normalise the value first, matching Gravity Forms.
Alterações
Note: a one-time background task runs after updating to index existing products.
3.7.12
1 melhoria2 correções
Melhoria
Tested up to WooCommerce 11.0
Corrigido
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.
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.
3.7.11
1 melhoria
Melhoria
Requires at least WordPress 6.5 (required for the "Requires Plugins" dependency header).
3.7.10
1 correção
Corrigido
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.
3.7.9
1 melhoria
Melhoria
Tested up to WooCommerce 10.9
3.7.8
1 correção
Corrigido
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).
Changelog publicado pelo desenvolvedor, no idioma original.
