Debugging AJAX

[Steve]

Hi,

I’ve got something that’s not working right when the events list gets filtered via AJAX, but when you do a full page refresh (with the query parameters that the filtering added), it works fine. So the issue is with AJAX.

How can I debug this easily? I’ve got debug mode on, but all I see in the console is the ‘List View Ajax Timer’ output and a few minor PHP warnings. I assume there’s something I can use to trigger console output when the request is via AJAX?

[Brook]

Howdy Mike,

For issues like that it is usually a plugin interfering with the PHP side. JS will usually show no errors. In this case I don’t think JS debugging will help you, which is probably why you’re not seeing much in the console.

Are you basically getting more events than you bargained for, or less? Could you describe what is missing or showing when you load a page via ajax?

I have seen issues like this before. On occasion it’s a legit bug in our plugin, hence my above questions. I would like to try reproducing it on a local install. But, more often than not it is a 3rd party plugin interfering with all requests to WP’ Ajax API. I’m not sure why it’s so common, but I have seen multiple plugins assume that all requests made to the WP Ajax API are for that specific plugin, and so they modify and thus interfere with every other plugin on the site that uses the API. The last time this happened we identified which plugin it was through a conflict test. (This guide walks you through how to test for a conflict, and then identify what is conflicting.) Then the user reached out to the plugin author with what they found, and the author almost immediately released a new version of the plugin that made them compatible with the rest of WP, our plugin included.

Please let me know about those questions, or if you need any clarification or elaboration on what I was talking about. Cheers!

– Brook

[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]

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?

[Brook]

I follow you now. Thanks for clarifying.

For reasons that are lost to history tribe_events_pre_get_posts does not apply to Ajax requests. :-/ This is something we are looking into fixing soon, along with some other tweaks to make modifying and targeting the WP Queries easier.

So, that’s probably the issue. You want to actually hook into pre_get_posts with a priority of 51 or greater. The reason for the high priority is because then the WP_Query  object will have some nice tribe variables defined, like the boolean $wp_query->tribe_is_event_query.

But I have once again dodged your question about whether there is any extra debugging info you could get, and whether that can be sent via Ajax to the browser. We do have some extra debugging info that gets enabled when you have defined the WP Constants WP_DEBUG and SCRIPT_DEBUG. But, these are not quite what you are looking for, and will not help you here. Most of our devs are all using a debugger like x-debug and an IDE for debugging info. It’s extremely useful for WP_Queries. We have not yet found a need for any more information than that provides. But, if you see an area where a debugger is not quite cutting it, please let us know. Even suggest it as a feature on UserVoice if you’re keen. We’d love to have that feedback. 🙂

Does that all make sense? Does the extra knowledge of tribe_events_pre_get_posts help you finalize your code?

Thanks for again for elaborating!

– Brook

[Steve]

Hi there,

Thanks for the extra information. However, no joy!

I’ve switched the tribe_events_pre_get_posts hook for pre_get_posts. Here’s the hooked code in question:

add_action( 'pre_get_posts', 'yh_tribe_events_pre_get_posts', 9999 );
function yh_tribe_events_pre_get_posts( $query ) {

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

		//echo 'yh_tribe_events_pre_get_posts() - START: <pre>'; print_r( $query ); echo '</pre>'; exit;
		if ( YH_EVENTS_SHOWING_RECURRENCES ) {
			// Show recurrences
			$query->set( 'tribeHideRecurrence', false );
		} else {
			// Hide recurrences
			$query->set( 'tribeHideRecurrence', true );
		}

		// Include child categories if filtering by category
		if ( ! empty( $query->query_vars['tax_query'][0] ) ) {
			$query->query_vars['tax_query'][0]['include_children'] = true;
		}

		// Never return past events
		if ( $query->get( 'tribe_is_past' ) ) {
			$query->set( 'post__in', array( 0 ) );
		}

		//echo 'yh_tribe_events_pre_get_posts() - END: <pre>'; print_r( $query ); echo '</pre>'; exit;
	}

}

