[Fifty]

For future reference, I may have found the cause of this unexpected behaviour. Currently we’re testing and watching close if we have solved the issue.

I found that there were single day events in our calendar which had an ’empty’ recurrence object (see image with red border). Even though it was a single day event, the result of this was that this event was shown on all days of the related month in the month view. Example: if it was an event at Jan 10th, it was shown in the day view of Jan 10th only (and correctly) but also on all days of the month view of January (incorrectly).

How it could have happened to get an ’empty’ recurrence/serie probably was caused by the way the event was added: It appears that it is possible to create a ‘serie’ for just once at the same time of the primary event. That is what accidentally happened, because the editor of the events in our calendar thought it was required to fill in all fields. So understandable that he added “too much data”.

Would be best if you can only create a series if the recurrence pattern is more that once at a different time then the primary event.

Maybe this helps!

[Fifty]

Hi András,

Turning off the cache had no effect. Also saw your conflicts checklist, but switching a crowdy live site to another theme and disabling plugins is not an option.

I added the Query Monitor plugin to see what goes on in the background. For example, I tested on Jan 22nd. Our monthview (and admin) say that there are 15 events, but the single date view for Jan 22nd shows only 6 events. And when I copied – what seemed – the main query from TEC to PHPmyAdmin, it also gave 6 events.

I’m now checking with my collegues if 6 should be the correct answer, or 15.

Will get back if I have more debugging info.

BTW, the query I tested was:

SELECT DISTINCT wp_posts.*, MIN(wp_postmeta.meta_value) as EventStartDate, MIN(tribe_event_end_date.meta_value) as EventEndDate
FROM wp_posts 
INNER JOIN wp_postmeta
ON ( wp_posts.ID = wp_postmeta.post_id )
LEFT JOIN wp_postmeta as tribe_event_end_date
ON ( wp_posts.ID = tribe_event_end_date.post_id
AND tribe_event_end_date.meta_key = '_EventEndDate' ) 
WHERE 1=1 
AND ( wp_postmeta.meta_key = '_EventStartDate' )
AND wp_posts.post_type = 'tribe_events'
AND (wp_posts.post_status = 'publish'
OR wp_posts.post_status = 'tribe-ea-success'
OR wp_posts.post_status = 'tribe-ea-failed'
OR wp_posts.post_status = 'tribe-ea-schedule'
OR wp_posts.post_status = 'tribe-ea-pending'
OR wp_posts.post_status = 'tribe-ea-draft'
OR wp_posts.post_status = 'private')
AND ((wp_postmeta.meta_value >= '2017-01-22 00:00:01'
AND wp_postmeta.meta_value <= '2017-01-22 23:59:59')
OR (tribe_event_end_date.meta_value >= '2017-01-22 00:00:01'
AND wp_postmeta.meta_value <= '2017-01-22 23:59:59' )
OR (wp_postmeta.meta_value < '2017-01-22 00:00:01'
AND tribe_event_end_date.meta_value >= '2017-01-22 23:59:59' ))
GROUP BY wp_posts.ID
ORDER BY EventStartDate ASC, wp_posts.post_date ASC

[Fifty]

Hi Andras,

What guide? I assume link is missing … 😉

Upgraded WP to lastest plus almost all plugins (including yours: now 4.4.0.1 and Pro at 4.4), but still same issue.

[Fifty]

Got it fixed now.

Deleted close to 80.000 records from the wp_posts in phpmyadmin. Next tried to remove orphaned records in postmeta with WP Sweep, but that didn’t do anything. Maybe because 1.6 million records was a bit too much to handle for it. ? So removed them thru phpmyadmin too with this query. Took 37 seconds but worked 🙂 (see screenshot)

Phew – case closed! ?

[Fifty]

Was just about to fix the thing with the DELETE-query, but looking at phpmyadmin another question came up: What about wp_postmeta? Isn’t that table ‘contaminated’ too?

Also, do I have to run the patch too, after the Delete-query?
Please advice on the best approach for the quickest & best fix, knowing that we have close to 80.000 duplicates in our database.

I can’t do just alone the patch, since – according to your info – it will take too long to clean the duplicates, since it will run only every 30 minutes and I have no clue how much records it will clean every run.

Or can you give me the raw MySQL query from the patch, so that I do the full cleaning of the database myself? (Yes I do backups and yes I know my way around mysql/phpmyadmin).

Please be as complete as possible with the info/advice, thanks in advance.

[Fifty]

Hi Hunter, that query is definately helpful! EventID 15562 is the runaway event. See attached image!

Next I’ve ran the query SELECT * FROM wp_posts WHERE "post_parent" = 15562; and I can see that it’s all the same event, same title, same post date and all.

What happens if I simply run DELETE * FROM wp_posts WHERE "post_parent" = 15562; with the plugin still inactive? Or is the patch the only way to go to clean it up permanently?

We’re running TEC 4.2.4.

Thanks again.

• This reply was modified 9 years, 8 months ago by Fifty.

[Fifty]

Still no feedback from the developers?

[Fifty]

Hi Hunter, a test environment is always an option, but it’ll be very time consuming to set it up. The plugin has already asked for a lot of my & my teams time, so if you can get a technical confirm that it should work, that would be best.

Ofcourse I’ll always have my backups in place, should something go wrong. But setting up a test environment only for this is not my fav route.

Thanks and a good weekend to you too 😉

(Though I hope that you can get a confirmation before the weekend starts, cuz the sooner I can start, the better)

[Fifty]

Hi Hunter,

Thanks for your additional info.

Regarding the hotfix-plugin:
1 – Can I keep both plugins TEC / TEC Pro inactive while running the cleanup? I dearly hope so, since it would freeze up our admin again. And put extreme load on our site that would hurt visitors.
2 – Does it also work for TEC / TEC PRO 4.2.3? (Since it says: “Please update to the latest version while making sure that your version of The Events Calendar is at version 4.2.2.”)

Thanks!

[Fifty]

Hi Hunter, thanks for replying. I need to more explicit though because the problem is of a larger scale. I’ve attached the load of our db usage, where you can clearly see that we experienced a growing spike, from an average of roughly 15 to 1500. The graph with database load speaks for itself. After disabling the Calendar, we’re back at (currently) a load of 9.5 so far today, see image. (PS: BPU is the providers own measuring tool, you can neglect that. It’s the graph itself I want to share.)

I came across the post https://theeventscalendar.com/support/forums/topic/site-slow-and-down-due-to-calendar-pro-wp_postmeta-table/ and this looks very similar to our situation. We also used recurring events. We’ve added approx 20 events in the last 3 weeks, with some of them reccurring weekly, but we’ve never created 80.000 events in total (see my first post).

Should we install and run the hotfix mentioned here? How much records will it clean per 30 minutes? And also, please check the last question in my previous post, at the bottom.

Thanks.

• This reply was modified 9 years, 8 months ago by Fifty.

[Author]

Posts