Skip Navigation

[Résolu] 48 Render blocking scripts.

This support ticket is created Il y a 5 années et 6 mois. 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.

Aucun de nos assistants n'est disponible aujourd'hui sur le forum Jeu d'outils. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.

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+00:00)

Marqué : 

Ce sujet contient 56 réponses, a 3 voix.

Dernière mise à jour par Akhil Il y a 5 années et 4 mois.

Assisté par: Nigel.

Auteur
Publications
#1271607

Nigel
Supporter

Les langues: Anglais (English ) Espagnol (Español )

Fuseau horaire: Europe/London (GMT+00:00)

Actually, I just tested this and I could dequeue the maps CSS file easily enough, but toolset-common is proving trickier.

The file with handle onthegosystems-icons is not a dependency of anything else, and yet refuses to be dequeued. And because toolset-common is a dependency of it, that cannot be dequeued.

I can't see why, I'll ask a colleague to take a deeper look.

#1271627

Nigel
Supporter

Les langues: Anglais (English ) Espagnol (Español )

Fuseau horaire: Europe/London (GMT+00:00)

It seems like the same file may be added with two different handles.

Here's how to do a clean sweep of the OnTheGo admin styles, together with dequeueing toolset-common and toolset-maps-fixes:

function toolset_styles(){

	wp_dequeue_style( "toolset-maps-fixes" );
	wp_dequeue_style( "toolset-common" );
	wp_dequeue_style( "onthegosystems-icons" );
	wp_dequeue_style( "onthego-admin-styles" );
	wp_dequeue_style( "onthego-admin-styles-icons" );
	wp_dequeue_style( "onthego-admin-styles-colors" );
	wp_dequeue_style( "onthego-admin-styles-helper" );
	wp_dequeue_style( "onthego-admin-styles-core" );
	wp_dequeue_style( "onthego-admin-styles-buttons" );
}
add_action( 'wp_print_styles', 'toolset_styles', PHP_INT_MAX );
#1274027

Thank You Nigel. i will follow up on this soon.
i'm about to wrap up this case.

#1274427

Hi Nigel.

good day. i think my biggest nightmare just resurfaced.

Do you suggest, performance wise which is better,,

