[Barry]

Hi accessrose, does this thread give you any ideas?

The thread you were following seems to have been written for 2.0.11 or earlier and will not work at present.

[Barry]

One thing that does jump out is the use of NextGEN – it’s on our incompatible plugins list precisely because it interferes with database queries (though we haven’t seen this particular one being modified before).

What we’ll do is keep this open for a week or so just in case either of you can confirm either that NextGen is at the root of this, or some other plugin, or even that the source of the problem is completely different but if you don’t have time that’s understandable and we’ll go ahead and close this.

[Barry]

@David: thanks, no problem at all!

@zacheryh: have you had a chance to look into this at all?

[Barry]

I can definitely appreciate that and happy to have helped even if in a very small way.

It’s great to hear about interesting things being built on top of the plugin and if you feel so inclined definitely drop us a line to share the results of your work once you approach completion (pro [at] tri [dot] be).

Thanks again!

[Barry]

No problem at all, I can appreciate it might be disruptive if you don’t have a test site to work on.

Looking at our test site though – which is fairly minimal in terms of the theme (it’s heavily based on one of the default themes) and additional plugins – the output of that button seems pretty clean by comparison so, if this does turn into something you want to address at some future point I suspect investigating the possibility of a theme/plugin conflict is the right course of action.

But for now it sounds like you’re happy with things as they are – which is great – so I’ll go ahead and close this thread.

Thanks!

[Barry]

Ahoy Steve, thanks for getting in touch.

Looking at your site I can see something (probably your theme, based on what you’re telling us) is enqueuing a much older version of jQuery (1.7.2) than is required for The Events Calendar.

Since The Events Calendar requires WordPress 3.5 as a minimum it also expects the jQuery version to be at least 1.8.3.

Would it be possible for you to touch base with the theme author and enquire if it is indeed the theme that’s responsible for this and if it can safely use the shipped version of jQuery in place of its own?

Thanks!

[Barry]

I suspect you’d need to build this up with custom code and we’re a bit limited in terms of how much support we can provide for this sort of thing.

To return events for 1st January 2005 to 31st December 2005, for instance, you might be able to leverage our tribe_get_events() function, setting eventDisplay to custom and setting the event_start_date and event_end_date properties accordingly. You may also want to set posts_per_page to infinity (-1), depending on how many results are likely to be returned.

[Barry]

Hi Maria,

What happens if you deactivate all other plugins and switch to a default, unmodified theme? Does that resolve this problem (even if it means you run into the greyed out dialog issue you referred to)?

I’m not sure from your final comment if doing that sort of troubleshooting is not possible in your case or if you simply haven’t had an opportunity – but since we haven’t seen many other reports along these lines it does suggest a conflict may be at work.

Thanks!

[Barry]

Hi Patrick: it should respect the WordPress wide date format setting … is it viable for you to change that?

[Barry]

Hi Joseph – there is a current bug with iCal export in relation to recurring events, but it seems your problem is a bit different as no events from October (even those that aren’t recurring) seem to come through.

Can you try:

* Deactivating all other plugins except for those by Modern Tribe
* Ensuring all Modern Tribe plugins are up-to-date
* Switch to a default, unmodified theme

Does the same behaviour still happen? Does this allow you to isolate a plugin or perhaps your theme as having some sort of impact here?

[Barry]

Hi Laura,

With regards to the first question what I’d ask if the following doesn’t help is that you create a new thread – we’d much rather handle different topics in different threads to avoid confusion.

Basically though there are many factors that could be at play. If, as an example, you are using the default page template (check Events > Settings > Display to see if this is the case) and test using tribe_is_event() too early (before the loop, essentially) then it is destined to fail because of the way event content is injected into the template.

On the other hand, if you are using the default events template you could test with tribe_is_event() much earlier – at the top of header.php ought to work, for example.

For the second question, no, unfortunately that doesn’t help. I understand that. My point was that I have tested every single-event.php file that there is and none of them change the single event page.

Oh I see – apologies for the misunderstanding.

The default single-event.php template responsible for single event pages actually resides in the-events-calendar/views (it’s a core template, rather than a PRO one) and copying that to your theme’s tribe-events subdirectory ought to do the trick.

Does that help?

[Barry]

Hmm not getting stuck in the spam filter.

OK, we’ll definitely keep an eye out for further reports of this, right now though I’m not sure there is much we can do about this one, unfortunately 🙁

One element I’m stuck on now is changing the Venue slug.

You can filter the arguments used during post registration with tribe_events_register_venue_type_args (and indeed you can alter properties like this immediately post registration – the registered_post_type action could be leveraged here as your possible trigger to do this).

[Barry]

Yep unfortunately the forum simply doesn’t do a great job when it comes to accommodating code – sharing it via Pastebin, Gist or a similar service is preferable for the time being 🙂

So with that being the case, what if in addition to whichever plugin you disabled to resolve the initial issue you disable everything except your Modern Tribe plugins and at the same time switch to a default, unmodified theme such as Twenty Twelve – does that remove the extra code?

[Barry]

If the hosting environment is identical and the same version of WordPress is running, with the same plugins and theme and the same data in the database and you aren’t able to replicate this then I think, realistically, we are also going to have problems in replicating it.

Are you able to resynch the databases and effectively flip the two? So that the current test environment becomes your live environment, or otherwise stage a transition of that sort?

[Barry]

OK – we do actually have Jetpack on our list of incompatible plugins although we weren’t aware of this particular problem occurring. Although I can’t guarantee anything we’ll hopefully have an opportunity to assess what’s happening and what might be going wrong at some future point.

For the time being though I’m afraid there’s not too much we can offer at this time (and so I’ll go ahead and close this thread – of course if you have any other issues please create a new thread or threads as needed 🙂 ).

[Author]

Posts