Clean Up Your WooCommerce Inline JS: Ditch wc_enqueue_js()

Just last week, a client called me up, frustrated. Their WooCommerce shop, a decent earner for them, suddenly started throwing deprecation notices all over the place after a routine update. Not breaking anything outright, but filling logs and causing anxiety. They wanted to know why their custom WooCommerce inline script wasn’t working as smoothly anymore, after all, it used to be the recommended way.

Turns out, their issue was tied directly to WooCommerce 10.4 and the deprecation of wc_enqueue_js(). This isn’t just a random change; it’s a move towards aligning with modern WordPress core practices and, frankly, better performance. For years, we’ve used wc_enqueue_js() for inline JavaScript, and it felt convenient. But here’s the kicker: it always wrapped your code in a jQuery dependency, even if your script didn’t need jQuery at all. That’s unnecessary overhead, man. And it impacts site speed.

Why Your WooCommerce Inline Script Needs an Update

The core problem with wc_enqueue_js() was its rigidity. It forced a jQuery dependency on every piece of inline JavaScript. Think about it: loading jQuery just to run a simple console.log()? Total waste of resources. This led to heavier page loads, especially on sites trying to shed unnecessary JavaScript. The WooCommerce team listened to the community, and they’re pushing us towards a cleaner, more efficient way, as detailed on the WooCommerce Developer Blog.

My first thought, and I’ve seen other developers do this, was to just grab the inline script part and chuck it into a wp_add_inline_script() call. Quick fix, right? Not really. Just blindly swapping functions without properly registering and enqueueing the script it belongs to is asking for trouble. You end up with untracked scripts, potential loading order issues, and you’re still missing the point of the deprecation: being explicit about dependencies.

The Right Way to Handle Inline JavaScript in WooCommerce

The modern WordPress way is all about control and clarity. You register your script, you enqueue it, and *then* you add your inline JavaScript. This gives you granular control over dependencies, ensuring jQuery is only loaded if your script actually needs it. This is how you optimize your WooCommerce inline script.

• Register your script: Use wp_register_script() to define your script’s handle, its source (which can be empty for inline-only scripts), and its dependencies.
• Enqueue your script: Call wp_enqueue_script() with your registered handle.
• Add inline JavaScript: Finally, use wp_add_inline_script(), referencing your script’s handle. This is crucial: only declare dependencies that are genuinely required for *this specific inline script*.

Example Migration from Old to New Pattern

Let’s look at a practical example. Say you had some simple inline JS using the old way:

<?php
wc_enqueue_js( "console.log('Hello from bbioon WooCommerce!');" );
?>

Here’s how you’d refactor that 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()` function. Always version your scripts, it helps with caching issues after updates. And that was it. Clean, explicit, and faster. This isn’t just about making your code work; it’s about making it work *better*.

Don’t Let Deprecations Become Technical Debt

The deprecation of wc_enqueue_js() is a clear signal from WooCommerce towards better development practices. Ignoring these warnings just piles up technical debt. Modern WordPress development prioritizes performance and explicit dependency management, and our code should reflect that. Updating these old patterns ensures your site remains fast, stable, and compatible with future WooCommerce versions. Period.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.