A client called me last week, frustrated. Their WooCommerce shop, a solid earner, had started spitting deprecation notices everywhere after a routine update. Nothing was broken outright, but the logs were filling up and it was making everyone nervous. They wanted to know why their custom WooCommerce inline script was suddenly acting up, since it used to be the recommended approach.
The cause traced straight back to WooCommerce 10.4 and the deprecation of wc_enqueue_js(). It is not a random change. It brings WooCommerce in line with how modern WordPress core handles scripts, and it is better for performance. For years we leaned on wc_enqueue_js() for inline JavaScript because it was convenient. The catch is that it always wrapped your code in a jQuery dependency, even when your script never touched jQuery. That is dead weight on every page, and it slows the site down.
Why your WooCommerce inline script needs an update
The real problem with wc_enqueue_js() was that it was rigid. It forced a jQuery dependency onto every bit of inline JavaScript. Loading all of jQuery just to run a single console.log() is a waste. That made pages heavier, which hurts most on sites that are trying to cut JavaScript. The WooCommerce team took the feedback and moved to a leaner approach, which they lay out on the WooCommerce Developer Blog.
My first instinct, and I have watched other developers do the same, was to lift the inline part and drop it into a wp_add_inline_script() call. Quick fix? Not really. Swapping functions without registering and enqueueing the script they belong to just invites trouble. You get untracked scripts, loading order surprises, and you have still missed the point of the deprecation, which is being explicit about dependencies.
The right way to handle inline JavaScript in WooCommerce
The modern WordPress pattern gives you control and keeps things clear. You register your script, enqueue it, and then add your inline JavaScript. That way you decide the dependencies, so jQuery only loads when your script truly needs it. That is how you keep a WooCommerce inline script lean.
- Register your script: Use
wp_register_script()to set the handle, the source (which can be empty for inline-only scripts), and the dependencies. - Enqueue your script: Call
wp_enqueue_script()with that handle. - Add inline JavaScript: Then call
wp_add_inline_script()against the same handle, and only list dependencies this particular inline script actually needs.
Migrating from the old pattern to the new one
Say you had some simple inline JS written the old way:
<?php
wc_enqueue_js( "console.log('Hello from bbioon WooCommerce!');" );
?>Here is how you would refactor it into the recommended pattern:
<?php
add_action( 'wp_enqueue_scripts', 'bbioon_enqueue_custom_script' );
function bbioon_enqueue_custom_script() {
$bbioon_handle = 'bbioon-custom-script';
// Register the script. No source needed if it's only inline JS.
// Set dependencies to an empty array if no jQuery or other libs are needed.
wp_register_script( $bbioon_handle, '', array(), bbioon_get_version(), true );
wp_enqueue_script( $bbioon_handle );
// Add your inline script, explicitly without jQuery if not needed.
wp_add_inline_script( $bbioon_handle, "console.log('Hello from bbioon WooCommerce!');" );
}
// Helper function for versioning, typical in plugins/themes
function bbioon_get_version() {
// Replace with your theme/plugin version
return '1.0.0';
}
?>Notice the bbioon_get_version() helper. Always version your scripts, since it saves you from caching headaches after an update. That is the whole change: no forced jQuery, and dependencies you declare explicitly. It loads lighter and runs faster than the old wrapped version did.
Don’t let deprecations turn into technical debt
The deprecation of wc_enqueue_js() is WooCommerce telling you where things are headed. Ignore the warnings and you just let technical debt pile up. Modern WordPress work leans on performance and explicit dependencies, and your code should too. Update these old patterns now and your site stays fast and keeps working with future WooCommerce releases.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably run into it before.
