next / prev links when showing all recurring events instances loads other events

[Steve]

On the view returned by the ‘all’ endpoint for recurring events, I’ve got the standard tribe_get_listview_prev_link() and tribe_get_listview_next_link() to paginate. However, when you click, the next page the AJAX loads includes other events (not in the recurring series).

If the basic URL is this:

/event/test-event/all/

The ‘next’ page is given this URL:

/event/test-event/all/?tribe_paged=2&tribe_event_display=all

If I hack &tribe_event_display=all off the end, the pagination works fine. However, if I try to remove this query arg from the URL returned by tribe_get_listview_next_link(), the AJAX JS breaks:

tribe-events-ajax-list.js?ver=3.11.2:77 Uncaught TypeError: Cannot read property ‘1’ of null

Is tribe_get_listview_next_link() the right function to use in this context? Is there a way of removing tribe_event_display without breaking the AJAX?

[Geoff]

Hey Mike,

You’re absolutely right: those functions are specifically tied to the List View as a whole rather than a specific recurring series.

The problem (or pain point perhaps) is that the /all/ page of a recurring series is set to show all events in that series regardless of past or upcoming status. It would use it’s own pagination from there.

Unfortunately, I’m afraid this would be a rather tough customization to pull off. However, it does seem to dovetail nicely with this existing feature request, which I highly suggest adding your vote to.

Sorry I don’t have more of a concrete solution for you here, but does this at least help shed some light on things? Please let me know if you have other follow-up questions here and I’d be happy to help as best I can.

Cheers,
Geoff

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

[George]

Hey Mike,

I’m hoping to write some custom code for you here, but am curious about a few specific details before we proceed because I do not run into the problems with the /all/ recurring events page navigation that you report here.

I’m curious:

1. What version of The Events Calendar is currently active on your site?
2. What version of Events Calendar Pro is currently active on your site?
3. What are your site’s permalinks settings (in Settings > Permalinks in your wp-admin)?

Next, can you clarify what you mean when you say this:

I’ve got the standard tribe_get_listview_prev_link() and tribe_get_listview_next_link() to paginate.

4. Does that mean you are using custom events templates in your theme? If so, what specific custom files are you using? Even if you have 5 or 10 custom Events template files, can you copy and paste each of them into separate Gists at http://gist.github.com and link to those Gists? We can look at your exact code that way – it might be helpful.

In Closing
Now, there is no problem at all if you are using custom template files – no worries! Just curious because that could change the texture of your problems here a bit. As I mentioned, the recurrence /all/ pagination works fine for me, so even though it seems like a lot of information that I’ve requested in this post, it’s just to help us boil down exactly what is going on here.

Thanks in advance for as much information as you can provide, and for your patience with us on this issue – we’re eager to get you a bit of working code that will make this /all view useful on your site until actual improvements make their way into the official plugin release, so don’t give up on us here yet! 😉

Thanks,
George

P.S.

The reasons why an instance of filtering pre_get_posts fails could be many – it could be stemming from the priority you’ve set on that hook (tribe_events_pre_get_posts is called at the end of another function in TEC that hooks into the “main” pre_get_posts, so that priority isn’t really necessary here).

I’d recommend holding off on trying to filter pre_get_posts for the moment – we can start with the information above and then work towards a reliable solution from there.

Thank you!

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

[George]

Sounds good Mike, thanks for the update! It’s worth noting that we have a “SupportDroid” bot who auto-closes threads if they remain un-replied-to for 14 days.

He means well, but sometimes SupportDroid closes threads like this one where we want to leave them open to hear back from users like yourself who have to leave an issue temporarily, then come back later to update it…

If you come back to this thread and find it closed by SupportDroid, no worries! Just open a new thread, slap a link to this thread in it for reference and context, and pick up right where we left off here 🙂

Cheers!
George

[Support Droid]

This topic has not been active for quite some time and will now be closed.

If you still need assistance please simply open a new topic (linking to this one if necessary)
and one of the team will be only too happy to help.

[Author]

Posts