[BUG] Plugin interferes with the_date / get_the_date / etc.

If you’re working with events then using event-related template tags like tribe_get_start_date() is probably more appropriate – would that work for you?

There are two dates associated with an event post:

1. The start date.
2. The date on with the event post was published.

The problem is that the_date returns #2 when it should return #1.

When I var_dump() the event post object in the loop, I can see that the post_date field itself has been overridden to contain the Event’s start date rather than the post’s published date. Hence why I think this is a bug. The plugin is doing something so that a core function doesn’t output the expected value.

The post_date_gmt field seems unchanged but there’s no easy way to grab that and I’ve read a bunch of things saying that there’s a performance hit to querying that value.

Can you give some more context? Are you seeing this in the main blog loop with the include events in main blog loop setting enabled, for instance?

Certainly if you use the_date() within a custom single-event.php template it returns the publication date, as expected, rather than the event start date – but I’m not sure at this point how or where you are seeing this behaviour.

I’ve tested this with all plugins except TEC and ACF disabled and the problem remains. I can’t test it with Twenty Twelve since it’s a custom page template.

The problem I’m seeing is in a custom loop on a custom page template. Here’s the loop:

$ac_news_args = array(
	'post_type' => array( 'post', 'tribe_events' ),
	'cat' => '-49',
	'posts_per_page' => 6
);
$ac_news_events = new WP_Query( $ac_news_args );

Adding 'orderby' => 'date' to that query does not resolve the issue.

In the accompanying loop, I’ve got this line:

get_the_date( 'j M, Y' )

And that outputs the date of the event rather than the date on which the post was published. If I var_dump($post) in the loop, I see the following:

["post_date"]=> string(19) "2013-12-04 17:30:00"
["post_date_gmt"]=> string(19) "2013-09-07 22:40:53"

Note the difference in dates. The post_date_gmt is the publish date while the post_date is the event date.

On a single event, var_dump($post) object shows both dates correctly:

["post_date"]=> string(19) "2013-09-07 15:40:53"
["post_date_gmt"]=> string(19) "2013-09-07 22:40:53"

While I’m not completely sure, I’ve done some digging and I wonder ifthe problem may be in TribeEventsQuery->posts_orderby and/or TribeEventsQuery->multi_type_posts_fields that seem to be modifying the posts’ post_date fields on certain queries.

To take a step back, the general use case of needing to sort by post publish date is that this site has a stream of Posts and Events that should be shown in the order that they were published. There is a separate page (the one that comes with the plugin) for showing the Events in the order they occur and I use the default Page for Posts for showing all Posts in the order they were published.

OK, thanks for giving the background to what you are doing here.

Yes, this is deliberate and the event start date basically replaces the post_date field where the query is A) for a mixed set of post types (that include the event type) and B) only for actual event posts within the result set.

In your case this is surfacing as a problem only in your own custom view, if I’m understanding correctly – so really I think it would be your responsibility to resolve this (which you could so by selectively removing TribeEventsQuery::multi_type_posts_fields() from the list of post_fields filters).

If you feel strongly that this should not be the case though, definitely describe why – we’re open to making changes where it makes sense and will be of benefit to a wide range of users.

Glad I’m understanding the issue at least now.

You’re right that it’s a custom view, but I still see this as a problem because the filter affects the expected output of a set of common core WordPress functions and classes including:

• the_date() / get_the_date()
• the_time() / get_the_time()
• WP_Query

It strikes me that there are all legitimate use cases for wanting to tell people when an event post was published, particularly in relation to other post types. Like I said, in my case, I want a stream of all posts in the order they’re published so people can see what’s new on the site.

What is the intended use case for that multi_type_posts_fields() filter?

At a bare minimum, writing some documentation about the limitations of post sorting of Events with WP_Query would help a lot.

You’re right that it’s a custom view, but I still see this as a problem because the filter affects the expected output of a set of common core WordPress functions and classes including:

I don’t entirely disagree, but I think on a pragmatic level it makes sense for us to keep this in place. For most of our users this is not an issue – in fact it achieves exactly what a large number of them have been requesting – and, for want of a better expression, “tricking” WordPress into seeing the event date as the post date is something we are doing deliberately, it isn’t unintentional.

In cases like this where that behaviour isn’t desirable we’d need to leave it to you to workaround this, whether by killing the filter function I mentioned or retrieving post dates some other way.

At a bare minimum, writing some documentation about the limitations of post sorting of Events with WP_Query would help a lot.

Definitely. We’re very conscious that there are gaps in our documentation and areas for improvement and that’s something we hope to build up over time.

I’m thinking that the optimal solution is somewhere in between.

I see your point about date ordering, and that is a very important, significant, and common issue. I can live with the filters that need to be undone when using WP_Query. Documentation with an example would resolve that.

But I still think it’s a problem that a core function doesn’t work in those cases. That’s a bug.

Since get_the_date() has a filter, I suspect that it’s possible for the plugin to

1. See when one of these filters is active.
2. Grab the post publish date from somewhere else.
3. Return the correct published on date.

Would it be possible for the multi_type_posts_fields() method to stash the original post_date value in a new field on the $post object (maybe “tribe_post_publish_date”) for easy retrieval?

So I went and tried to remove those filters but didn’t have any luck. I thought the following would work when placed before my WP_Query loop:

// prevent TEC brute-force post_date change
remove_filter( 'posts_orderby', array( 'TribeEventsQuery', 'posts_orderby' ) , 10 );
remove_filter( 'posts_fields', array( 'TribeEventsQuery', 'multi_type_posts_fields' ), 10 );

Can you offer any pointers?

There’s not enough context in that snippet for me to offer too much help – when does it run? Is it possible it is running before our own query filters are set up and so is trying to remove something that has not yet been added?

We can’t help a great deal with this I’m afraid, as support here on the www.ads-software.com forum is limited. but do know that I’ll take your points forward for discussion within the team.

Thanks!

Since you’re recommending that I remove the filters, any help you can give me would be appreciated. I’ve got a page template with a WP_Query loop. Do I need to hook into something to remove the filters? Should they go inside the loop?

Hi mrwweb,

Sorry for the delay – we were unable to complete some of our weekly passes over the festive season due to team vacations etc.

So with regards to your question, we add that filter when the pre_get_posts hook fires – so you would probably look to remove it on the same hook, perhaps at a later priority.

I’m afraid we can’t really provide any further support here – custom development is really beyond the scope of what we deliver here on this forum, but I hope the above helps and we’ll certainly consider your feedback.

Good luck!

Not expecting a reply but also giving up. This doesn’t seem to work:

add_action( 'pre_get_posts', 'my_pre_get_posts', 51 );
function my_pre_get_posts( $query ) {
    // prevent TEC brute-force post_date change
    remove_filter( 'posts_orderby', array( 'TribeEventsQuery', 'posts_orderby' ), 10 );
}