[Steve]

All OK I think, cheers.

[Steve]

Well as I said above (https://theeventscalendar.com/support/forums/topic/get-link-for-next-event-in-series/#post-1284002), I’ve got code that seems to work for me with start_date. I just made a comment there that I’m surprised there’s no function to do this (get the next upcoming event). And then I was thrown by your next comment(s), which suggested I was missing something. But I’m not sure I am?

[Steve]

I assumed from the description in the docs that start_date means ‘get events whose start date is on this date or later’. The docs are pretty clear: ‘The above code simply retrieves a list of upcoming events’ (with start_date set to today).

Testing in my test installation this appears to be the case. However, posts_per_page doesn’t seem to work. At least, I have one recurring event with many upcoming instances. If I run that code it only returns one instance. That instance is the one that is ‘start_date or later’, but there’s only one.

However, for my practical purposes, I only need to output the next upcoming instance of one event. So there seems to be an issue there (either in lack of clarity of docs, or in the functionality), but it doesn’t affect me right now.

I’m not clear about your comment: ‘You should be able to query for today’s date and set the comparison not to equal but to smaller than.’ Which parameter controls the comparison? Sounds like a reference to the meta_query parameter. Is it a case of using meta_query explicity to use the comparison operator, instead of using start_date (which I presume is a shortcut for meta_query)?

[Steve]

Am I misunderstanding the start_date parameter? I copied from the example here:

Using tribe_get_events

Which says: ‘The above code simply retrieves a list of upcoming events.’

[Steve]

Thanks. That snippet only works if the next upcoming event happens to be the 2nd in the whole series. However, it seems to work with the addition of a start_date parameter to the query:

$next_event = tribe_get_events( array(
	'posts_per_page'	=> 1,
	'post_parent'		=> $parent_id,
	'start_date'		=> date( 'Y-m-d H:i:s' )
));

So basically it’s necessary to ‘manually’ query for the next upcoming event in a series. Frankly I’m astonished that such (presumably) frequently-used functionality doesn’t have a function, or at least a parameter to manage it in tribe_get_event_link().

[Steve]

To be clear, my mentioning of ‘editing’ the events was merely to highlight what each post ID I’m mentioning refers to, how that particular post is seen by the plugin. I’m not really concerned with editing them here. I’m just surprised there’s not a function to get the link to the next upcoming event in a series.

I’ve gone over to a vanilla install of the latest WP, with only EC and EC Pro plugins activated. I’m running custom code using a child of the 2015 theme. Hopefully this can rule out clashes with other custom code.

I’ve created the same event series – starting on 2017-05-03, running every Weds until the end of June. The ID of the ‘parent event’ (with post_parent = 0) is 108.

Here’s the test code:

$parent_event_id = 108;
$event_all_link = tribe_all_occurences_link( $parent_event_id );
echo $event_all_link . '<br>';
$upcoming_event_id = tribe_get_upcoming_recurring_event_id_from_url( $event_all_link );
echo $upcoming_event_id . '<br>';

I’m getting this:

http://wps.dev/event/test-recurring-event/all/

So currently no ID is being returned by tribe_get_upcoming_recurring_event_id_from_url().

[Steve]

Thanks but it doesn’t really help. Here’s what’s happening:

• tribe_all_occurrences_link() returns the /all/ link for the event
• Passing that to tribe_get_upcoming_recurring_event_id_from_url() returns an ID 6829
• Passing that to tribe_get_event_link() returns the URL for the event on 2017-05-10 – two days ago, ‘event past’
• If I edit the post 6829, a notice says ‘You are currently editing all events in a recurring series.’ However, the permalink given is for 2017-05-10.
• If I look in the database at 6829, it has a parent 6822 (which has parent 0)
• If I edit 6822, it also says I’m editing all in the series, but the permalink is 2017-05-03 (the first in the series)

What I need is the NEXT event in the series, based on today going forward. Seems pretty basic? Not sure why there’s a need for such convolution (which doesn’t even work).

[Steve]

I think things are OK as they stand now, it’s just one of those issues that ideally would be properly diagnosed, but practically we’ve had to restore from back up, and keep an eye out.

[Steve]

Thanks, yes, it seems that the ‘parent’ events had been deleted (completely, emptied out of trash), but recurrences remained. Not sure how this could have happened? We bit the bullet and restored a backup, losing a bit of new work but restoring the events. If you’ve ever heard of this happening, let me know. I thought an editor may have done it but surely if it was trashed through the WP interface the recurrences would have been trashed too?

[Steve]

The client is sure that the ones not listed in the back, listed on the front but giving 404s, should be listed in the back and not giving 404s. But there’s no way to edit them to check their details. I’m trying to look manually through the database.

[Steve]

Thanks, didn’t realise I hadn’t closed this thread! The SQL worked a treat – all’s well that ends well.

[Steve]

Thanks for getting back. Appreciate the extra effort, I guess I’m falling foul of time zones? What time zone are you in? Also, do you provide a premium service at all? I’ve had a few problems with this plugin that have necessitated back-and-forth, and it’s just not realistic for my client to have this level of backup when it’s a plugin-specific issue affecting the site.

Anyway:

1. The excess posts mean that I can’t actually back up the database via phpMyAdmin. I’m going to have to wait until the server admins are there in the morning so they can do a backup. The SQL looks good but obviously I can’t run any SQL straight onto a live DB without backing up first!
2. I tried the SELECT with the event that has 14,071 recurrences, and there were 408,037 results. Is that because of the meta and taxonomy joins (which are presumably to clean those bits up with the posts)? Assume so, just thought I’d check.

[Steve]

This reply is private.

[Steve]

How would I identify specific events that might be causing an issue, out of over 100? Maybe there’s a way to query the data to list the number of recurring instances that have been created for each event? If that’s a problem you’ve faced before and you have an SQL snippet, that’d be great.

[Steve]

I already have my own filter for hiding recurring instances. There’s 162 ‘parent’ events, most are recurring. Is there really no way to automate this?

At least, if I sit down and do this, I need to know it’s going to work.

Should I reduce the ‘create in advance period’ before doing this? 12 months had been working OK so far.

I tried it with a few events and the total doesn’t seem to be going down.

[Author]

Posts