Repost: Removing Scripts/Styles on pages they shouldn't be loading

[Allen Presher]

Greetings,

Unfortunately I need to repost a critical problem with the Events Calendar’s improper loading of assets. The original post was here, however it was closed and I cannot reopen it:

Removing Scripts/Styles on pages they shouldn’t be loading

The solution provided in that thread does has no effect.

We really need a solution to this problem. Currently an additional four additional HTTP requests are being injected before content is displayed, interfering with the critical rendering path. Worse yet two of these resources are JavaScript, which are blocking resources and completely stop the page from loading until parsed — one of these being the jQuery library, a hefty 97 kilobytes of JavaScript browsers must contend with before the page can be displayed. It’s also not very nice that the script being erroneously injected by The Events Calendar on every page of every site running the Events Calendar has relocated jQuery from the footer to the header.

I’d like to underscore that not only is this is major problem for future deployments of The Events Calendar, but that all previous deployments on completed client projects have seen their performance greatly hampered. I really ask that you guys consider developers, who would like to buy large quantities of licenses, completing a project 6 months ago or a year ago only to see a plugin update mess with the loading of their scripts and performance of their projects.

[George]

Hey @Stratejusinc,

At this time, the only way to un-load scripts from our plugins is to search the plugin folders for any instance of wp_enqueue_script(). Then you can use wp_dequeue_script() in your theme or a custom plugin to disable these scripts, and then selectively load them where needed/wanted.

As for our plugins loading jQuery in the header, I do not find this to be the case on my own sites. Perhaps another plugin or your theme is making this happen?

If possible, please post the “System information” of one of these afflicted sites you mention—you can learn how to do so here → https://theeventscalendar.com/knowledgebase/sharing-sys-info/

Thank you,
George

[Allen Presher]

Please provide me the code required to dequeue these assets on all pages but those generated by the Events Calendar. While I understand that I can reverse engineer the plugin and figure this out on my own, I don’t think that’s something that I as a customer should have to do.

Regarding the loading of jQuery I am correct that the Events Calendar is effectively overwriting our theme preference of loading jQuery in the footer (an industry best practice for performance) and placing it in the head. As much as I hate reverse engineering a plugin we pay for when I’ve specific information that could used to solve the problem, the offending line is:

Line 39:
/plugins/events-calendar-pro/src/Tribe/This_Week.php

And that line is as follows:

wp_enqueue_script( 'tribe-this-week', tribe_events_pro_resource_url( 'widget-this-week.min.js' ), array( 'jquery' ), apply_filters( 'tribe_events_pro_js_version', Tribe__Events__Pro__Main::VERSION ) );

You can see that script is being enqued to the head, and requires jQuery, thus forcing jQuery to be loaded first into the head. This is a terrible thing to do to your customers sites by default and without consent.

Please consider developers who buy many licenses, deploy the Events Calendar on multiple sites in development, realize that the plugin has the default behavior of loading assets on every page, then come here and ask you guys for a solution. We then use the solution you guys provide, the sites go live, and then 6 months later we find out that an update injected a bunch of assets on every page of each site, and even changed the loading location of jQuery to the head which totally blocks page rendering.

This could all be easily solved by building an option into the plugin that developers could check off that simply says “load Events Calendar assets only on pages generated by the Events Calendar”. That option could work from tomorrow, till a decade from now, and if you’re concerned that restricting the loading of assets to only Events Calendar pages could cause some theme integration problems that’s why the option would be off by default, with a warning message that it’s for developers only. Bury the option somewhere. Even just make it a PHP flag for us.

[George]

Hi @stratejusinc,

I am sorry to see that this script is loading in the header. It’s unique in that way—all other scripts of ours load in the footer. I am not sure why this is happening, but will make a development ticket so that this can be patched in a future release.

In the meantime, a temporary fix would be to just make that line of code that says wp_enqueue_script() look like this instead of what it currently looks like:


