Darren Ethier (nerrad)

I did some digging @emacencini and I’m convinced this is due to a plugin conflict (potentially the one that @shahzeenfarooq discovered). Here’s a few more details to highlight why I think this:

There is a PR that was introduced in the 10.6.0 release (which would also be in 10.6.1 in your case) which fixed a bug with timezone not being detected correctly. The fix is a good one, but one nuance is that in fixing the bug, it exapanded the conditions under which moment().tz() is called which in surfaced a latent plugin conflict. Prior to 10.6.0 this plugin conflict wouldn’t have surfaced because of the timezone detection bug.

The .tz() method comes from the moment-timezone script, not base moment, which WooCommerce bundles in it’s scripts –moment is externalized to WordPress; moment-timezone is bundled into WooCommerce’s JS.

Here’s the dependency chain:

moment is externalized to WordPress; moment-timezone is bundled into WooCommerce’s JS.

1. WordPress ships moment as a registered script handle. It’s declared in the $vendor_scripts array in wp_default_packages_vendor(). The @wordpress/dependency-extraction-webpack-plugin externalizes import moment from 'moment' to the global window.moment.
2. moment-timezone is NOT externalized — it’s bundled into WooCommerce admin’s JS chunks. The MomentTimezoneDataPlugin trims timezone data at build time, confirming it’s processed by webpack. At runtime, moment-timezone extends the global window.moment object with the .tz() method. It’s declared as an npm dependency in both packages/js/date/package.json and plugins/woocommerce/client/admin/package.json.
3. @woocommerce/date is listed in wcAdminPackages and bundled into admin chunks. It imports both moment and moment-timezone. Its getStoreTimeZoneMoment() calls .tz() on the moment instance when the store timezone is a named timezone (e.g. America/New_York).

Since moment is a global external and moment-timezone extends it by mutating moment.prototype, the conflict vector is: if a third-party plugin enqueues a script that replaces window.moment after WooCommerce’s bundle has loaded, the .tz() method disappears. A lazy-loaded chunk like customizable-dashboard.js then calls .tz() on the clobbered moment and gets tz is not a function.

So, it’d be really helpful @emacencini if you could verify in your environment this is due to a plugin conflict. It’d be any other plugin that is using moment. In general, we’re going to be moving away from using the moment library because it’s fairly heavy. But until then, risk of conflicts like this still exist unfortunately. We’ll also take a look at implementing a more defensive check for this type of error.

Hi there,

Carding attacks are the bane of online commerce! A solution like Anti-Fraud for WooCommerce might work for you?

Do the affected products have a large amount of variations/attributes? I noticed you have a high value for the PHP max_input_vars config.

Hi there, I posted an update in a separate thread about this issue. Submitting a ticket via the form should work now (but chat is not working at the moment – there’s an issue with the service provider that we’re working on).

You may need to set the max_input_vars configuration for PHP on your server to a higher value with that many variations.

Hi there, thanks for posting about this. I’ve shared this with the relevant folks on WooCommerce.com and it’ll be looked into. Will you share more details about what options you are selecting from the form?

If you are experiencing firewall issues, this advisory should provide some guidance.