[canadianbrass]

I may not be the only guy with stuff possibly running its own wp_queries. It might be a good idea to alter events calendar to ensure that the original query is being used to start the loop with some code immediately before the loop start similar to this, I dunno. Whatever, I’m probably a weird fringe case.

[canadianbrass]

Sorry, it looks like my code is being scrambled a bit here, let me try again:

global $wp_query;
$wp_query = new WP_Query($wp_query->query);

if ($wp_query->have_posts()) :
$hasPosts = true; $first = true;
while ( $wp_query->have_posts() ) : $wp_query->the_post();

etc.

[canadianbrass]

Okay, I think this is fixed.

I came up with a script to delete the duplicate postmeta data. It is pretty brainless, but I’m going to operate on my theory that some botched import jobs caused this and hope that this doesn’t happen again.

I also found that the problem with the full calendar view was that for some reason the WP_Query was being altered by the time the loop for the monthly display started. I don’t know why this didn’t crop up before, and I don’t know exactly where the conflict is, but I implemented this silly hack before the loop that seems to work:

global $wp_query;
$wp_query = new WP_Query($wp_query->query);
have_posts()) : ?>

have_posts() ) : $wp_query->the_post(); ?>
etc.

[canadianbrass]

Thanks Jonah!

Some additional info…

Just to re-iterate, there are multiple symptoms here. They might be of the same basic problem, but I’ve discovered some stuff that might be revealing…

My primary concern here is the discrepancy between mini and full calendar views, and what might have caused the duplicates in the first place. This is evident on the mini calendar of one of my test sites: http://dev1.canadianbrass.com. As you can see on the dev1 subdomain the full calendar shows two events with no duplicates, and the mini calendar shows all of them with the duplicates.

I’ve provided SQL dumps of all wp_post data of post_type “tribe_events”, and wp_postmeta data where meta_key like ‘_Event%’, you can access them here:

http://netmusician.org/~joe/cbdata

There appears to be a lot of duplicate postmeta rows since there are over 4000 entries here. I’m not sure what caused all of these. I may have struggled with the WordPress Exporter plugin at some point in syncing data with the live site, it has always been finicky for me, but in my experience it is pretty good about not duplicating data, and even if it were to I’d expect it to provide a few extra duplicates, not as many as we are seeing here.

If you feel that the WordPress Exporter plugin was the culprit here, so be it, I can write a script to cleanup the duplicates, but this still doesn’t explain the discrepancy between the mini and full calendar views. Still, I will work on a script to search for and cleanup the duplicate and/or orphaned postmeta data to see if this helps.

Theory:

Could the full calendar view be seeing SQL limits on postmeta requests, expecting one set of corresponding postmeta data per event, and therefore we are not getting all the results because of this duplicate data?

Just to clarify something I wrote above, because I realize this thread is incredibly disorienting, I confirmed that the data is not “tainted”. What I meant by this is that I confirmed with my client that the events that are supposed to be appearing in January really should be, despite being created several months ago. Obviously, if there is duplicate postmeta data this could be considered a form of data taint as well. So, I take back what I said about taint not being the problem. I haven’t combed through the 4000 postmeta rows yet to see if there are indeed exact duplicates, but for now I will assume there are.

It could be that your developer(s) simply need to assess whether my case is super fringy and not provide error checking for this, or else tweak the code a little bit. I would think that at all costs the mini and full calendar views should show the exact same data, even if the underlying data is messed up.

[canadianbrass]

Please do. I’m having this problem with the TwentyTen theme and no plugins enabled other than the latest version of Events Calendar and Events Calendar Pro. I’d love to see what a dev thinks of the queries that are being generated!

[canadianbrass]

deactivating the plugin and using the default theme has unfortunately had no effect on the problem I’ve described above where I’m getting the events appearing over and over again due to the query that is being generated. Your confirming that the query I’m getting above is normal would be most appreciated!

[canadianbrass]

Absolutely! I didn’t mean to suggest any unwillingness on my part, I would also be surprised if this problem was at all widespread. I’ll re-test a vanilla install, and keep on try to figure out how to reproduce this. One thing I can provide that might be useful is a MySQL dump file with my calendar data, would that be useful to you guys? This might be more useful that a screencast if it proves that the problem can be reproduced that way, as this problem doesn’t seem GUI related in nature, although I could be wrong about that.

