Events Calendar is making the website slow

[Vikram Saini]

Hello,

We’ve been running Events Calendar and Events Calendar Pro for a long time and I’ve just noticed that the plugin is starting to slow down the website.

I ran a debug tool and it seems that the Events Calendar plugin is making various calls to functions even when no calendar is displayed on the page.

Any help regarding this will be useful.

Kind Regards,

Vikram

[Jaime Marchwinski]

Hi Vikram,

Thanks so much for reaching out!

I’m sorry to hear that your site is running slowly with use of our plugins.

As a first step, please have a look at our Performance Considerations and see if there is anything you can adjust in order to help your site run better:

https://theeventscalendar.com/knowledgebase/performance-considerations/

After that, you may be interested in caching, so take a look at this article:  https://theeventscalendar.com/knowledgebase/caching-basics/

I would also recommend that you update your plugins to their most recent versions.

Let me know how it goes and if you need any further assistance on this topic!

 

Thanks,

Jaime

[Writers]

I’ve noticed this too and I think I’ve located the problem, but not the solution yet. On every front-facing page I see the following and it takes up 5.6837s:

GET https://ea.theeventscalendar.com/api/aggregator/v1/origin?key=*****
Tribe__Events__Aggregator__API__Requests->get()
/wp-content/plugins/the-events-calendar/src/Tribe/Aggregator/API/Requests.php:41

On the back end, there are two of these api calls. Yet the only time the aggregator is actually needed is on the page /wp-admin/edit.php?post_type=tribe_events&page=aggregator

https://ea.theeventscalendar.com/api/aggregator/v1/origin?key=*****
https://ea.theeventscalendar.com/api/aggregator/v1/origin?key=*****

If we could block this from running except on the required page, our sites would speed up… a lot.

-Amanda

[Writers]

hmm. It’s the admin bar. Starts on line 568 in Aggregator.php – it adds admin bar items for Aggregator, all the good stuff, if you can live without the list of ways to import events, then it’ll speed up a lot for you and any logged in users with priviledges. It shouldn’t affect your site’s visitors.

add_action( 'wp_before_admin_bar_render', array( $this, 'add_admin_bar_items' ), 10 );

Tribe__Events__Aggregator->add_admin_bar_items() /Aggregator.php:531
Tribe__Events__Aggregator__Admin_Bar->init() /Aggregator/Admin_Bar.php:83
Tribe__Events__Aggregator__Service->get_origins() /Aggregator/Service.php:258
Tribe__Events__Aggregator__Service->get() /Aggregator/Service.php:165
Tribe__Events__Aggregator__API__Requests->get() /Aggregator/API/Requests.php:41

The best way I’ve found to kill the aggregator is the kill the api. ie: make the api invalid if we don’t need it.

add_filter( 'tribe_aggregator_api', function($api) {
    // only allow on: /wp-admin/edit.php?post_type=tribe_events&page=aggregator
    if(!is_admin() || !(isset($_GET['page']) && strcmp($_GET['page'], 'aggregator') === 0 &&
         isset($_GET['post_type']) || strcmp($_GET['post_type'], 'tribe_events') === 0))
    {
        return;
    }
        
    return $api;
});

But as I said, this isn’t going to affect your visitors, but it is damn annoying when you don’t know why your site is running so slow while you’re trying to debug. It’s pretty lazy programming to require an API call to get a list of ways to import events.

Hey Modern Tribe, am I right? and can you fix this?

-Amanda

[Writers]

Yeah, yeah, that || should be an && but I couldn’t edit my post. BUT I found a better way…

add_filter( 'tribe_aggregator_should_load',  function($load) {
    // only allow on: /wp-admin/edit.php?post_type=tribe_events&page=aggregator
    if(!is_admin() || !(isset($_GET['page']) && strcmp($_GET['page'], 'aggregator') === 0 &&
                        isset($_GET['post_type']) && strcmp($_GET['post_type'], 'tribe_events') === 0))
    {
        return false;
    }
    
    return $load;
}, 10, 1);

Needs to be called before this:

// let's initialize tec silly-early to avoid fatals with upgrades from 3.x to 4.x
add_action( 'plugins_loaded', array( $this, 'plugins_loaded' ), 0 );

Which means you can’t place it inside an init or plugins loaded action, the “add_filter” call needs to be before everything.

I tried digging down into:
tribe_singleton( 'events-aggregator.main', 'Tribe__Events__Aggregator', array( 'load', 'hook' ) );
But I got lost in the code, so I’m not sure when the aggregator’s load function is actually called, but I do know when the singleton is made…

…and only loading the aggregator when it’s needed does speed up my site.

-Amanda

[Jaime Marchwinski]

Hi Amanda,

Thanks for your input!  It sounds like you may be heading in the right direction, but let me know how it goes and if you have any further questions!

 

Thanks,

Jaime

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts