Using tribe_get_events and ignoring those marked 'hide from event listings'

[Brian Hogg]

I’m trying to step through tribe_get_events to manually query events, but ignore those marked ‘hide from event listings’.

Here’s the query I’m using:

$query = tribe_get_events( array( 'posts_per_page' => 10000, 'hide_upcoming' => true, 'post_status' => 'publish', 'start_date' => date( 'Y-m-d H:i', $start_date ), 'end_date' => date( 'Y-m-d H:i', $end_date ) ) );

But it’s still returning events marked hide from upcoming. I could try doing a meta query on the ‘_EventHideFromUpcoming’ key but seems hide_upcoming => true should be doing the trick? Thanks!

• This topic was modified 9 years, 9 months ago by Brian Hogg.
• This topic was modified 9 years, 9 months ago by Brian Hogg.

[Brook]

Howdy Brian,

I would love to help you with this.

You must have been searching through the quagmire that is our Query class if you found ‘hide_upcoming’. It’s strange that it is not hiding those events for you. It is for me. If I use your exact code it is working as expected. What version of the plugins are you on? From time to time we have had bugs where hide_upcoming does not work anywhere. If you’re on a version with that bug…

edit: If you are on the latest version, what happens if you set ‘eventDisplay’ => ‘list’ ?

• Brook

[Brian Hogg]

Thanks Brook! Yes was trolling through the Query class 🙂

It is the latest version, but I think part of the issue might be that the query is being run from an automated integration test. I’m including the file, adding to active_plugins, and calling Tribe__Events__Main::activate(); during the setup. I’m adding the event using tribe_create_event with EventHideFromUpcoming set to boolean true as per the function docblock.

With the hide_upcoming => true set it does correctly hide on the frontend now but just not through the automated test.

I did an output when looping through the events with var_dump( get_post_meta( get_the_ID(), '_EventHideFromUpcoming', true ) ) and when adding using tribe_create_event and this create event statement:

tribe_create_event( array(
			'post_status' => 'publish',
			'post_title' => 'Event to ignore',
			'post_content' => 'Sed egestas libero eu neque sagittis laoreet. Quisque sed tortor ac orci posuere dignissim rutrum sed purus. Curabitur in nisl volutpat, commodo erat vel, ultricies odio. Donec euismod nisi et tortor pretium, a porta tellus sodales. Etiam facilisis, metus vitae ultrices malesuada, lorem turpis ultrices elit, sit amet accumsan ex mi nec mi. Nunc ac elit fermentum ipsum ultricies luctus. Nam non mollis erat. Aliquam egestas sapien sapien, nec suscipit ante lacinia eu. Fusce mollis eu risus a commodo. Nunc pretium id dolor sed volutpat. Suspendisse nec est bibendum, gravida ligula ut, sagittis magna. Nunc quis mauris diam. Aliquam at nulla nec diam pellentesque viverra vel quis purus. Nunc et eros nunc. Suspendisse potenti.',
			'EventStartDate' => date( 'Y-m-d', time() + ( 86400 * 5 ) ),
			'EventEndDate' => date( 'Y-m-d', time() + ( 86400 * 5 ) ),
			'EventAllDay' => true,
			'EventHideFromUpcoming' => true,
			'EventShowMapLink' => true,
			'EventShowMap' => true,
			'EventCost' => '0',
			'Venue' => array( 'VenueID' => $venue_id ),
			'Organizer' => array( 'OrganizerID' => $organizer_id ),
		) );

The value is “1” (probably the string value of the boolean) vs. the “yes” that _EventHideFromUpcoming is supposed to be. But even setting _EventHideFromUpcoming to “yes” manually via update_post_meta doesn’t do the trick.

I’ll keep digging through the quagmire but thoughts welcome 🙂

[Brook]

Oh no, I feel your pain if you’re trying to write an automated test for this. One of our developers if a very active contributor to Codeception, and has been naturally taking the lead in helping us make our code testable.We have made some enormous strides, but with a code base as large as this one there is a long ways to go. And the Query class has not seen that love yet.

