[Cully]

Sorry, for some reason I wasn’t notified of replies to this message. Before running the plugin you linked to, I just wanted to find out a few things.

(1) Here’s our list of previous_ecp_versions:

previous_ecp_versions =
Array
(
    [0] => 0
    [1] => 4.2.2
    [2] => 4.2.4
    [3] => 4.2.5
    [4] => 4.2.7
    [5] => 4.3
    [6] => 4.3.0.1
    [7] => 4.3.1.1
    [8] => 4.3.2
    [9] => 4.3.3
    [10] => 4.3.4.2
    [11] => 4.3.5
)
latest_ecp_version = 4.4.0.1

Since 4.2.2 was so far back in our update cycle, why would we be running into problems with it now?

(2) The documentation for the plugin you linked to says that it only cleans up recurring events that were created because of the 4.2.2 bug. We don’t have any extra recurring events, so we don’t need that kind of cleanup. Does the plugin also fix some kind of serialized data storage problem?

(3) Since we’re so many versions beyond 4.2.2, is there a chance that the plugin you linked to will mess up some data/structure that was introduced since that plugin was created?

(4) We only noticed problems when we updated from 4.3.5 to 4.4.0.1. After that update, we could create new events, but we’d get an error when we tried to then make a change and save that same event. This makes me think the problem has to do with current code, and how that data is being saved. If it was a throwback to some problem in 4.2.2, then how would that be affecting newly created events?

(5) I created a temporary ‘hack’ that entirely fixes the problem we were having. I’ve pasted it below. Does that potentially indicate the actual problem we’re having? Do you still think the plugin you linked to is a good solution?

This starts on line 1053 of events-calendar-pro/src/Tribe/Recurrence/Meta.php:

foreach ( array( 'rules', 'exclusions' ) as $rule_type ) {
    foreach ( $recurrence_meta[ $rule_type ] as &$recurrence ) {
        if(is_string($recurrence)) $recurrence = unserialize($recurrence); // I added this line, which fixes the problem
        $rule = Tribe__Events__Pro__Recurrence__Series_Rules_Factory::instance()->build_from( $recurrence, $rule_type );

• This reply was modified 9 years, 3 months ago by Cully.

[Cully]

The month view caching did improve load time by quite a bit. We’ll try reducing the lifetime of recurring events and see if that does anything. Thanks again for your great help!

[Cully]

First, you guys do such a good job at customer support. Every time I’ve asked a question on here I’ve received a prompt, honest, amazing response. Thank you 🙂

1. We have 1,342 events.

2. WordPress 4.4.1, PHP 5.6.10, The Events Calendar PRO version 4.0.6, The Events Calendar: Filter Bar version 4.0.3, The Events Calendar version 4.0.6

3. The site was hosted by Lunar Pages. We just moved to a Dreamhost VPS. We saw a slight improvement, but the bottleneck is definitely the plugins.

The Events Calendar plugins aren’t the only ones giving us trouble. However, they seem to be the biggest contributors.

I’ve look through the code a bit; it does seem like quite the job to improve performance. I hope it goes well for you all!

[Cully]

Yeah, that’s actually a super great response 🙂 Thanks for being so upfront about where you all are at. For some reason I’ve had quite a few customer service experiences in the past few days, and it’s refreshing to hear some honesty.

I ended up fixing the problem using tribe_get_events(), but didn’t have to provide a start/end date for some reason. I basically just sent the same parameters I was sending to get_posts() to tribe_get_events(), without setting “eventDisplay”, and it worked. Not sure why, but I don’t really care at this point 🙂

[Author]

Posts