[Kevin]

I attempted this fix and is does not work. Category archives appear in the correct order. The main query of a category archive looks like this:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts 
LEFT JOIN wp_term_relationships
ON (wp_posts.ID = wp_term_relationships.object_id)
WHERE 1=1 
AND ( wp_term_relationships.term_taxonomy_id IN (7486) )
AND wp_posts.post_type = 'post'
AND (wp_posts.post_status = 'publish'
OR wp_posts.post_status = 'acf-disabled'
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')
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 0, 30

Tag archives still appear in reverse order, and the sql for the main query looks like this:

SELECT SQL_CALC_FOUND_ROWS * 
FROM ( 
SELECT DISTINCT wp_posts.*, IF (wp_posts.post_type = 'tribe_events', wp_postmeta.meta_value, wp_posts.post_date) AS EventStartDate
FROM wp_posts 
LEFT JOIN wp_term_relationships
ON (wp_posts.ID = wp_term_relationships.object_id)
LEFT JOIN wp_postmeta as wp_postmeta on wp_posts.ID = wp_postmeta.post_id
AND wp_postmeta.meta_key = '_EventStartDate'
WHERE 1=1 
AND ( wp_term_relationships.term_taxonomy_id IN (1086) )
AND wp_posts.post_type IN ('post', 'tribe_events')
AND (wp_posts.post_status = 'publish'
OR wp_posts.post_status = 'acf-disabled'
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')
ORDER BY EventStartDate DESC ) a 
GROUP BY IF( post_parent = 0, ID, post_parent ) 
LIMIT 0, 30

Since category and tags are both simply taxonomy queries, they should be the same. Any pointers here? I need this fix as I need the PHP 7.2 updates in recent updates to Events Calendar as well.

[Kevin]

Did this fix make it in by chance to the latest maintenance release?

[Kevin]

I just updated to the latest maintenance release. It looks like this fix is still not in there? When can I expect it?

[Kevin]

Has this issue been fixed yet?

[Kevin]

We were seeing on tags, not categories or home page archives.

Yes, sort order is correct without Events Calendar. And sort order is correct with previous versions of Events Calendar.

Notice the query changes shown above when your plugin was updated. Namely the removal of the eventstartdate order by statement

[Kevin]

I still don’t think the implementation here is correct for a couple of reasons.

We have a plugin that runs get_post_metadata on regular posts. Watching the call stack in Query Monitor, this fires off the Tribe_Meta_Chunker on the get_post_metadata filter. I see it running filter_get_metadata, get_all_meta_for and get_all_meta, yet these posts are not “chunked” as this function describes. (i.e. There are no long meta values)

I assume this function was added to support long metadata generated by TEC. If so, why is it being applied to posts and not tribe_event post types only?

This function is running on posts regardless of whether there is chunked data or not, so it is not “bailing” as far as I can tell. On our system, it is making it all the way through to the custom DB query on get_all_meta.

Since you are circumventing the normal DB query for get_post_metadata completely, it appears that this is also bypassing all of the object cache logic present in WP core for the normal get_post_metadata function. This is why I noticed it because it is hitting on every pageload where previously this was easily cached.

I am the dev on a very high traffic site where query performance and caching is critical. On a recently viewed post, our page generation can often be accomplished 100% from the object cache without even hitting MySQL. Even if your function is relatively quick, you introduced a needless query where we don’t need it with no object caching.

I assume there is some reason that TEC needs extra long metadata strings, which is why this was introduced. If that is the case, it should apply only where it is absolutely needed and bail to the normal WP functions otherwise. Why wouldn’t TEC store chunked data on tribe_event and not posts?

And I’m not totally comfortable with the way this completely rewrites a WP core function. It is one thing to filter or alter the value in a WP core function. It seems something else to completely replace the DB queries and post cache like was done here that applies to all regular posts.

What consequence will there be if I turn off the chunker via the post type filter available in the plugin?

[Kevin]

I’ve deployed the latest version. Indeed, the improperly written query seems to be gone, but I’ve uncovered a new issue.

Can someone explain to me why this function is hooked to to normal posts? I’m seeing it firing on regular posts that are using get_post_meta, not just the tribe_events CPT. This should only fire on posts that need it.

I’m also not sure this is object cache friendly. Most posts are not going to have the “chunked post meta” set, but this function has to run its query to figure that out. You have added a new query to every page load for us that didn’t normally have to run before because the calls to get_post_meta were cached.

It appears that this is story post-specific settings in the options table as well? Any explanation here? The proper way to store a post-specific value is to store it in postmeta, not options

I’m going to reiterate what I said before about the changelog. Why is this not listed anywhere in the change log?

[Kevin]

Here is the thread in the Advanced Post Cache repo

https://github.com/Automattic/advanced-post-cache/issues/11

[Kevin]

This has nothing to do with where reCAPTCHA appears. I know that it doesn’t appear for logged in users and is for anonymous submissions. The bug I’m seeing is related to settings and the persistence, or lack thereof, of those settings. Settings can be stored differently on multisite, so you may need multisite to see this.

Steps to recreate
1) Events > Settings > Community > Checck allow anonymous submissions > save changes
2) Events > Settings > APIs > enter reCAPTCH site and secret key > save changes
3) Return to Events > Settings > Community. Notice that “allow anonymous submissions” is unchecked.

