Skip Navigation

[Resolved] Deregister styles and scripts

This support ticket is created 5 years, 7 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
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+01:00)

This topic contains 6 replies, has 2 voices.

Last updated by Nigel 5 years, 7 months ago.

Assisted by: Nigel.

Author
Posts
#1102421

Hello, I placed the following code in my functions.php file

//remove wp styles and scripts
function my_deregister_scripts_and_styles() {
global $wp_scripts, $wp_styles;

foreach($wp_scripts->registered as $registered)
if(strpos($registered->src,'/wp-admin/')===FALSE)
wp_deregister_script($registered->handle);

foreach($wp_styles->registered as $registered)
if(strpos($registered->src,'/wp-admin/')===FALSE)
wp_deregister_style($registered->handle);
}
add_action( 'wp_enqueue_scripts', 'my_deregister_scripts_and_styles');

This breaks some functionality of toolset, not much though.

Can you help me find out which assets I can deregister safely from the frontend in order to increase page loading time?

Or can you tell me which wp-admin assets toolset requires on the frontend to work properly?

Thanks,
Nick

#1102459

Nigel
Supporter

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

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

Hi Nicholas

This is not well implemented, and it has been on our to-do list for quite some time to overhaul how script and style dependencies are added, and how they can be managed by clients who want more control over what is added where.

There is a basic issue relating to how the page is constructed by WordPress. A View or a Form, for example, could be added to a footer widget, but by the time we arrive there it is too late to enqueue a stylesheet that should be included in the page head, for example. So the developers took something of a kitchen-sink approach originally, namely to add scripts and stylesheets on pages where they might be needed, which means adding them in places they are not.

And in a handful of cases the dependencies are not entirely logical.

So, some preliminary work has been done on rethinking and re-implementing this, given the increasing emphasis on performance. It is not actively part of the current Views dev cycle—there were a handful of issues considered more urgent—but I will be pushing strongly for us to finally update this in the next Views dev cycle, which should start within a couple of months.

In the meantime there is not much I can tell you. We don't have documented what is added where and needed when. If you intend to manually dequeue unnecessary assets, it's a trial and error process, I would only know by going through the same steps myself, and each site may have different needs.

What I would say is that if you only have Toolset content (e.g. Views and Forms) on certain pages or archives, you could check for which page is being loaded first and effectively have a whitelist, where you don't dequeue Toolset assets, and go ahead and dequeue them on other pages. So the non-Toolset pages will see a clear benefit, whereas the benefit on Toolset pages may be marginal in any case (because some of the assets, if not all, would be required).

You could then revisit this later in the year when we should have tackled this.

#1104856
Screen Shot 2018-09-10 at 11.26.09 PM.png
Screen Shot 2018-09-10 at 11.26.30 PM.png

Thanks, Nigel.

Optimizing this would make a lot of sense. Please find my performance tests down below. My landing page almost loads twice as fast without scripts and styles that are not needed. This is huge.

#1105349

Nigel
Supporter

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

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

Hi Nicholas

This issue was mentioned in the developer meeting this morning, they are working on overhauling this to optimise adding assets only where required and to give more control to users, it is something we take seriously, but given timing of the dev cycles it is likely to be a couple of months or more before the updates are released.

I'm glad you were able to make such a difference controlling this yourself.

#1108801

Thanks Nigel.

Do you know how I can control this toolset maps style from being loaded?
It's an inline style but I just can't find a way to remove it from certain pages only where it's not needed.

Does this style come with an id or is there like a filter to remove it?

