The WooCommerce 10.5 Add to Cart button is disabled by default

If you keep a tidy asset list on your WooCommerce store, 10.5 may have quietly broken your variable product pages. The WooCommerce 10.5 Add to Cart button now ships disabled on variable products, and it stays that way until the variation script has finished initializing.

The reason is a race condition, and it is a real one. On a slow connection a shopper could pick an attribute and hit the button before the JavaScript was ready to handle the submission, so the add to cart call failed and the shopper got nothing for the click. The core team closed that window by putting a disabled attribute straight into the template.

Why the WooCommerce 10.5 Add to Cart button is now disabled

In 10.5 the variation-add-to-cart-button.php template ships with the disabled attribute hardcoded, and the core add-to-cart-variation.js script is what strips it back off once the variations have loaded. That split works fine until one half of it goes missing.

Plenty of us dequeue the default WooCommerce scripts, either to cut page weight or to run our own variation logic. Do that while still using the core template and your WooCommerce 10.5 Add to Cart button stays grayed out forever, because nothing is left to remove the attribute. Core updates and hand-rolled optimizations collide like this constantly.

The same release also changed how variation prices are cached, which I wrote up separately in WooCommerce variation price caching.

How to tell if your store is affected

You are affected if all of the following are true:

  • You sell variable products.
  • You have dequeued /client/legacy/js/frontend/add-to-cart-variation.js.
  • You have not overridden the variation-add-to-cart-button.php template in your theme.

Refactoring your custom script

The fix is to have your own JavaScript remove the disabled attribute once your variation logic has finished initializing. In plain JS that looks like this:

/**
 * Fix for WooCommerce 10.5 disabled Add to Cart button.
 * Ensure this runs after your custom variation logic initializes.
 */
document.addEventListener('DOMContentLoaded', function() {
    const variationForm = document.querySelector('.variations_form');
    
    // If you are using custom events, listen for them here
    variationForm.addEventListener('wc_variation_form_initialized', function() {
        const cartButton = variationForm.querySelector('.single_add_to_cart_button');
        if (cartButton) {
            cartButton.removeAttribute('disabled');
            console.log('WooCommerce 10.5 Add to Cart button enabled.');
        }
    });
});

On a jQuery setup, which plenty of older Woo stores still run, hook into the wc_variation_form event instead. Either way you are mirroring what the core script now does.

If this one is eating your dev hours, I can take it off your plate. I have been working with WordPress since the 4.x days.

What to check after upgrading

The change is good for stability and annoying for anyone maintaining a trimmed-down custom build. After any major update, check your wp_dequeue_script calls against what moved in the core templates. The new Add to Cart + Options block is not affected, since it runs on a different logic stack. Upgrade, then click through a variable product before you call it done.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.