[Barry]

I’m not sure I see this tutorial on our current tutorials list – so it may be one of those which are left in place only as a convenience to the community and indeed if this is the tutorial you are referring to you can see we’ve marked it as being applicable to 2.x builds only.

At this time I’m afraid we’d need to leave it to you to figure out the solution – though hopefully, despite not being directly applicable to 3.x builds, that tutorial can serve as a good starting point.

Good luck!

(I’ll go ahead and close this thread since there’s not much more we can do to help here, but definitely feel free to create new threads as required should you hit any other issues/have further questions.)

[Barry]

If I make it to Vienna I’ll let you know (funnily enough I’ve been enjoying some Stiegl these last few weeks which I think comes from Austria 🙂 ).

In any case, glad you are all sorted here and I’ll go ahead and close this thread – thanks!

[Barry]

Hi John – you’re absolutely right (and sorry for the inconvenience). We’ll take a look and if there is any workaround we can offer you before a substantive fix becomes available in an upcoming maintenance release we’ll be sure to share it with you 🙂

Thanks for your patience – I’ll try and update this again as soon as I can.

[Barry]

Hi Dulcie,

That should certainly be possible. You would need to set the post_type argument correctly (for venues it is tribe_venue or you can refer to it with TribeEvents::VENUE_POST_TYPE) if you want to focus only venues.

Splitting them into three views by venue type is a little more involved – without knowing how you are going to make this distinction it’s hard to offer any advice – but I’m afraid in any case we will really need to bow out and leave this sort of customization to you 🙂

Good luck!

[Barry]

Hi Andy,

I think you are right and perhaps the taxonomy query is taking precedence and perhaps causing other query properties to drop … we’ll make a note to look into this – and sorry for the inconvenience in the meantime 🙂

[Barry]

Hi trevellyan,

That would definitely be frustrating.

In the first instance can you visit the license management page here at tri.be and clear the entry relating to your site (let me know if it isn’t there) – then try clearing and re-entering the license key on your own site one more time.

If that doesn’t resolve the problem it may be easiest to update manually: you can grab copies of the latest core plugin here and access PRO and any other premium addons you have purchased here – I hope that helps and sorry for the inconvenience.

[Barry]

Hi verdipro,

Thanks for taking the time to post here. Can I ask you to share a download link for Royal Slider as a private reply (perhaps by uploading a .zip file to Dropbox or a similar service)?

Thanks!

[Barry]

If you view the organizer (or venue) from the editor, is the correct URL showing at that point? In other words, is this only a problem on the “front end” of the site?

Thanks!

[Barry]

If your site is translated into a different language then that is, unfortunately, a bug in our code. Again we’re aware of this and have a fix in the works.

The basic problem though is that the actual CSS classes are being translated (so list might become lista, as one example) and that means our style rules that target those items and set up the special-to-view icons are failing. It’s possible as another user did to workaround this by adding custom CSS rules, if you are comfortable with CSS of course.

Again, we are aware of this issue and hope to get a fix out there shortly.

Since the original issue is resolved I will go ahead and close this thread. Thanks again!

[Barry]

No problem – and sorry for the inconvenience 🙂

I’ll go ahead and close this thread (since we are aware of the issue and plan to fix it ASAP) but if there’s anything else we can help with please don’t hesitate to create a new thread or threads as required.

[Barry]

Hi Heinz,

Your child theme (or another plugin) would seem to be replacing the default copy of jQuery that ships with WordPress with a very much older version (1.3.2).

Assuming for the moment this is due to the child theme I’d recommend talking to the theme author and checking A) if it is indeed their theme, or some library they are using, that is doing this B) if it is necessary and C) if it cannot instead use the far more recent and up-to-date copy of jQuery that ships with WordPress.

Based only on a quick scan, this would also seem to be tripping up some code belonging a plugin called User Access Manager. Hope that helps!

[Barry]

Hi Anthony,

Fantastic idea and one that you could certainly add to our feature request page. If you were building this yourself then there are a few possibilities.

One would be to effectively remove the limit on the number of events that display per calendar cell – but customize the relevant template such that after x events have displayed the rest are allocated a CSS class that hides them from view (they could then be expanded when someone clicks on Expand All).

Depending on how many events you are dealing with however that might add quite a bit of extra load to calendar requests, so an alternative could be to listen for clicks on the Expand All link then request the complete list of events for that day by ajax – you would need to build a handler to do this – then insert them into the table cell (and so you would only load those extra events if and when a user requests them, rather than always).

Hope that gives you a few ideas!

[Barry]

Hi siggiboy81,

The Default Events Template might be considered the normal way of presenting events to the world and that’s probably why there’s no problem there. Generally in fact we’d recommend it wherever possible – the ability to use other templates really exists only to provide a convenient workaround for theme compatibility reasons.

If an alternative like the Default Page Template is used however (bearing in mind here that, ordinarily, such a template is a vehicle for just one piece of content – whereas for event calendar purposes we might need to display a stream of many event posts within it, such as if list view is selected) then some special magic has to happen to facilitate that.

What essentially happens here is that our own content is wrapped up in a container – this does not have a real or valid post ID of its own – and that is used to carry the real event data, Trojan horse style, into the page template.

The plugin you are using probably stores SEO information for each event using the event’s post ID as its reference. In this scenario however it is likely that is can only see the container ID, which is largely meaningless. I hope that explains things a little better – it probably is possible to workaround this if the Default Events Template isn’t a viable choice for you – but such a workaround is not unfortunately something we can help with a great deal.

[Barry]

Hi hansford77,

The forum isn’t a great place to share code as it’s prone to dropping bits and pieces where various symbols are used. Just to be certain that what I’m seeing is accurate can I ask you to share it via Pastebin or Gist and drop the link in here?

Thanks – and sorry for the inconvenience 🙂

[Barry]

Not a great deal admittedly – but does my last reply make sense to you / help you to pin down whatever might be inserting the “Posted in” text?

[Author]

Posts