Upsell funnel and product variants: what is actually happening (Ticket 1528851)

Short answer

Your product, your variants and your downloads are all set up correctly. Both problems you reported are the same single fault, and it is not in the variant feature itself.

On your offer page, SureCart's product page JavaScript module is not running. That module is what makes a variant choice real. Without it the pills render struck through and every choice a shopper makes is thrown away, so the offer is always bought as the first variant.

Something on the site is stopping that one file from executing. In almost every case it is a JavaScript optimizer, a "delay JS" or "combine JS" setting, a CDN script rewriter such as Cloudflare Rocket Loader, or a cookie consent tool that blocks scripts until consent.

I reproduced both symptoms on this demo site

This demo runs SureCart 4.7.0, the same version you are on, with a digital product called "Monday Altar Devotional" that has one variant option, Format, with the values PDF and Notion. Each variant has its own download file attached. There is an upsell funnel offering that product.

Here is the offer page with the module blocked, and the same page with the module allowed to run. Nothing else changed between the two shots. No product setting, no stock setting, no plugin version.

1. Your site today

Both pills filled in and struck through. Button still reads "Add To My Order".

2. Healthy

One pill highlighted. No strikethrough.

3. Genuinely out of stock

Struck through, but only one pill is filled. Button changes to "Sold out".

Column 1 is your screenshot. Column 3 is what a real out of stock variant looks like. They are not the same picture, and the difference is decisive:

  • In the real out of stock case only one pill is filled in, because only one option can ever be the selected one, and the buy button changes to a disabled Sold out.
  • In your case both pills are filled in at once, which is impossible, and the button still reads Add To My Order.

Both pills selected at once plus a normal buy button is the signature of the JavaScript module failing. That combination cannot be produced by any stock setting.

Why radio and dropdown behave differently

It is one fault, but it shows up in two different ways depending on which display type the Format option uses. This is why it felt like two separate bugs.

  • Radio (pills). The pill highlight is drawn by that same JavaScript. With the module dead the highlight logic returns garbage, so every pill is painted as selected and as unavailable at once. That is the strikethrough. Clicking a pill also does nothing, because the click handler lives in the dead module.
  • Dropdown. A dropdown is a plain browser control, so it visibly changes when the shopper picks Notion even with the JavaScript dead. It looks like it worked. But nothing recorded the choice, so the offer is still submitted with the first variant, and the buyer receives the first variant's download. This is silent, which is why you only noticed it on the dropdown.

The measurement, not a guess

I ran a real test purchase on each setting and then read back which file the buyer was actually entitled to.

  • Dropdown, module blocked, shopper picks Notion → delivered PDF-EDITION.pdf. Wrong.
  • Radio, module blocked, shopper clicks Notion → delivered PDF-EDITION.pdf. Wrong.
  • Dropdown, module running, shopper picks Notion → delivered NOTION-EDITION.html. Correct.
  • Radio, module running, shopper clicks Notion → delivered NOTION-EDITION.html. Correct.

So per variant downloads through an upsell funnel do work correctly in 4.7.0. The delivery only goes wrong when that script never runs.

Check your own site in about 30 seconds

Open one of your own offer pages, the one in your screenshot is fine, and try these in order. The first two need no developer tools at all.

  1. Click the other Format pill. If it does not become the highlighted one, the module is dead. That alone confirms it.
  2. Watch the address bar. When the module is working, picking a variant appends something like ?format=notion to the URL. If the URL never changes when you switch variants, the module is dead.
  3. Open the browser console. Right click the page, choose Inspect, open the Console tab, reload. A red error such as Cannot destructure property 'addQueryArgs' of 'wp.url' as it is undefined, or a failed request for /wp-content/plugins/surecart/packages/blocks-next/build/scripts/product-page/index.js, is the cause.
  4. Inspect a pill. In the Elements tab, click one of the Format pills. If it carries aria-disabled="[object Object]" then this is definitely the fault. A healthy pill reads aria-disabled="false".

Try it live on this demo

You can watch the fault appear and disappear on this site, on the same page, without changing any product setting.

  1. Click the button below. It puts a five dollar test item in the checkout. The store is in test mode, so pick Test Processor and complete the purchase with any email address. No real money moves.
  2. You will land on the offer page for the Monday Altar Devotional. Switch the Format pill and watch the URL gain ?format=. This is the healthy behaviour.
  3. Now open this link to switch on a simulation that blocks that one script, then run the test purchase again. The pills will come back struck through, exactly like your screenshot, and picking Notion will deliver the PDF.
  4. Open this link to switch the simulation back off.

How to fix it on your site

The goal is simple: let that one file load and run, untouched, on the offer page. Turn optimizations off one at a time and retest the offer page after each change.

  • Cloudflare. Speed, then Optimization, then Content Optimization. Turn Rocket Loader off. Rocket Loader rewrites script tags and breaks modern module scripts, which is exactly what SureCart uses here. Then purge the Cloudflare cache.
  • LiteSpeed Cache. Page Optimization, then JS Settings. Turn off JS Combine and Load JS Deferred, and clear any JS Delayed setting, at least while you test.
  • WP Rocket. File Optimization. Turn off Combine JavaScript files and Delay JavaScript execution, or add the exclusions below.
  • SiteGround Optimizer, Autoptimize, Perfmatters, NitroPack, W3 Total Cache. Same idea. Turn off combining, deferring and delaying of JavaScript.
  • Cookie consent plugins such as Cookiebot, CookieYes or Complianz. If script blocking is set to Automatic, it will hold these files back. Mark the SureCart and WordPress core scripts as necessary, or switch that mode off.

If you would rather keep your optimizer on, add these two paths to its JavaScript exclusion list, and never let it combine or delay them:

/wp-content/plugins/surecart/
/wp-includes/js/dist/

Those two are enough. The first is the SureCart module itself. The second is the small WordPress core script it depends on, and it is the one people usually forget, which leaves the exact symptom you are seeing.

One more thing to leave alone. The page also carries an inline block that starts with <script id="wp-importmap" type="importmap">. If your optimizer moves, merges or minifies inline scripts, that block has to be excluded too, or the module cannot resolve its imports.

The one other thing that can strike a pill through, and how to tell it apart

There is a second, unrelated way to get a line through a variant pill: real stock tracking. If Track quantity is on for the product or for an individual variant and the quantity is zero, SureCart correctly marks that option as sold out and strikes it through. Column 3 above is that case, produced on this demo.

The one second test: look at the buy button on the offer page.

  • Button reads Sold out and is greyed out → it really is a stock setting. Open the product, open the Variants box, and turn Track quantity off or give the variants a quantity.
  • Button still reads Add To My Order → it is the JavaScript fault described above. This is your case. Do not change your stock settings, they are not the problem.

What I would send back if this does not fix it

If the module still fails after every optimizer is off and every cache is purged, then send us these three things and we will take it to engineering:

  • A screenshot of the browser Console tab on the offer page, showing any red errors.
  • A screenshot of the Network tab filtered on product-page, showing the status code that file returns.
  • The list of active performance, security and cookie consent plugins on the site, plus whether the site sits behind Cloudflare or a similar CDN.
Scroll to Top