[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

[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]

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

[Author]

Posts