[Barry]

You can download previous versions from the downloads page:

https://theeventscalendar.com/downloads/

Remember that you would need to pair this with the relevant version of The Events Calendar (our free, core plugin):

http://wordpress.org/plugins/the-events-calendar/developers/

[Barry]

Excellent – well I wish you every success with your project and of course if you hit any other stumbling blocks or have further questions please don’t hesitate to create new threads as needed.

We’re also always delighted to receive any feedback about our product and service if you are happy and have time to leave a review over on our wordpress.org page – that would be much appreciated 🙂

(…and I’ll go ahead and close this thread now. Thanks!)

[Barry]

Hi!

I’m not actually seeing the same thing, can you provide a specific-to-an-event example?

We’ve certainly had customers reporting issues with one or more Gameday themes in the past, due to a query loop executing and not being cleaned up after early on in the process of rendering a page. I don’t know if that is also the case here but it’s certainly a possibility – and it would be great if you could point me to a live example of the problem as I’m not actually able to identify it right at this point in time.

Thanks!

[Barry]

I think you’ve pretty much zeroed in on the problem by yourself: the issue is that ‘Date’ is being supplied as the value of the tribe-bar-date URL query (when that piece of text is converted to a date it is ultimately interpreted as something like 1st January 1970).

Of course, this should really be a valid date or should simply be empty. Sometimes though a plugin – or more often a theme – uses something called a polyfiller (typically a piece of JavaScript) attempts to convert our placeholder text into an actual input field value to achieve better cross-browser support. If this happens, though, then it also needs to basically undo its changes before a form submission takes place. In this case, it may be that final act of cleaning up isn’t happening.

To confirm this theory can you try deactivating all other plugins and switching to a default, unmodified theme – then see if the same thing happens? If it does not, try reactivating each plugin / your theme, one-at-a-time. This might help to isolate the conflict, if indeed there is one.

[Barry]

Hi Andy: that seems to be a valid bug and we’ll log it and address it as quickly as we can.

[Barry]

OK, thanks for sharing that. Although I can view the front page, trying to navigate to the main events page simply times out.

I do appreciate you want a functioning plugin and that you reasonably expect it to be simple to set up. What I can say is, for most of our customers that is the experience they have.

When you created this thread you noted that you had tried deactivating all other plugins and reverted to a default, unmodified theme: do you still hit these same problems? Or does it only occur when using Gantry?

[Barry]

Thanks for sharing that, Christopher. In essence then this only would occur with the Redirections plugin you are using?

[Barry]

OK, please do post a request: we’re certainly open to making changes, and UserVoice is also a great way to attract support from other users, too.

Thanks!

[Barry]

Hi Hugues,

For the second bug you mentioned please do try updating to 3.3.1 in the first instance and see if that helps – but if not please create a new thread and someone will happily help if they can 🙂

For the first issue, for single day events you might find this snippet useful (which you could add to your theme’s functions.php file). Other alternatives include A) setting up a filter on the following hook:

tribe_events_event_schedule_details

Or B) replacing any calls to tribe_events_event_schedule_details() within the single-event.php template and elsewhere and replacing them with your own code. That’s a bit more involved of course, but the following resources could be useful if you want to investigate that route:

• Themer’s Guide
• Tutorials
• Technical Docs

[Barry]

Nothing I know of that would prevent this – it’s certainly not an active aim of ours to stop that sort of integration. Theoretically it should be as simple as binding the two together with register_taxonomy_for_object_type() – as ever in WordPress you would need to make sure this happens at the correct point in the request (ie, at some point after both our taxonomy and your custom post type have successfully been registered and can be recognised by WP).

[Barry]

If all of your community-submitted events are consistently categorized somehow then you could link to the feed for that category, certainly. If they haven’t been then you’d have a little more difficulty, though I think it is still possible to query for and detect events that were submitted via Community Events I am not sure this is conveniently exposed in an RSS feed available ‘out of the box’.

[Barry]

Hi coryleyte,

I’m not sure I follow: I can access your calendar at the URL you provided and see details of individual events without any issue.

[Barry]

I believe so, the pattern of the URL would normally be something like this:

http://wpshindig.com/events/category/wordpress-meetups/feed/

Does that help?

[Barry]

That is indeed strange – and we did put a fix in place for venue widget related issues for this release, and of course tested the fixes and there was no problem we could see (of course we could have missed something, if so we’ll definitely take a second look).

You noted that you had tried deactivating all other plugins and reverting to a default, unmodified theme: can you confirm if this impacted on the problem at all?

[Barry]

No, that isn’t normal behaviour.

Can you try deactivating all other plugins and reverting to a default, unmodified theme – and see if that resolves this? If it does, try reactivating everything one component at a time until, potentially, you uncover anything that could be causing a conflict.

[Author]

Posts