[Steve]

Just to confirm, I’ve deactivated all other plugins and the issue remains. It’s not a plugin conflict.

I’m not going to switch to the default theme, because my custom theme contains code specifically to manage the hiding and showing of recurring events (via tribe_events_pre_get_posts). I imagine the issue is with that code, and I’m trying to debug it.

I’ve done some blunt dumping of data from PHP to the AJAX handler, to output in the console, and I’ve determined that there’s no issue with my constant, set according to $_REQUEST[‘tribe-bar-date’]. That seems to be working fine.

So, I’m wanting to dig deeper and find the issue. Which brings me back to my original request – is there anything in TEC JavaScript that can help me send debug data to the AJAX handler, for output in the browser console?

[Steve]

Yeah, I guessed the issue is with PHP. As ever, the problem is getting the data from PHP back to the browser, into the console. TEC seems to do this so I was wondering about leveraging whatever system you’ve got in place to do my own debug dumping.

The issue is that we’re switching tribeHideRecurrence on or off depending on whether the list is being filtered by date. This impacts several areas of code so I set a constant in functions.php to indicate whether we’re showing or hiding recurrences (the test is based on the existence of $_REQUEST[‘tribe-bar-date’]).

My first guess is that event though I’m using $_REQUEST to grab both $_GET and $_POST vars, somehow the AJAX call isn’t using the same var syntax. I think it should be easy to find out with a few dumps of data to return with the AJAX results and be logged in the console. Just wondering how to do this?

[Steve]

Hi there,

I’m currently on another dev machine, where the date format settings haven’t been changed, and the recurring events are being created OK. The datepicker format is set to 2015-01-15.

Now, the environment where we’ve changed the datepicker format and recurring events aren’t being created is the staging server. The client has spent quite some time populating the events section in preparation for launch. Do you think we’ll have to delete and re-create events created while the datepicker was in day-first format?

Also, do you know when this bug is going to be fixed? We’re in the UK and obviously it’s best if we can actually use the option that’s provided to change the datepicker format, without breaking the functionality!

Cheers,

Steve

[Steve]

Many thanks for your help so far, but at this stage in the project we’re trying to focus on priorities, and this issue has slipped down the list. I’ll get back to you with more information if we decided to devote more time to this issue.

[Steve]

Thanks for letting me know.

I would be happy enough to just show everything on this page, without pagination, if pagination is difficult. However, I tried and tried and I couldn’t override posts_per_page for the query. I tried something like this:

add_action( 'tribe_events_pre_get_posts', 'yh_tribe_events_pre_get_posts', 9999 );
/**
 * Any customisation of the events query
 */
function yh_tribe_events_pre_get_posts( $query ) {

	// Is this an events query on the front end?
	if ( tribe_is_event_query() && ! is_admin() ) {

		// Never return past events
		if ( tribe_is_showing_all() ) {
			$query->set( 'posts_per_page', -1 );
		}

	}

}

Is there any way to make this work?

I’m assuming we can either get pagination or ‘show all’ working – otherwise, how is this feature supposed to work?

[Steve]

OK, I’ve found that CMB2 options can be populated using a callback. Problem solved, I think!

However, I’d still advise adding a little test for the existence of get_current_screen, if possible – there may be other situations/plugins where a callback isn’t available.

[Steve]

It seems that hooking differently just doesn’t work. I can only use the CMB2 plugin by hooking to cmb2_init as directed.

I’ll have a word with the CMB2 people to see if there’s any workaround, but at the moment it looks like I may have to hack The Events Calendar plugin to test for get_current_screen being defined.

Is there any way this change to make it into the next release do I don’t have to keep re-applying the hack?

[Steve]

Many thanks! For now I’ll try hooking differently as a workaround, but good to know it’s being addressed. I’ll notify you if I come up against serious issues with hooking later.

[Steve]

Hi Geoff,

Thanks, but no progress.

You’re right that that method of populating options is a bit cleaner – using a function to return the custom options. I was trying to create the options right before the call to $cmb->add_field(), whereas I should probably be using a function.

Anyway, that’s just a minor aspect of how to use CMB2. I don’t think the workings of CMB2 are the problem, though. The issue is that the creation of the CMB2 fields need to be hooked to cmb2_init. This fires just after init, and is the recommended way of registering custom fields. But when this happens, and the options need to be populated with events grabbed using tribe_get_events, that function calls Tribe__Events__Query::getEvents(), which does the WP_Query.

The problem is that the Events Calendar query class has a method pre_get_posts(), which is hooked to pre_get_posts. And (line 283) it uses the get_current_screen() function, which isn’t defined.

Just done some quick testing and it seems, from the list of hooks spit out by the Query Monitor plugin, get_current_screen() is defined somewhere between wp_loaded and auth_redirect. That means that tribe_get_events() can’t be used (in admin I’m talking about) before auth_redirect.

That seems strange – are there never instances where tribe_get_events might be needed on init?

I guess the last resort would be to register custom fields after auth_redirect. Maybe admin_init? Then I’d need to do some fudging to hook the code to cmb2_init (just a more convenient way of hooking to init), making sure that only runs on the front, and also hooking to admin_init to cover the issue with get_current_screen().

However, this seems very hacky. It’d be great if you could let me know a cleaner way of using tribe_get_events() in admin.

[Steve]

Ah, maybe I misunderstood how the default works. The default symbol is showing on the frontend view even if nothing’s set in the backend. So the default operates at the front rather than in the admin edit screen?

[Steve]

Apologies, yes, it seems to be working now I’ve stripped a lot of other custom stuff back.

However, regarding custom filters in general, could you confirm something? If I have this in my custom filter class:

protected function setup_query_args() {
	$this->queryArgs = array(
		'meta_query' => [query args]
	);
}

Is that overriding all other meta queries being applied, or is it adding to the meta query? I’m assuming the latter, since otherwise multiple filters wouldn’t work together?

[Steve]

Brilliant, thanks! Not sure what I got wrong first time but that snippet works.

[Author]

Posts