wp_enqueue_script( 'tribe-this-week', tribe_events_pro_resource_url( 'widget-this-week.min.js' ), array( 'jquery' ), apply_filters( 'tribe_events_pro_js_version', Tribe__Events__Pro__Main::VERSION ), true );


---

We do indeed limit asset loading to events pages. As an actively-updated plugin with many moving parts and a development team of many folks contributing code, things slip through and there are occasionally assets loading in places where they’re not needed.

We are constantly working on this and agree that an option or flag to have a bit more control over asset loading is a great feature to have. It is not “easy” or simple though, unfortunately, and so I cannot specify an ETA for the arrival of any such feature unfortunately.

In the meantime, I cannot provide you the extensive custom coding you demand. We are a support team for a general product of which you are one of many customers; not a consultant you have singularly hired to build something specific to your spec and project needs, available for demands for work on your time-table and whim.

⚠️ Please review what license support includes here: https://theeventscalendar.com/knowledgebase/what-support-is-provided-for-license-holders/

I am sorry to disappoint you about the nature of things. To review, however, we agree with you on many points and are actively working on refining the asset loading of our plugins. Here is a recap of the key details from this thread:

• I have shared a temporary fix for the script that is causing jQuery to load in the header.
• I have confirmed that this loading-in-the-header behavior is not correct behavior, and that I will make a bug ticket for us to fix this in our plugins in an upcoming release.
• I have confirmed that we are continuously working on loading assets only where appropriate, and that assets for events should only be loaded on events pages.
• I have confirmed that as future plugin releases are published, this behavior will be improved and refined over time.

Thank you,
George

[Allen Presher]

The temporary fix for the jQuery load isn’t particularly sufficient as it requires the editing of core code (and the editing of core code on every site this has been deployed). If you guys choose to ship a plugin update that does not include the fix, you will have undone my efforts across every site I’ve patched this. Can you commit to not wiping out my work (as has happened in the past with this same issue)?

At not point have I demanded “extensive custom coding”. I’m just looking for you to give me the code required to dequeue them. Here’s what such code might look like:

wp_dequeue_script( 'ASSET-NAME-HERE');

Was that extensive? We’re talking 3-4 one liners, purely declarative. Lines Events Calendar support has provided in the past as a simple search on this forum will show. Not sure why you’re refusing to answer this now.

[George]

If you modify core code of a plugin or theme, every time you update it it any changes to core code will be overwritten. There is not anything we can do to alter this truth, but the code fix I shared is a temporary way to fix a problem you described as very negative.

If you don’t want that fix, then the best option is to wait for an official plugin update that does this.

---

In regards to dequeueing scripts, I do not know where on your site you want things dequeued, and where you will then selectively be re-enqueueing them (if at all).

But you’re right that simply dequeueing a script is easy, so you should have no problem dequeuing any script or stylehseet you would like.

To find scripts and styles you want to dequeue, simply open the plugin code for The Events Calendar or Events Calendar Pro in your code editor of choice, and use its “Find in Folder” feature to look for all instances of wp_enqueue_script() and wp_enqueue_style().

If you find an instance and it is a script or stylesheet you want to dequeue, then make a simple little one-liner like you described above and you’re good to go! 😀

Cheers and best of luck with your modifications,
George

[Allen Presher]

Three places a quick google search turned up that users have come to this forum, asked for the exact same information, and received it:

Dequeue ECP scripts

Unhooking styles & scripts

Cannot dequeue styles

I did state where I wanted to remove these assets from: all pages other than those generated by the Events Calendar. That should be simple enough as the Events Calendar plugin defines a custom post type through which it operates, therefore any calls could be placed in logic such as:

if ( !is_post_type_archive('tribe_events') && !is_singular('tribe_events') )

Recap: Update hurts clients’ sites, no fix for months, refusal to provide a solution that was provided repeatedly in the past. I give up. Please close the thread.

Apologies to anyone in the community who finds this thread looking for a solution.

[George]

Okay—I will close this thread for now, but please stay tuned to the next plugin releases as we have some fixes planned that will reduce the loading of assets outside event contexts.

Best of luck with your site,
George

[Author]

Posts