WooCommerce has a lot of styles and scripts that it enqueues. Their asset managers are also full of hooks so if you have your own WooCommerce related styles, you could hook into those and be sure they are loaded when needed.

WooCommerce Assets are managed also through the WordPress core functions such as:

  • wp_enqueue_script
  • wp_enqueue_style
  • wp_register_script
  • wp_register_style
  • wp_localize_script

There are two classes that manage WooCommerce Assets, depending on front and admin part of your site:

  • WC_Frontend_Scripts
  • WC_Admin_Assets

Controlling the Front WooComerce Assets

The class WC_Frontend_Scripts can be used to remove some assets, add new or even change the path.

Hosting Assets Elsewhere

If you have a custom setup and your CSS and/or JS is hosted elsewhere (maybe through a CDN), you can change the path to those files. That can be done using the filter woocommerce_get_asset_url . This filter will receive two parameters:

  • full URL to the current asset
  • path /assets/....

In case you have a proxy or a setup done to handle those scripts through a different domain such as assets.mysite.com and don’t want to complicate things, you could make them accessible through assets.mysite.com/assets/... and use just this to manage that:

add_filter( 'woocommerce_get_asset_url', 'change_asset_url', 10, 2 );

function change_asset_url( $url, $path ) {
 return 'https://assets.mysite.com/' . $path;
}

Enqueueing with WooCommerce

If our styles rely on WooCommerce, we can let WooCommerce enqueue our own styles. This can be done using the filter woocommerce_enqueue_styles. This filter accepts arrays where the array key is the style handle. Here is an example of a configuration of asset.

'woocommerce-layout'      => array(
					'src'     => self::get_asset_url( 'assets/css/woocommerce-layout.css' ),
					'deps'    => '',
					'version' => $version,
					'media'   => 'all',
					'has_rtl' => true,
				),

We need to have a unique key for handle and then an array that has src, deps, version, media and has_rtl. Here is how we could enqueue our own style:

add_filter( 'woocommerce_enqueue_styles', 'enqueue_our_own_style' );

function enqueue_our_own_style( $styles ) {
 $styles = array(
  'src' => URL_TO_ASSETS . '/css/style.css',
  'deps' => '',
  'version' => '1.0',
  'media' => 'screen',
  'has_rtl' => false
 );
 return $styles;
}

Localizing WooCommerce Script Data

By using wp_localize_script, developers add data for JavaScript that can be used but that had to be retrieved from backend. They were primarily used for localized strings but are now used for providing other data such as url to AJAX and similar.

WooCommerce adds such data for various scripts. For example, for the script with handle wc-country-select, WooCommerce provides an attribute countries where all countries are listed. For wc-add-to-cart, it has the ajax_url where the data will be sent when adding a product to cart.

So if we are working with some of those scripts and have our own custom JavaScript code hooked with some of the triggerHandle part in WooCommerce scripts, we might need some parameters added in there. We can use the filter woocommerce_get_script_data. This filter will get the parameters that will be made available and the handle for which we do it.

Let’s imagine that we have a completely custom way of adding products to the cart and we don’t want to use WP AJAX or WC REST API. We would do it like that:

add_filter( 'woocommerce_get_script_data', 'change_wc_url_params', 20, 2 );

function change_wc_url_params( $params, $handle ) {
 if ( 'wc-add-to-cart' === $handle || 'wc-add-to-cart-variation' === $handle ) {
   $params    = URL_WHERE_YOU_WANT_DATA_TO_BE_SENT;
   $params = URL_WHERE_YOU_WANT_DATA_TO_BE_SENT;
 }
 return $params;
}

Removing all Front WooCommerce Assets

What if you have a really complex thing going on and you just need WooCommerce to handle the admin part and have the backend code. But you’ll build everything on the front using a different approach, maybe a complete React app within the WordPress theme? You would want to remove any assets from WooCommerce then.

You can do it like this:

remove_action( 'wp_enqueue_scripts', array( 'WC_Frontend_Scripts', 'load_scripts' ) );
remove_action( 'wp_print_scripts', array( 'WC_Frontend_Scripts', 'localize_printed_scripts' ), 5 );
remove_action( 'wp_print_footer_scripts', array( 'WC_Frontend_Scripts', 'localize_printed_scripts' ), 5 );

Controlling Admin WooCommerce Assets

The admin part does not have so much hooks but you probably won’t be needed them as much. You don’t need to control too much of the admin part of WooCommerce regarding styles or scripts. So I’ll have to disappoint you here 😀

One thing that is interesting and useful is to load admin WooCommerce Assets on screens where you would use WooCommerce parts. Example: Using the same wc-product-search class on input to create an AJAX loaded dropdown to select products or variations.

For that, you’ll need to hook into the filter woocommerce_screen_ids. If your screen is returned by that filter, you will have WooCommerce admin styles and scripts all loaded. For example, if you have a post type box, you would need to return box and edit-box.

add_filter( 'woocommerce_screen_ids', 'add_my_own_screens' );

function add_my_own_screens( $screens ) {
 $screens[] = 'box';
 $screens[] = 'edit-box';
 return $screens;
}

And then, by using this filter, you could actually remove any styles or scripts of WooCommerce inside of specific WooCommerce screens, but you probably don’t want to do that 😀

Conclusion

WooCommerce Assets on the Front have enough hooks for you to control how will those be loaded and what will be loaded on the front. This can help to optimize your store to conditionally load them and also load them from a faster domain by changing the url to the assets.

You can control all of those assets by hooking into the WordPress core to have a Better WordPress Performance by Controlling Scripts. If you want to have a better way of managing your own assets, I also have a guide on How to create an Asset Manager for WordPress Plugins.

Become a Sponsor

Posted by Igor Benic

Web Developer who mainly uses WordPress for projects. Working on various project through Codeable & Toptal. Author of several ebooks at https://leanpub.com/u/igorbenic.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.