[Barry]

Hi clampdesign,

I don’t think there are any easy paths to this one, but it would make a great feature request if you’re game to post one:

http://tribe.uservoice.com/

Thanks!

[Barry]

Hi webdesign309 – sorry for the delay.

Recurring event instances share the same post ID, so explicitly setting it (you’re passing in $post->ID as the first parameter of tribe_get_start_date()) has the effect of telling The Events Calendar to look at the first or ‘base’ event in the sequence.

However, since it looks like you’re correctly setting things up with setup_postdata(), can you pass null as the first parameter? Then The Events Calendar can magically determine which instance you are referring to 🙂

Hope that helps!

[Barry]

You could use a filter to do the same thing – in this case, the tribe_events_event_schedule_details filter – however I’m not sure there is a particular benefit to doing so in this case.

Forgot to add the function: it’s tribe_events_list_the_date_headers()

Not quite sure what you’re asking with regards to the above function, can you clarify and/or break the question out into a separate thread if it’s essentially a different topic from the first one?

Thanks!

[Barry]

Hi Anderson,

Since they are otherwise identical can you confirm if the actual hosting environment is also the same (same PHP version, MySQL server version, web server etc) and in the case of the production site are you able to access the error log and see anything of note in there?

[Barry]

OK great – since you’ve got a workaround in place I’ll go ahead and close this thread. We do have a fix for this on the radar, though, and as soon as that becomes available (in a forthcoming maintenance release) you should be able to set photo view as the default once again, if you want to do so.

Thanks!

[Barry]

No problem at all, I’ll aim to update you later this morning.

[Barry]

Just as a matter of comparing notes against a very similar thread, did you change the site URL (domain name) at any point? Though that shouldn’t present a problem even if you did I’m just interested in establishing any commonality between the two reports. Thanks again!

[Barry]

Thanks readdie,

We’ve got at least one other thread describing a very similar issue, so bear with me and we’ll have a chat this morning to see how we want to proceed with this.

@Stephen: thanks for the heads up. Definitely feel free to monitor this thread, but it’s still quite possible the cause in your case is something different (in which case it would be better to create a new thread of your own).

Thanks both of you for your support and patience 🙂

[Barry]

Thanks accessrose: can you try switching from a name-based timezone (“New York”) to the equivalent offset based setting (“UTC-5”) – though this means you need to manually handle daylight saving time it may produce the result we want here.

[Barry]

Thanks again for your patience: I’m not at all sure what the cause of this is and am going to have a chat with the team about this this morning.

[Barry]

No problem, sorry we can’t do more on this occasion.

[Barry]

Hi Robin,

We have added a useful snippet to the list on the right https://theeventscalendar.com/recurring-events-dialog-fix/ but if that isn’t working for you please just hold tight – a maintenance release ought to arrive shortly.

Thanks for your patience!

[Barry]

Hi Phil:

I am aware that I can select a different template to use as the ‘wrapper’ for TEC, but that won’t help me.

Are you sure that won’t help?

Just to clear up any misunderstanding, the point I’m trying to make is that when something other than the Default Events Template is being used a virtual post (with an ID of -9999) is part of the system used to wrap up and deliver our content.

For instance if you are using the Default Page Template and the context is that of a single event, then if you inspect the global $post object early enough – or indeed use a function like get_the_ID() – it will seem the ID is set to -9999. However, this is not true if the Default Events Template is in use and you would instead see the actual post ID of the single event. In light of which, if it’s possible for you to switch to the Default Events Template perhaps that would be an easy way forward?

If that isn’t possible and/or you are unable to run your code at a later point in the request (when the actual event itself is set up as the current post) you could alternatively inspect the global $wp_query object and its posts property in particular, which in the case of a single event request will contain our virtual wrapper post and also the actual event post.

Does that help at all? I appreciate it’s slightly involved, so if you need further clarification on anything I’ll try my best to help.

[Barry]

I’m afraid I can’t see anything of use with that link:

Flourishdesignstudio has no public pastes.

Perhaps you marked your paste as being private?

It’s just the standard WP code because I have not (don’t know how to) edit it.

OK – but based on your opening post you did try adding the snippet to functions.php at some point, right? That’s what we’re interested in seeing (in case there are any obvious errors that jump out at us).

Thanks!

[Barry]

Hi Heinz!

Please familiarize yourself with our Themer’s Guide (if you haven’t already done so) to learn about template overrides, as that is the safest way to make changes such as these. Basically though, you could override single-event.php and find this piece of code:

echo tribe_events_event_schedule_details();

If all you want to do is remove the @ character then changing the above code to something like this should do the trick:

echo str_replace('@', ' ', tribe_events_event_schedule_details());

Does that help at all?

[Author]

Posts