A . function based on script and style and reconditioned them OR
B. function based on wp-conditions [ex: if ( !is_page( array()] and condition the styles and scripts .

I think I made a big mess after writing all codes. I need to clean them up.

#1274483

Nigel
Supporter

Les langues: Anglais (English ) Espagnol (Español )

Fuseau horaire: Europe/London (GMT+00:00)

I don't understand what you mean by A.

If I were implementing this I would be using WordPress template tags such as is_page(), is_single() etc. to dequeue unwanted assets.

Depending on how extensively you use Toolset on the site it will either make sense to whitelist or blacklist pages, i.e. dequeue them everywhere except on certain pages, or to only dequeue them on specified pages.

Doing it this way, with PHP as code snippets or in your functions.php, is likely to be the most efficient method.

I'm not sure what other method you have been working on.

#1280583

Hi Nigel.

A. example :

function dequeue_styles() {

if ( !is_page( array('slug1', 'slug2' ) ) ) {

    wp_dequeue_style('additional-parent-style');
    wp_deregister_style('additional-parent-style2');
}

if ( is_post_type_archive( '' ) ) {

    wp_dequeue_style('post-type-archive-style');
    wp_deregister_style('post-type-archive-style2');
}

	}
add_action('wp_enqueue_scripts','dequeue_styles', 100);

B. example

iif ( !is_page( array('slug1', 'slug2' ) ) ) {

function dequeue_styles_custom_pages( ) {

    wp_dequeue_style('additional-parent-style');
    wp_deregister_style('additional-parent-style2');
}
add_action('wp_enqueue_scripts','dequeue_styles_custom_pages', 100);
}




if ( is_post_type_archive( '' ) ) {

function dequeue_styles_post_arch() {
    wp_dequeue_style('post-type-archive-style');
    wp_deregister_style('post-type-archive-style2');
}
add_action('wp_enqueue_scripts','dequeue_styles_post_arch', 100);
}

}

i am just confirming performance wise which is better, or both is same , etc ?

Thanks

#1280585

I am not sure if this is within the topic or I should be opening a new thread for this.

I am using Plugin Load fIlter Plugins to solve the same issue, loading scripts, and styles on non-toolset pages,
however I face some strange issue here, it seems I cant custom disable toolset-types plugins independently.

when i set this my template, GP is creating conflict.

Please view the screen here: lien caché , i am guessing something to do with jquery etc.

Btw, manage to reduce wp query from 134 to 111 queries by disabling toolsets plugins on the non- toolset pages, except toolset-types which is giving issue.

I also would like to check is it safe to disable "toolset-access" on non-toolset pages?

Thanks

#1280979

Hi Dee,

Nigel will be away on vacations until next week, and I'll be following up on this ticket.

The way PHP works, the difference in the performance of both approaches (A & B) should be unnoticeable, however, I'll prefer the approach A, because:

1. The code will be cleaner/tidier to manage.
2. You won't be adding multiple functions and actions to call different conditions.

As for the screencast related to the "Plugin Load Filter" Plugin, it is not entirely clear exactly how the template, theme and other plugins are configured to work on the page in question. But other Toolset plugins rely on the Toolset Types plugin, not only for the common resources ( CSS & script files ) but also in some cases for PHP code.

I'm afraid, it is not possible to troubleshoot this without access to that webpage, in the state when Types plugin is disabled, but to start troubleshooting, I would recommend checking the browser's console to see if there are any errors or warnings recorded when Toolset Types is disabled.
( ref: https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/ )

>> I also would like to check is it safe to disable "toolset-access" on non-toolset pages?

- Since the Toolset Access plugin manages critical functions like user roles and their capabilites and then grant or deny access to particular pages/sections accordingly, a general recommendation would be against this.

However, this primarily depends on how and specifically what features of the Toolset Access plugin are being used on the website. For example, suppose that you have registered a new user role through Toolset Access or are controlling customized access capabilities for the default WordPress user roles. Since, both these are global operations and are not limited to a some pages, this can lead to unexpected results or security/access loop holes, even if the plugin is disabled on page(s) where apparently there are no Toolset components being used.

I hope this helps and please let me know if any point is not clear.

For a new question/concern, please open a new ticket.

regards,
Waqar

#1280981

Hi Waqar, great that you're following up .

You may look at the backend now, pls reply with your IP to whitelist temp entry, cheers

#1281019

Hi Dee,

Thanks for writing back.

I use a static dedicated IP: 59.103.76.147 and if you can whitelist it to access the admin area for the next 24 hours, that would be great.
( my shift is already over and will be looking into this tomorrow morning ).

I've set your next reply as private so that you can share the temporary admin access details.

Meanwhile, it would be interesting to test if the same issue with the homepage's template/layout is experienced if the Toolset Types plugin is deactivated directly (and not through the "Plugin Load Filter" Plugin).

If the issue only happens when the "Plugin Load Filter" Plugin is used for its deactivation, it could be due to the order of execution, in which that plugin disables other plugins.

regards,
Waqar

#1281071

Sure, we can follow up in the morning., cheers

#1281405

i didnt get the private reply .

#1281465

Hi Dee,

I have set your next reply as private again so that you can share the admin access details.
( no changes will be made, but it is still recommended to make a complete backup copy of the website first )

Did you get a chance to perform the test from my last message?

>> Meanwhile, it would be interesting to test if the same issue with the homepage's
>> template/layout is experienced if the
>> Toolset Types plugin is deactivated directly (and not through the "Plugin Load Filter" Plugin).

>> If the issue only happens when the "Plugin Load Filter" Plugin is used for its deactivation,
>> it could be due to the order of
>> execution, in which that plugin disables other plugins.

regards,
Waqar

#1281497

Hi Dee,

Thank you for sharing the access details.

The access details work, but whenever I try to visit any page for the backend/admin area, it shows the "Forbidden - You don't have permission to access /wp-admin/ on this server." message.
( screenshot: lien caché )

Since it is a live/production website, I requested admin access, only to check Types plugin's settings to see what can be breaking the layout in its absence, without making any changes.

But it seems it would make troubleshooting more efficient if I can clone it on my own server and perform the tests, without worrying about breaking the actual website.

Would it be possible for you to share the clone/snapshot of the website instead?
( https://toolset.com/faq/provide-supporters-copy-site/ )

Notes:

1. If for some reason, "Duplicator" plugin ( https://wordpress.org/plugins/duplicator/ ) doesn't work on your server, you can use "All-in-One WP Migration" plugin ( https://wordpress.org/plugins/all-in-one-wp-migration/ )

2. Your next reply will be private as well so that you can share clone/snapshot securely.

3. "I am not sure how to order the plugin to load, are you referring to this" - I was referring to the natural order of execution of these involved plugins and this point can be ignored at the moment.

regards,
Waqar

#1281503

Hi, i forgot to whitelist the IP , pls try again . thanks.