Skip Navigation

[Resolved] Loading extra stylesheets on the front-end

This support ticket is created 4 years, 4 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 24 replies, has 4 voices.

Last updated by Christian Cox 3 years, 8 months ago.

Assisted by: Christian Cox.

Author
Posts
#1767327

Sorry for the delay, I have spoken with Nigel and he has updated the erratum post with the following workaround:

add_action( 'wp_print_styles', 'ts_dequeue_styles', 1 );
function ts_dequeue_styles( $handles ){

  global $wp_styles;
  $wcv_styles = $wp_styles->registered['woocommerce_views-block-style-css'];
  // dequeue & deregister existing style with dependencies 
  wp_dequeue_style( 'woocommerce_views-block-style-css' );
  wp_deregister_style( 'woocommerce_views-block-style-css', $wcv_styles->src );
  // re-enqueue same style minus dependencies
  wp_enqueue_style( 'woocommerce_views-block-style-css', $wcv_styles->src, array(), $wcv_styles->ver );
}

This does seem to resolve the problem in my local site. Please try this updated workaround and let me know if the problem is not resolved.

#1768487

Thank you! That did remove most of the stylesheets, except for the following 3:

<link rel='stylesheet' id='toolset-common-es-css' href='hidden link' type='text/css' media='all' />
<link rel='stylesheet' id='toolset_blocks-style-css-css' href='hidden link' type='text/css' media='all' />
<link rel='stylesheet' id='view_editor_gutenberg_frontend_assets-css' href='hidden link' type='text/css' media='all' />

Are those needed for any reason? We don't even use blocks editor and are still on the classic.

Thanks!

#1768515

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Lenas,

Christian is currently on a Public Holiday today but he will be back tomorrow to continue assisting.

Thank you for the continued patience.

#1769867

Hello, let me ask for some additional feedback from the team. I was initially focused on removing the Google Fonts file you mentioned specifically, and I don't have any information on hand about these other assets. At first glance they do appear to be limited to Blocks elements, but I would like to be able to give you a more definitive answer.

#1771005

Nigel has offered the following script you can use to dequeue the assets you mentioned:

add_action( 'wp_print_styles', 'ts_dequeue_styles', 1 );
function ts_dequeue_styles( $handles ){

    global $wp_styles;

    // woocommerce_views-block-style-css
    $wcv_styles = $wp_styles->registered['woocommerce_views-block-style-css'];
    // dequeue & deregister existing woocommerce_views-block-style-css style with dependencies
    wp_dequeue_style( 'woocommerce_views-block-style-css' );
    wp_deregister_style( 'woocommerce_views-block-style-css', $wcv_styles->src );
    // re-enqueue same style minus dependencies
    wp_enqueue_style( 'woocommerce_views-block-style-css', $wcv_styles->src, array(), $wcv_styles->ver );

    // dequeue toolset_blocks-style-css
    wp_dequeue_style( 'toolset_blocks-style-css' );
    // dequeue view_editor_gutenberg_frontend_assets
    wp_dequeue_style( 'view_editor_gutenberg_frontend_assets' );
    // dequeue toolset-common-es
    wp_dequeue_style( 'toolset-common-es' );

}

I didn't receive any information about whether or not the assets are needed for any reason, so some trial and error may be needed here to determine whether the display of any elements is impacted. To some degree it could also depend on your theme and other plugins, and the styles they include that intersect with the styles applied by these dequeued assets. You may need to add custom CSS to override issues that pop up when these styles are dequeued.

Let me know if you have questions about that, or if the stylesheets are not dequeued as expected.

#1771663

Good, I do sees the ones I mentioned removed. Thanks!
Can you please confirm the the following stylesheets are needed on the front end ( i see these as well, which I didn't realize before, or perhaps they were added after the others were dequeued):

<link rel="stylesheet" id="woocommerce_views-block-style-css-css" href="hidden link" type="text/css" media="all">
<script type="text/javascript" src="hidden link" id="toolset-common-es-masonry-js"></script>
<script type="text/javascript" src="hidden link" id="woocommerce_views_frontend_js-js"></script>

Furthermore, are they needed on pages that don't use Toolset Views/Woocommerce? I am seeing them on every page.

Thanks!

#1772683

Okay sure, I have asked Nigel to take a look. I'm not sure what information we have available but I'll let you know what I find out when I return on Sunday. My day is closing here and I'm off Fridays and Saturdays, FYI.

#1773421

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Let me jump in here to give a bit of background explanation.

With scripts in principle it is reasonably straightforward to only include the required scripts, as script links are typically added to the footer, so the page has been rendered at the point and its content is known.

Stylesheets are more problematic because they are added to the document head, and the page content isn't known at the time as it hasn't been rendered yet, so some stylesheets are added in case they might be needed on a page by some Toolset-based content.

It is precisely because of this that it is difficult to give a general solution to customising which assets are loaded, because it depends on the content (and if it didn't the plugin could optimise what is included automatically).

Over time we've gone through various iterations to improve this, but also things can be overlooked or extra assets may be added as the plugins evolve and features expand.

Right now some of the assets you've identified are earmarked to be removed in the upcoming plugin releases, which barring any last minute problems with testing, should be released by the middle of the coming week.

So rather than aim at a moving target, if it's okay with you, I suggest I pause responding to these individual requests to remove this or that asset until the new plugins are available.

I can then offer a more general solution based on the latest versions, where you can comment in or out those assets that you want to remove. If you only have Toolset content on certain pages you could specify whitelists of pages where the Toolset assets are untouched, and where otherwise they are removed so they don't affect non-Toolset pages.

#1860447

Hello, I have a quick update for you. We have a fairly major project underway where our developers are optimising the assets that get loaded on the front-end and will bundle and minimise them ourselves, so Toolset will load only a single JS and CSS file. I hope to have more information about this project soon, and will continue to update you here.

#2025087

Quick update to let you know we have implemented major refactoring of Toolset's assets, and the latest versions of Toolset plugins implement more streamlined asset optimization and loading mechanisms. If you have not yet been prompted to update to the latest versions of Toolset plugins, you may need to go to Plugins > Add new > Commercial tab, then scroll to the Toolset installer and click "Check for updates".