Certain Category Not Excluding in tribe_get_events()

[Cliff]

This is an odd one, but I’ve tried everything.

We’ve been using a custom query for a while to hide events on the homepage using a category. It’s worked fine until very recently (though I was able to replicate in 3.7 before upgrading).

You can take a look at the code here: https://gist.github.com/logoscreative/0783321f2f15b8a7c859

It seems to work 100% of the time if I use a single word as the term (whether calling by slug or name). I can reproduce some wonky behavior _sometimes_ when using terms with spaces or dashes, but the one particular category in the gist, which is the one we need, doesn’t work at all anymore.

What’s even stranger is, in one staging environment, I was testing different categories to try to find the problem, and it eventually worked exactly as desired—but I’ve found no way to replicate this behavior again. It would seem some combination of changing categories, saving, and running the query multiple times ‘fixed’ whatever bug is in there.

Help? 🙂

[Barry]

Hi Cliff,

I can certainly replicate what you’ve described but I’m not sure it is a problem that’s specific to The Events Calendar.

Let’s forget about events and event categories for the moment and consider the following snippet:

$posts = get_posts( array(
	'posts_per_page' => 10,
	'tax_query' => array(
		array(
			'taxonomy' => 'category',
			'field' => 'name',
			'terms' => array('Test Post Cat'),
			'operator' => 'NOT IN'
		)
	)
) );

Tracing through the code it appears that – despite specifying the field type as name – the term or terms are passed through sanitize_title_for_query() – effectively turning them into slugs.

In short, WordPress is looking for a term named term-post-cat which does not exist. In your example of course it is looking for an event category named hide-from-home – that doesn’t exist either, as the name is actually Hide from Home.

• You noted that sometimes this works and sometimes it doesn’t … could the difference be that some of your categories have single word, lowercase names and so slip through this mechanism?
• Instead of comparing the name, can you switch to comparing by slug instead?
• It may be worth looking on WordPress Trac to see if this is a known bug

Does that help here?

[Cliff]

Unfortunately, the ‘slug’ field has already been tried to no avail. 🙁 I’ve also tried setting ‘field’ to ‘id’ and passing in the integer. No luck.

The name field has worked as expected with other categorized, and all of them are capital case.

Not seeing a bug in Trac, currently.

[Barry]

Interesting – sounds like we’re experiencing different things.

While I do see a problem when using names it’s resolved with slugs: so long as I do use slugs, I can’t replicate what you’ve described.

Am I correct in thinking you are also unable to reliably replicate outside of this one environment? If you duplicate that site into a test environment, deactivate everything except our plugins and switch to a default theme – then test out that code with slugs – can you see the problem there, too?

 

[Cliff]

Yes, definitely. I double checked in a staging environment with all other plugins disabled and 2014 turned on.

Let me know if you need a login.

[Barry]

If you want to share a db dump that would be ideal – that would make it a lot faster for me to inspect things. Is that possible (you can share a download links via a private reply if preferred)?

[Cliff]

Sure. Will do.

[Cliff]

This reply is private.

[Barry]

Awesome, thanks for sharing that 🙂

So I set up your database and added the same snippet you provided initially (that is, testing against the category name) and this failed to exclude the relevant events posts. As described above, though, I don’t believe that is the result of any problems with The Events Calendar itself.

Next of all I tested against the slug. In my first test, l commented out the tax query. These are the post IDs (so you can double check against your own copy of the database) that were returned, plus the assigned event categories:

• 3334 Hide from Home, Sports
• 3447 Sports
• 3448 Sports
• 2156 Hide from Home, Men
• 3449 Sports
• 3450 Sports
• 1311 Hide from Home, Missions
• 3451 Sports
• 3452 Sports
• 3441 Men

And here are the results when the tax query is left in place (but, just to be clear, testing against a slug of hide-from-home):

• 3447 Sports
• 3448 Sports
• 3449 Sports
• 3450 Sports
• 3451 Sports
• 3452 Sports
• 3441 Men
• 3453 Sports
• 3454 Sports
• 3434 Children

So actually it seems to be behaving as expected – all the events assigned to Hide from Home are removed, so long as we test against the slug rather than the event category name.

Obviously that isn’t what you are experiencing and there are a number of possible reasons for that – so probably I’m just missing some context. Can I ask where you are running this code exactly? Also, though it may seem like an obvious point, when you changed the field property to slug did you also “slugify” the term name and convert it to lowercase, replacing spaces with hyphens?

Thanks!

[Cliff]

Interesting. It lives in functions.php of the active theme.

Yep, I slugified the term and, still, no dice. So odd. :\

[Cliff]

The other odd thing is that the same code works properly with that specific category if I comment out ‘eventDisplay’ => ‘upcoming’

[Barry]

OK, so you mean it’s quite literally sitting in your theme’s functions.php pretty much as you presented it and runs as soon as that file is loaded?

If so, that’s a very early stage in the lifetime of the request to be doing work like this. What if you don’t run it until later in the request (such as the init action) – do you hit the same problem then/is there a reason you need to do this before things have initialized?

[Barry]

Hey Cliff,

Just checking in here.

Did the above help at all? Honestly, I’m not sure how much more we can do on our end with this one – but if you have any other feedback or findings from your own further testing we’d love to hear back from you.

Thanks!

[Cliff]

It’s attached to a shortcode, so there’s not a ton I can do to change runtime.

[Barry]

Hmm, so it is almost certainly being called after init in that case.

Does this problem only crop up when the shortcode is deployed in the context of event pages, or anything like that you can spot?

[Author]

Posts