Would you be able to confirm what a typical MySQL query should look like of calendar data within wp-includes/query.php get_posts()? It would be really helpful to confirm what I should be expecting as far as a normal query. I’ll check this out with a vanilla install too.

I also trust that this plugin is officially supported in multisite installs?

[canadianbrass]

I have, but don’t you think it would be a pretty remotely small probability that some other plugin is mucking around with database entries of post_type “tribe_events”? I haven’t messed around with this since my initial testing since I figured that what I found pointed to the problem being self-contained. I’ll try this again once I have a free moment though.

[canadianbrass]

When I say that this row turns up a ton of times, to be crystal clear, I mean that ID# 4994 appears over and over and over again a ton of times within the same day. The same happens for all the other events in the month. I’m happy to provide a MySQL dump file of this data if that would be helpful. You can see the results of this in the mini calendar view here, although you’ll have to wait for a while and hope you don’t create a timeout due to this heavy query:

http://dev1.canadianbrass.com/

[canadianbrass]

Okay, here is one of the problems…

Tracing the query that is sent by the mini calendar down to WordPress’ get_posts function in wp-includes/query.php, it looks like the final query sent, in my case is as follows:

SELECT wp_2_posts.*, eventStart.meta_value as EventStartDate, IFNULL(DATE_ADD(CAST(eventStart.meta_value AS DATETIME), INTERVAL eventDuration.meta_value SECOND), eventEnd.meta_value) as EventEndDate FROM wp_2_posts LEFT JOIN wp_2_postmeta as eventStart ON( wp_2_posts.ID = eventStart.post_id AND eventStart.meta_key = ‘_EventStartDate’) LEFT JOIN wp_2_postmeta as eventDuration ON( wp_2_posts.ID = eventDuration.post_id AND eventDuration.meta_key = ‘_EventDuration’) LEFT JOIN wp_2_postmeta as eventEnd ON( wp_2_posts.ID = eventEnd.post_id AND eventEnd.meta_key = ‘_EventEndDate’) WHERE 1=1 AND wp_2_posts.post_type = ‘tribe_events’ AND (wp_2_posts.post_status = ‘publish’) AND ((eventStart.meta_value >= ‘2013-01-01 00:00:00’ AND eventStart.meta_value = ‘2013-01-01 00:00:00’ AND eventStart.meta_value <= '2013-01-31 23:59:59' ) OR (eventStart.meta_value = ‘2013-01-31 23:59:59’ )) ORDER BY DATE(eventStart.meta_value) ASC, TIME(eventStart.meta_value) ASC

This query is producing duplicate entries on my test site, such as this row turning up a ton of times:

*************************** 226. row ***************************
ID: 4994
post_author: 1
post_date: 2012-04-25 14:03:47
post_date_gmt: 2012-04-25 18:03:47
post_content: Canadian Brass Concert w/Orchestra in Harrisburg, PA
post_title: Canadian Brass Concert w/Orchestra in Harrisburg, PA
post_excerpt:
post_status: publish
comment_status: closed
ping_status: closed
post_password:
post_name: canadian-brass-concert-worchestra-in-harrisburg-pa-2
to_ping:
pinged:
post_modified: 2012-04-25 14:03:47
post_modified_gmt: 2012-04-25 18:03:47
post_content_filtered:
post_parent: 0
guid: http://dev1.canadianbrass.com/?post_type=tribe_events&p=4994
menu_order: 0
post_type: tribe_events
post_mime_type:
comment_count: 0
EventStartDate: 2013-01-27 20:00:00
EventEndDate: 2013-01-27 22:00:59

Something is definitely generating bogus queries. Does the query I posted above look normal?

[canadianbrass]

Thanks Jonah,

An update here…

Apparently all of the above data is actually fine, the problem isn’t with tainted data, I apologize for not helping my own cause by confusing this (it wasn’t me that entered the data, so this has been a challenge to work through conceptualizing).

The main problem is that the main calendar view doesn’t agree with the main calendar view, and the funkiness that is appearing in both (duplicates, etc.). The problem with the administrative views is also outstanding, but I haven’t spent much time tracing this – I realize the info I’ve provided there is sketchy.

I will continue to trace this on my end so that I can provide more useful info (if not figure out the problem). Thanks very much for your help with this!

[Author]

Posts