tribe_is_past_event() uses ID property on non-object $post

Hi,

Just to inform you:

I found errors in the php log pointing to a line in tribe_is_past_event() that used $post->ID, while $post didn’t contain an object.

In tribe_is_past_event() the $post global is used when no argument is passed through (what is the most likely scenario), but there is no check whatsoever for the input to be an instance of WP_Post.

I don’t know if that is a conscious choice, so that errors are reported, but the error occurred on a website of ours, when $post contained the value false instead of a WP_Post object.

When I researched it on my website, I found there where old events that still pointed to a venue that didn’t exist (anymore?) in the post table. And it might also occur when an event has no venue, but I haven’t verified that. Anyway, the cause in our case was a inconsistency in the db that only became visible through this error.

Perhaps you want to check there is a WP_Post instance in global $post before using it and decide what to do in such cases? Also in normal usage I would expect the plugin to safeguard that a invalid state, like having meta that points to non-existing venues, wouldn’t occur. So perhaps that’s an issue too, about how to deal with venue removal.

In our case I found $post to be filled with boolean false after get_post had returned a null value elsewhere in the program, that caused the problem.

I traced it back to tribe_get_venue_id(), that calls Tribe__Events__Main::postIdHelper( $postId ); which calls Tribe__Main::post_id_helper() that calls get_post(); that returns a null value that is translated in a boolean value false when the post doesn’t exist (while the normal state of course is to return an post_id.

When the venue_id doesn’t exists in the posts table it will return boolean false and will pass it through to the rest of the plugin, including the $post global used in tribe_is_past_event()

I corrected the problem in the database itself, but perhaps there is some issue in the plugin too. Just to inform you.

Given the log notice, it took a lot of searching, to find out what caused this problem, since it is not obvious from the error notice. It would have been nice if somewhere earlier the plugin had noticed there were loose threads in the data and at least tries to point in the right direction (of better yet, prevent and handle the problem altogether). The plugin right now doesn’t seem to validate the integrity of (at least this part of) the underlying data. Its probably an edge case, only noticed since I check the logs, but its all in the details.

Hope it helps.

regards,
Hans