I would like to report a rounding issue with the discount percentage tag, followed by a proposal to streamline the discount dynamic data tags in Bricks.
1. The Bug: Decimal Rounding Issue When using the {woo_cart_item_save:percentage} dynamic data tag, the percentage is outputting raw decimal values instead of a rounded integer.
Example: For a product with a regular price of 45 and a sale price of 30, the tag outputs 33.33 instead of the expected 33 (whereas standard tags like {woo_product_on_sale} properly display -33%).
2. Feature Proposal: Unify Discount Dynamic Data Since {woo_product_on_sale} already works seamlessly in both the Product Query Loop and the Cart Loop, creating or maintaining separate tags like {woo_cart_item_save} creates unnecessary redundancy.
Instead, I propose enhancing {woo_product_on_sale} with standardized modifiers that work globally across both contexts:
{woo_product_on_sale} – Standard output with the % symbol (e.g., -33%).
{woo_product_on_sale:percentage} (or :raw) – Rounded percentage without the % symbol (e.g., 33).
{woo_product_on_sale:value} (or :amount) – The actual monetary discount amount (e.g., $15).
This fix and enhancement would eliminate decimal bugs, keep Bricks clean from duplicate tags, and give us total design flexibility in both cart elements and product grids.
Thanks for the suggestion. We agree that the discount percentage output should be consistent, without a decimal point following the product-on-sale percentage format for {woo_cart_item_save:percentage}.
However, we won’t reuse {woo_product_on_sale} for cart-item savings because the tags represent different values:
{woo_product_on_sale} represents the product’s configured catalog sale state and sale badge.
{woo_cart_item_save} compares the cart item’s effective price with its regular price.
The cart item price can be affected by the selected variation, dynamic-pricing extensions, product filters, and the cart’s tax-display configuration. These adjustments may not be represented by the product’s configured sale price. Coupons and order-level discounts remain intentionally excluded.
For example, a pricing extension could reduce an item from 45 to 25 without setting a WooCommerce sale price. In that case, the cart savings tag can report the effective discount, while {woo_product_on_sale} may correctly show no catalog sale.
Keeping the tags separate preserves this distinction while allowing us to make their displayed percentage formatting consistent.
May I ask whether the suggestions regarding the data dynamics of {woo_product_on_sale} will be considered? (For example, outputting the discount percentage as an integer, such as 33)
We will not work on the {woo_product_on_sale} tag right now.
Woo v2 focuses on the Cart, Checkout, and My Account.
I found that you already created another forum feature request post for {woo_product_on_sale} Support "value" for {woo_product_on_sale} Kindly add your suggestion and additional information on that thread.
We’ve addressed this in Bricks 2.4-rc (release candidate), now available for manual download from your Bricks account.
The cart-item savings percentage now returns a rounded whole number without a percent sign.
Please read the changelog entry before testing, and let us know if you experience any issues. Release candidates are not recommended for production sites.