Quote from ether-engineer on January 31, 2026, 01:54

Subject

Intermittent fatal error on PHP 8+: preg_match(): Argument #2 ($subject) must be of type string, array given caused by WooCommerce handles (wc-jquery-ui-touchpunch / wc-price-slider) registered with src as an array

---

Summary

On a WordPress + WooCommerce site running PHP 8.x, we are seeing an intermittent fatal error originating from WordPress core (wp-includes/class-wp-scripts.php:411) while printing footer scripts (wp_footer()).

The crash happens because a WooCommerce script handle (most frequently wc-jquery-ui-touchpunch and/or wc-price-slider) ends up with its src property being an array, not a string URL. WordPress expects a string and runs preg_match() on it; in PHP 8+ this produces a TypeError and breaks the request.

---

Impact

• Fatal error / HTTP 500 on frontend requests.
• Appears “random” because it is triggered by specific page renders and also by bots (Googlebot/Bingbot/etc.).
• Negative SEO impact (crawlers receive 500 on product/shop/category/sitemap-related requests).

---

Fatal error evidence (stack trace)

Captured from WP/WooCommerce logs:

2026-01-30T22:14:27+00:00 Critical Uncaught TypeError:
preg_match(): Argument #2 ($subject) must be of type string, array given
in /wp-includes/class-wp-scripts.php:411

Backtrace:
#0 wp-includes/class-wp-scripts.php(411): preg_match()
#1 wp-includes/class-wp-dependencies.php(137): WP_Scripts->do_item()
#2 wp-includes/class-wp-scripts.php(804): WP_Dependencies->do_items()
#3 wp-includes/script-loader.php(2173): WP_Scripts->do_footer_items()
#4 wp-includes/script-loader.php(3726): print_footer_scripts()
...
#13 wp-content/themes/astra/footer.php(33): wp_footer()
...

This confirms the crash occurs during footer script output.

---

Evidence: src is an array for those handles

We added defensive logging to capture the scripts queue. The following entries were observed (real examples):

{
  "time":"2026-01-30T22:58:57+00:00",
  "type":"script_footer_queue",
  "handle":"wc-jquery-ui-touchpunch",
  "src":["jquery-ui-core","jquery-ui-slider"],
  "uri":"/sitemap_index.xml",
  "ua":"Mozilla/5.0 ...",
  "ip":"..."
}

and:

{
  "time":"2026-01-30T22:58:57+00:00",
  "type":"script_footer_queue",
  "handle":"wc-price-slider",
  "src":["jquery-ui-slider","wc-jquery-ui-touchpunch"],
  "uri":"/sitemap_index.xml",
  "ua":"Mozilla/5.0 ...",
  "ip":"..."
}

Conclusion: these scripts are being registered (or re-registered) with a non-string src value (array), which triggers the fatal error when WP core tries to process it.

---

Likely root cause: incorrect wp_enqueue_script() usage

Using code search (String Locator), we found occurrences in:

• wp-content/plugins/woocommerce-products-filter/index.php

where there appears to be code similar to:

• wp_enqueue_script('wc-jquery-ui-touchpunch', array('jquery-ui-core','jquery-ui-slider'));
• wp_enqueue_script('wc-price-slider', array('jquery-ui-slider','wc-jquery-ui-touchpunch'));

This is an incorrect use of the wp_enqueue_script() signature:

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );

In the examples above, the dependency array is being passed as $src.

Correct usage would be something like:

wp_enqueue_script('wc-jquery-ui-touchpunch', $src_string, array('jquery-ui-core','jquery-ui-slider'), $ver, true);

Or ideally, avoid re-enqueuing/re-registering these WooCommerce core handles and let WooCommerce manage them.

---

Environment

• WordPress:  latest
• WooCommerce: active
• Theme: Astra pro
• Plugin: WOOF - WooCommerce Products Filter / HUSKY (v2.2.5.6)
• Trigger pattern: Intermittent; often on shop/category/product pages (and sometimes sitemap-related requests), including bot traffic.

---

Steps to reproduce (likely)

1. Enable WooCommerce + WOOF/HUSKY.
2. Visit pages where the filter/price slider scripts are enqueued (shop/categories/product listings, etc.).
3. Not sure how exactly this is triggered, but is triggered from time to time
4. On some requests, wc-jquery-ui-touchpunch and/or wc-price-slider are present with src as an array.
5. When wp_footer() prints scripts, WP core runs preg_match() on src → fatal error.

---

Temporary workaround we applied

We implemented a MU-plugin as a defensive patch that:

• detects scripts/styles with non-string src
• re-registers wc-jquery-ui-touchpunch and wc-price-slider with correct URLs (using WC()->plugin_url() and proper deps)
• prevents the fatal and logs the incidents

This is a mitigation only; the underlying issue seems to be WOOF/HUSKY registering/enqueuing these handles incorrectly.

---

Request to maintainer / support

Could you please confirm whether in WOOF v2.2.5.6 there is code that:

• enqueues or re-registers wc-jquery-ui-touchpunch / wc-price-slider, or
• calls wp_enqueue_script() with an array passed as the $src argument?

If so, please:

1. fix the wp_enqueue_script() call signature ($src must be a string URL or false, not an array)
2. avoid overriding WooCommerce core handles, or re-register them correctly
3. release a patch/hotfix version