[Barry]

That does indeed appear to be related, my bad for not finding the related issue on our bug tracker. If it does happen to be the same problem then yes, it should definitely be addressed in a forthcoming maintenance release.

[Barry]

OK – and though I see you marked down that you tried deactivating all other plugins can you confirm if you also tried switching to a default, unmodified theme? If so did that have any effect on this?

[Barry]

Hi Bob,

I believe this behaviour only affects the list of events – it should still be possible to open an individual recurring event and trash it from within the event editor, using the trash link near the Publish|Update button.

Does that help at all?

[Barry]

Trashing one instance of a recurring event will indeed trash them all and that is by design, owing to the underlying architecture. If that’s likely to be problematic we’d definitely be open to feedback/suggestions to change this and our UserVoice page would be a great place to do this:

https://tribe.uservoice.com/forums/195723-feature-ideas

As other users can than add their support.

[Barry]

Right 🙂

As in my initial response we are aware of some areas where an amount of optimization could take place, either by reducing the total number of event-related queries required to build a given view or by making them individually more efficient (or both of those) and that will be an ongoing work in progress, but if you need to drill into this right now and figure out if it is purely The Events Calendar or if something else is impacting then this could be a worthwhile exercise.

[Barry]

Hi hallahund,

I can definitely see the utility of this and believe there is some code floating around the forum in relation to the 2.x series of our plugin. Unfortunately, I can’t seem to locate it at this time and it is a touch outside the normal scope of support we offer here.

We’ll certainly add this to a list of tutorials we plan on writing for the latest incarnation of the plugin – in the meantime if you need something right now I’m afraid we’d need to leave you to dig into some code or work with a developer to this end.

Thanks – and sorry we can’t do more on this occasion.

[Barry]

Hi Skatch,

Could you try adding a rule like this one to a suitable place, such as a custom tribe-events.css file (please see our Themer’s Guide for details on setting this up if you haven’t already done so):

.tribe-events-venue-map { width: 600px }

Does that help here?

[Barry]

Hi Niki,

Can you confirm if this affects only events that existed prior to updating to 3.x – for instance, if you create a new event set in the future does the same problem occur?

Thanks!

[Barry]

Hi Nanette,

Unfortunately this is a known bug and ought to be released in a forthcoming maintenance release.

In the meantime, can you try the fix suggested by our developer Jessica as outlined here? https://theeventscalendar.com/support/forums/topic/recurring-event-prompt-dims-screen-and-is-unclickable/#post-59303

Thanks!

[Barry]

Sure thing – if you have any specific questions that come up in the process then although we’re a bit limited as to how much support we can offer for this sort of customization, if we can prod you in the right direction we’ll happily do so 🙂

Good luck! For the time being though I’ll close this thread.

[Barry]

Right – and does that also affect regular WooCommerce products (even those which are not tickets)?

[Barry]

Thanks!

Your custom tribe-events-pro.css is indeed being loaded – it’s just that the rules aren’t specific enough. Can you try something like this:

table.tribe-events-calendar td.tribe-events-present { background: #0a9690 }

[Barry]

Ah ok, I see.

Unfortunately we can’t really help with that. That would be a custom piece of work that you’d really need to determine on your own (or with the help of a developer).

What you can basically do though is take the post ID for the product and then use that to retrieve a piece of meta data called _tribe_wooticket_for_event – this will provide you with the post ID of the related event, if there is one.

You can then load that event/post and pull out whichever details you need (or you may be able to simply use a number of our template tags directly, by passing in the event’s post ID).

[Barry]

OK, so basically (as you can probably tell from the nomenclature used in the iCal import buttons) we’ve currently got things set up to import a specific event or batch of events.

This would definitely be a worthy feature request though, if you’re game to make one:

https://tribe.uservoice.com/forums/195723-feature-ideas

The great advantage to UserVoice is that other users can find the suggestion and add their support – and though that’s far from the only factor in us taking up a suggestion it can provide us with a useful metric.

Thanks!

[Barry]

Could be worth a try for sure. Given the sort of pressure your production site is under though, is it worth considering if the existing resources simply aren’t sufficient? It may also be worth considering strategies such as query caching at MySQL server level.

It sounds though like you’ve got a good handle on how to approach this, and with regards to importing existing events I think I’d be inclined to make it as simple as possible – perhaps creating a dump of the entire database, perhaps by using the mysqldump utility, and pulling it across to your other server with wget and then importing it directly into your test database – that would reduce this basically to a set of three command line operations.

[Author]

Posts