A few notes of explanation:

• PILAU_FRONT_OR_AJAX is set to ( ! is_admin() || ( defined( ‘DOING_AJAX’ ) && DOING_AJAX ) ) – self-explanatory
• YH_EVENTS_SHOWING_RECURRENCES is set to ( ! empty( $_REQUEST[‘tribe-bar-date’] ) ) – we only show recurrences if a specific date has been picked by the user

You can see the commented-out bits where I’ve been returning debug data (and I’ve been adding a console.log() line to the TEC JS to see it via AJAX).

All my tests show that the latter print_r( $query ) shows the tribeHideRecurrence query var to be set correctly for any particular request. Only, when a date is picked, the AJAX request doesn’t include recurrences. Then, when you refresh the page with the query vars that have been added, the non-AJAX request returns the events with recurrences, as expected.

I really thought the pre_get_posts thing you mentioned would solve this, it sounded like the obvious diagnosis if tribe_events_pre_get_posts isn’t hooked for AJAX requests.

The priority on my hook, 9999, is what I had it at before. I wondered if by “51 or greater” you meant between 0-50 (since WP hooks get processed earlier the lower the number). However, it doesn’t seem to matter what the priority is, I’ve tried it all the way down to 0.

Any other ideas? We’re not in a big rush here, but we need to solve this over the next week and it’s eating up more and more of our time.

[Brook]

Howdy again Mike,

I appreciate the detailed elaboration.

The priority on my hook, 9999, is what I had it at before. I wondered if by “51 or greater” you meant between 0-50 (since WP hooks get processed earlier the lower the number). However, it doesn’t seem to matter what the priority is, I’ve tried it all the way down to 0.

I was thinking any priority more than 50, such as 51-99. I personally don’t use priorities higher than that, as odd things have happened to me. In fact for this snippet it was not quite working right for me until I switched to a 99 priority, but that was among a couple of other changes.

This snippet is working for me. Recurring events will only show one time on the first page, and not again on subsequenty pages, unless date is set. You should be able to replace my variables with your constants: http://pastebin.com/kKV0AK0k

Does that new code work for you?

Cheers!

– Brook

[Steve]

Hi there,

No, the priority makes no difference. I’ve never had issues with priorities like 999999, but anyway, setting my hook to 99 doesn’t change anything.

After a while of step-by-step debug dumping, I think I’ve tracked the issue down to the Pro plugin’s Main.php, the function setup_hide_recurrence_in_query() around line 1170. If I comment out these lines my AJAX query is OK:

// if the admin option is set to hide recurrences, or the user option is set
if ( $this->should_hide_recurrence( $query ) ) {
	$query->query_vars['tribeHideRecurrence'] = 1;
}

should_hide_recurrence() brings us to the admin setting. I’ve unchecked that and the AJAX request with a date set is returning recurrences as expected. D’oh!

Well, that seems stupid and simple, but I’m not sure. setup_hide_recurrence_in_query() is hooked to tribe_events_pre_get_posts with default priority (10). So why does my code, hooked at 99 or 9999, not override the default admin setting?

I left the admin setting checked, to hide recurrences, because that’s exactly what we want as default. However, now I’ve set the admin setting to default to show recurrences, our default list view has them hidden. I guess in this case, my override is working – it just wasn’t working the other way round, on AJAX requests.

Our team is now testing things as they are. If everything seems to work, I’ll probably leave it at that. Even though there does seem to be something amiss in terms of the logic, if the outcome is OK, I don’t have the time to dig deeper to solve a mystery that isn’t apparently affecting things aversely. Let me know if this sheds light on what’s amiss for you, and thanks for your help so far.

[Brook]

I am happy you found a solution. If you’re happy with it stick with it for sure. But, if you do wish to not modify Core then you might try the snippet I shared earlier. The priority was just one of the things I changed. For me it was working great. I was testing it with hide the first recurrence setting disabled.

Let us know if you need anything else!

– Brook

[Author]

Posts