Did you have a chance to examine how the hide_upcoming works? If it’s true we add a posts__not_in clause, which is set to all event IDs that have had ‘_EventHideFromUpcoming’ set to ‘yes’. However, the list of event IDs is itself cached, and the cache will only be regenerated on post save. It seems very possible that running update_post_meta after the fact did not trigger the cache to get regenerated. You might be wondering why we don’t just do a meta query, it looks like we were trying to save an extra join from being added to every main query.

It is also possible that not all of our actions our firing. Tribe__Events__Main::activate() is a good start, but it might not be enough. I have encountered this problem my fair share of times. So many of our hooks will rely on other WP actions to first, like wp_admin_init or some other random action that is well suited for a typical page load, but becomes very difficult if you are trying to do something nonstandard.

Just throwing some ideas out there. Hopefully that helps us narrow it down.

Cheers!

– Brook

[Brian Hogg]

Appreciate the ideas! I’m able to get non-‘hide from listing’ events to query and be testable as expected, so certainly a great start.

I did dig in and noticed the cache, but adding this doesn’t do the trick:

	    $cache = new Tribe__Cache();
	    $cache->delete( 'tribe-hide-from-upcoming-events', 'save_post' );

The ::activate() and missing other add_actions/filters could definitely be part of the issue, but adding an event with tribe_create_event() should still save as ‘yes’ vs. ‘1’? I’ll try and dig in and see what’s up, but there must be something else causing that posts__not_in to not fire properly.

[Brook]

You are welcome!

adding an event with tribe_create_event() should still save as ‘yes’ vs. ‘1’?

In your code you have set ‘EventHideFromUpcoming’ to true, but it really should be ‘yes’ to work as expected. I think our inline documentation might need updating here because it refers to this field as a boolean, but it’s not really. It’s stored as text in the database, and if the value does not === ‘yes’ the event will get included in the event query. That might be the issue.

Cheers!

– Brook

[Brian Hogg]

You’re right, passing in ‘yes’ vs. a boolean does save the meta as ‘yes’ (I could have sworn I tried this before and it didn’t work), so updating the inline documentation would be good.

Unfortunately that still doesn’t do the trick during the automated test, I’ll need to dig in a bit further to see what else other than Tribe__Events__Main::activate(); needs to be called in order to get the right hooks/filters in place.

Thanks!
Brian

[Brook]

Well that’s one step closer!

If I were in your shoes I would fire up my trusty debugger, and throw a bunch of breakpoints in the get_events() code and query class. I would them in the function that powers get events since that’s obviously running. I would also put them in the query class, just before the hide_upcoming code executes and just after. Inside the function that builds the posts__not_in list, etc. Then I would run your query and step through each of these. It is likely one of them either is not running, the arg does not get passed right, or possibly something is being overridden. Watching the code and vars in the debugger should help figure out what’s going, what’s firing and what is not.

I think doing it that way will be a lot more efficient searching through the code hoping to find which filter or whatever is not working.

Cheers!

– Brook

 

[Brian Hogg]

Hey Brook,

By “digging” I meant debugging, the casual look didn’t find what was missing 🙂

I found the issue – in addition to Tribe__Events__Main::activate(), I also need to call this in the setup:

Tribe__Events__Main::instance()->init();

which will add hooks/filters like this on the pre_get_posts action:

Tribe__Events__Query::pre_get_posts()

Or by doing this in my setUp() with do_action( ‘init’ ):

		update_option( 'timezone_string', 'America/New_York' );
		date_default_timezone_set( get_option( 'timezone_string' ) );

		require_once( dirname( __FILE__ ) . '/../../the-events-calendar/the-events-calendar.php' );
		Tribe__Events__Main::activate();
		do_action( 'init' );
		update_option( 'active_plugins', array( 'event-calendar-newsletter/event-calendar-newsletter.php', 'the-events-calendar/the-events-calendar.php' ) );

This handles things like adding post__not_in the upcoming IDs to hide and voila, tests pass!

There’s likely a better way to this to have the init action fired and plugins loaded, suggestions welcome 🙂

[Brook]

Excellent! Thank you for getting back, it’s good to know how you worked around this. Personally I like the notion of running do_action(), it more accurately simulates the WP environment. Assuming it does not conflict with your goals in some way I am not aware of, I think you should stick with that.

• Brook

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts