Bug Report – Duplicate Product loses buy button

  • Resolved Alpha Vale Tec

    (@donatelol)


    1 week, 2 days ago

    Duplicate Product loses buy button / stock meta until toggled between Simple and Variable product types

    Description: When duplicating a product in WooCommerce, the newly duplicated product (or existing duplicated products after WooCommerce/WordPress updates) loses the “Add to Cart” button on the frontend, behaving as if it were out of stock or missing price data, even though stock status and prices are correctly set in the admin area.

    This issue has been occurring across multiple recent WooCommerce versions.

    Steps to Reproduce:

    1. Go to Products > All Products.
    2. Click Duplicate on an existing Simple Product.
    3. Publish/Save the duplicated product.
    4. View the product page on the frontend: The “Add to Cart” button is missing or disabled.
    5. Edit the product in the admin area:
      • Change product type from Simple product to Variable product.
      • Change product type back from Variable product to Simple product.
      • Click Update.
    6. View the frontend again: The “Add to Cart” button immediately reappears and functions normally.

    Expected Behavior: Duplicating a product should properly clone and write all relevant postmeta (_stock_status, _price, _wc_type) and populate wc_product_meta_lookup without requiring a manual product type toggle.

    Actual Behavior: The duplicated product’s meta/lookup table entries become desynchronized or missing, suppressing the buy button on the frontend until forced to resync by changing product types.

    Environment / Notes:

    • <font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>Versão WooCommerce: </font></font><font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>11.1.0</font></font>
    • <font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>Versão WordPress: </font></font><font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>7.1</font></font>
    • <font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>Tema: WoodMart / Loja Virtual (O problema persiste independentemente do tema ativo)</font></font>
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support Gabriel – a11n

    (@gabrielfuentes)

    1 week, 1 day ago

    Hi @donatelol, thanks for the detailed write-up, it made this quick to test properly.

    Okay so I tried to reproduce it on a clean install running your exact versions, WordPress 7.1 and WooCommerce 11.1.0, with no other plugins active. I duplicated a simple product using the Duplicate link, published it from the product editor, and checked the result on both a block theme and Storefront, etc. The duplicate came out with the correct price and stock status, a correct row in wc_product_meta_lookup, and an Add to Cart button identical to the original’s.

    Since duplication on its own doesn’t seem to cause this, the first thing worth doing is a full conflict test. You note it persists regardless of the active theme, but it would help to know exactly what that covered. Could you deactivate every plugin except WooCommerce, switch to a default theme such as Storefront or Twenty Twenty-Five, then duplicate a product and publish it?

    If the button is still missing under those conditions, that’s very different from what I saw on my test site and we’ll dig in from there. If it works, we reactivate things one at a time until it breaks again.

    Worth knowing either way: the Add to Cart button on a single product page isn’t driven by wc_product_meta_lookup, which is used for catalog sorting and filtering. It depends on the product having a price, so an empty _price is the more likely culprit. That’s also why the type toggle works, since WooCommerce only recalculates _price when the regular price, sale price, sale dates or product type change, and a normal save changes none of those.

    Let me know how the conflict test goes.

    Thread Starter Alpha Vale Tec

    (@donatelol)

    1 week, 1 day ago

    Hi,

    Thank you for the detailed feedback and for testing this in a clean environment.

    We completely understand that this behavior could be influenced by a third-party interaction rather than WooCommerce core alone. To help your team investigate how this might happen (or improve how edge cases are handled), here are the technical details of what we observed in our database and environment during testing:1. Database State Identified

    Upon inspecting the duplicated products, we noticed:

    • The _regular_price meta key was correctly copied and visible in the WP Admin product editor input field.
    • However, the calculated _price meta key in wp_postmeta was missing or empty.
    • Because _price was empty, WooCommerce filtered the product out of category queries (even with Hide out of stock items disabled) and suppressed the “Add to Cart” button on the single product page.

    2. Why the Type Toggle Resolved It

    As you pointed out, changing the product type from Simple -> Variable -> Simple forces WooCommerce to trigger its internal price recalculation logic. Once saved this way, the _price meta key was successfully written to wp_postmeta, immediately restoring the product in catalog queries and displaying the buy button.3. Potential Triggers in Our Environment

    <font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>Como uma instalação limpa não reproduziu o problema, suspeitamos que, durante a duplicação de produtos, algum código de terceiros possa estar interferindo no processo de salvamento e impedindo a </font></font>_price<font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>conclusão da rotina de recálculo padrão. </font></font>

    4. Observations on Tools & Behavior

    • When we tested WooCommerce > Status > Tools (e.g., Regenerate product lookup tables), it did not populate _price because lookup tools appear to read existing postmeta values rather than recalculating empty _price entries for Simple products.
    • Even with “Hide out of stock items from catalog” unticked, the missing _price meta caused the query to treat the product as having an invalid price, removing it from catalog lists entirely rather than just marking it out of stock.

    We hope these details regarding the _regular_price vs _price desynchronization during duplication are helpful for your development team when considering how duplication hooks and price recalculation fallbacks are handled!

    <font dir=”auto” style=”vertical-align: inherit;”><font dir=”auto” style=”vertical-align: inherit;”>Atenciosamente,</font></font>

    Plugin Support Gabriel – a11n

    (@gabrielfuentes)

    1 week, 1 day ago

    Hi @donatelol,

    Thanks, that’s genuinely useful. The _regular_price being present while _price is empty is exactly what I suspected, and having it confirmed on a real affected site is the part I couldn’t get from testing.

    Your point about fallbacks is a fair one, so I’ve raised it:

    https://github.com/woocommerce/woocommerce/issues/68605

    It covers what you spotted, which is that nothing rebuilds _price once it’s gone. A normal save doesn’t, and Regenerate product lookup tables doesn’t either, because it reads _price rather than recalculating it from _regular_price. I verified all of that on a test site and you’re credited in the issue for both observations.

    What’s still open at your end is what’s emptying _price in the first place. That isn’t coming from WooCommerce’s duplication, so it’ll be something else on the site, and it’ll keep happening to new duplicates until it’s found. If you want to chase it, deactivating all plugins and duplicating a product after each one is the quickest route, and I’m happy to work through that with you.

    In the meantime the type toggle stays your fix for anything already affected.

    Cheers!

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.