<style>
		/* Global fix for images inside the map */
		.gm-style img,
		.toolset-google-map-preview .gm-style img {
			max-width: none;
		}
		/* Global glow effect when updating a field */
		.toolset-google-map {
			transition: all 1s linear;
		}
		.toolset-google-map-container {
			overflow: hidden;
		}
		.toolset-google-map-container .toolset-google-map.toolset-being-updated,
		.toolset-google-map-container .toolset-google-map-lat.toolset-being-updated ,
		.toolset-google-map-container .toolset-google-map-lon.toolset-being-updated {
			box-shadow: 0 0 10px 2px #7ad03a;
			border-color: #7ad03a;
		}
		.toolset-google-map-container .toolset-google-map.toolset-latlon-error,
		.toolset-google-map-container .toolset-google-map-lat.toolset-latlon-error ,
		.toolset-google-map-container .toolset-google-map-lon.toolset-latlon-error {
			box-shadow: 0 0 10px 2px #B94A48;
			border-color: #B94A48;
			color: #B94A48;
		}
		/* Global map preview dimensions */
		.toolset-google-map-preview {
			width: 100%;
			height: 200px;
			float: right;
			background-color: #ccc;
			background-image: url(/wp-content/plugins/toolset-maps/resources/images/powered-by-google-on-toolset.png);
			background-position: 50% 50%;
			background-repeat: no-repeat;
		}
		.toolset-google-map-preview-closest-address {
			width: 100%;
			float: right;
			clear: right;
			background: #f1f1f1;
			margin: 0;
			font-size: 0.9em;
		}
		.toolset-google-map-preview-closest-address-value {
			font-size: 0.9em;
		}
		.toolset-google-map-preview .toolset-google-map-preview-reload {
			display: none;
			overflow: hidden;
			position: absolute; 
			top: 0px; 
			left: 0px; 
			right: 0px; 
			bottom: 0px; 
			text-align: center;
			background-color: #ccc;
			background-image: url(/wp-content/plugins/toolset-maps/resources/images/powered-by-google-on-toolset-reload.png);
			background-position: 50% 40%;
			background-repeat: no-repeat;
			z-index: 1000;
		}
		.toolset-google-map-preview .toolset-google-map-preview-reload a {
			display: block;
			position: absolute;
			top: 0;
			left: 0;
			right: 0;
			bottom: 0;
			cursor: pointer;
			margin-left: -999999px;
		}
		/* Autocomplete inside dialogs z-index fix */
		.pac-container {
			z-index: 100150;
		}

        .toolset-maps-success {
            color: green;
        }
        .toolset-maps-error {
            color: darkred;
        }

		/* Backend styles - Types field */
		.wp-admin .wpt-google_address.wpt-repetitive .wpt-field-item {
			padding: 0 0 0 10px;
			border-left: solid 3px #ccc;
		}
		.wp-admin .toolset-google-map-container {
			overflow: hidden;
		}
		.wp-admin .toolset-google-map-inputs-container {
			width: 52%;
			float: left;
		}
		.wp-admin .toolset-google-map-preview {
			width: 45%;
			height: 200px;
			float: right;
		}
		.wp-admin .toolset-google-map-preview-closest-address {
			width: 45%;
			float: right;
			clear: right;
		}

        /* These can be shown on backend, and also on frotend, in a CRED form */
		.toolset-google-map-toggle-latlon, .toolset-google-map-use-visitor-location {
			cursor: pointer;
			display: inline-block;
			margin: 5px 0 10px;
		}

        /* Backend styles - Types fields table */
		.wp-admin .toolset-google-map-toggling-latlon {
			padding-bottom: 5px
		}
		.wp-admin .toolset-google-map-toggling-latlon p{
			margin: 0 0 5px 0;
		}
		.wp-admin .toolset-google-map-label,
		.wp-admin .toolset-shortcode-gui-dialog-container .toolset-google-map-label {
			display: inline-block;
			width: 120px;
		}
		.wp-admin .toolset-google-map-label-radio {
			display: inline-block !important;
			width: auto;
		}
		.wp-admin .toolset-google-map-lat,
		.wp-admin .toolset-google-map-lon{
			display: inline-block;
			width: -webkit-calc(100% - 80px);
			width: calc(100% - 80px);
			max-width: 300px;
		}
		.wp-admin #wpcf-post-relationship .toolset-google-map-inputs-container,
		.wp-admin #wpcf-post-relationship .toolset-google-map-preview {
			width: 100%;
			min-width: 200px;
			float: none;
		}
		.wp-admin #wpcf-post-relationship .toolset-google-map-preview {
			height: 150px;
		}
		.wp-admin #wpcf-post-relationship .toolset-google-map-preview-closest-address {
			width: 100%;
			float: none;
			clear: both;
		}
		#wpcf-post-relationship table .textfield.toolset-google-map {
			width: 99% !important;
		}
		.wp-admin #wpcf-post-relationship .toolset-google-map-label {
			display: block;
			width: auto;
		}
		.wp-admin #wpcf-post-relationship .toolset-google-map-lat,
		.wp-admin #wpcf-post-relationship .toolset-google-map-lon {
			width: auto;

		}
		</style>
#1109104

I followed this guide to deactivate the toolset maps plugin on pages where I don't need it.
hidden link

What do you think about this?

#1109279

Nigel
Supporter

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

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

Hi Nicholas

I'm struggling to see the same as you.

That CSS comes from a file toolset_maps_fixes.css which is enqueued as with other stylesheets, and only on the admin pages, not on the front end, and as such it can be dequeued like any other asset.

On my test site I haven't found it added as an inline style while visiting any front end pages, with or without map content.

Where are you seeing this CSS?

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.