The act of saving reCAPTCHA keys removes the anonymous submission setting. The act of saving anonymous submission removes the reCAPTCHA keys.

[Kevin]

I have found the cause of this. Events Calendar Pro does some SQL manipulation in the posts_requests filter.

Advanced Post Cache is a query caching plugin from Automattic that creates hashes of SQL queries and caches them on this same filter hook.

https://github.com/Automattic/advanced-post-cache

Because Advanced Post Cache is loaded first as an MU plugin, and it has the same priority as Events Calendar posts_where filter, the Advanced Post Cache is firing too early, since Events Calendar posts_where is making SQL changes after it.

Not sure who is the best to fix here. Either load your filter earlier or have Advanced Post Cache load later.

Have you come across this on WP VIP? Or is the plugin VIP certified?

[Kevin]

I ended up downgrading, but we have the same setup as Adam. We run HTTP on the front-end, and HTTPS for login and wp-admin pages. That seems to be the setup where this bug is appearing.

We actually have two certs. One is a Cloudflare cert that you’ll see and an end-user on our site. There is a second cert that encrypts traffic between the Cloudflare proxy and our nginx load balancer.

[Kevin]

We are getting the exact same thing. Tons of these entries in our error log:

[Thu Jun 09 22:03:46.418184 2016] [:error] [pid 28950] [client 185.53.44.67:60122] PHP Warning: key() expects parameter 1 to be array, null given in /nas/content/live/mysite/wp-content/plugins/the-events-calendar/src/Tribe/JSON_LD/Venue.php on line 46
[Thu Jun 09 22:03:46.418469 2016] [:error] [pid 28950] [client 185.53.44.67:60122] PHP Warning: reset() expects parameter 1 to be array, null given in /nas/content/live/mysite/wp-content/plugins/the-events-calendar/src/Tribe/JSON_LD/Venue.php on line 49
[Thu Jun 09 22:03:46.418618 2016] [:error] [pid 28950] [client 185.53.44.67:60122] PHP Warning: Creating default object from empty value in /nas/content/live/mysite/wp-content/plugins/the-events-calendar/src/Tribe/JSON_LD/Venue.php on line 51

[Kevin]

This is easy to replicate. I just did so on a clean install using an unmodified version of Twenty Twelve as the theme with no plugins.

Add the following in to functions.php:

function exclude_venue_orgs( $args ) {
    $args['exclude_from_search'] = true;
}
add_filter( 'tribe_events_register_venue_type_args', 'exclude_venue_orgs', 10, 1 );

Now try to edit venues. You cannot, even with administrator privileges. I realize that the default is to exclude from search, but this gets changed by Pro, which is why we are doing this customization.

[Kevin]

This is not a plugin conflict. Our site uses the tribe_events_register_venue_type_args filter to exclude Venues from WordPress search. In our functions.php, we have the following:

function exclude_venue_orgs( $args ) {
    $args['exclude_from_search'] = true;
}
add_filter( 'tribe_events_register_venue_type_args', 'exclude_venue_orgs', 10, 1 );

This used to work just fine. I believe that Pro re-registers venues to allow custom post type search, which we need to prevent. We don’t want venues appearing in WP search results, and we cannot use a pre_get_posts modification, since we use a third-party search solution that relies on the value of exclude_from_search

Somehow, when this filter is active, the registration of venues is not working correctly. I haven’t been able to figure out why. The best way to see this is to print_r the results of get_post_types at various points in the code. You’ll see that initially the post type object looks correct, but is altered later on with a variety of incorrect parameters for Posts, rather than venues.

What is the proper way to use tribe_events_register_venue_type_args and tribe_events_register_organizer_type_args filters with the new 4.0 code?

• This reply was modified 8 years, 4 months ago by Kevin.

[Kevin]

Looks like this is the same issue as mentioned in this thread.

https://theeventscalendar.com/support/forums/topic/posts-displaying-out-of-order-in-dashboard/

[Author]

Posts