[Barry]

Hi there @gazelle,

You’ve updated on class name but not the other (in your class_exists() check) so that could be worth updating.

Can you confirm where this code is situated and what if any hook it runs on?

[Barry]

OK, so if on deactivating Event Rocket there is still no (WooCommerce Tickets) ticket form, it sounds like that wasn’t the problem.

As requested, can you share details about the tickets set up for the URL you shared? What are the start and end sale date (and what is the inventory level)?

Thanks!

[Barry]

I can only say I’m sorry for these problems and we’re working as hard as we can on getting fixes out in as timely a fashion as we can – we’ll do our very best to keep you updated here in the topic as things progress.

[Barry]

Thank you 🙂

If possible, on on your staging site only, could you leave all other plugins deactivated (but keep The Events Calendar, Filter Bar etc activated) and switch to a default, unmodified theme then let me know so I can take a look?

I would also need the HTTP authentication details.

Thanks!

[Barry]

Hi @graphicpilot,

I’m glad that helped at least with part of the problem.

The further issue you have described is, again, a known issue that we will address as soon as possible. It did seem that for other users, despite the event being set to ‘password protected’, no password was actually set and it remained accessible.

If that’s not what you’re experiencing though that is definitely more concerning and we’ll look at raising the priority on that one.

[Barry]

Hi Aaron – I’m sorry you’re experiencing difficulties but it is usually best to create a fresh topic of your own: the root cause is not necessarily going to be the same as in @jocwebsite’s case and it also affords an opportunity for you to share your own system information confidentially.

Thanks!

[Barry]

It should still be possible if you import the events from eventbrite.com and have the temporary fix in place – but ultimately that may not work for everyone and waiting out on the definitive fix may be necessary.

[Barry]

The fix should allow the ticket iframe to display within the single event page, but it won’t correct the issue you are experiencing in the event editor, I’m afraid.

A substantive fix is en route, however – and we’ll make that available as quickly as we can.

[Barry]

@graphicpilot,

So on further investigation it is looking like a very recent API change has created this issue.

Unfortunately, this isn’t a change where a great deal of notice was afforded to us by eventbrite.com (and in fact they were unable even to provide us with a specific date for the change). So the circumstances are unusual and really there isn’t much more we could have done here.

I realize that still leaves you (and your client) with a problem, of course. Adding this snippet (for example, to your theme’s functions.php file) should hopefully restore the ticket form for imported events:

https://gist.github.com/barryhughes/345a6b12ce9c44f573fd

It’s not a complete solution – updating the event tickets via the event editor in WordPress for instance is still going to be problematic – but we are rapidly working on a more substantive solution which we’ll roll out as quickly as we can.

[Barry]

This may not work in all cases, but a temporary solution could be to add the following snippet to your theme’s functions.php file (or some other suitable location):

https://gist.github.com/barryhughes/345a6b12ce9c44f573fd

As soon as we release a definitive fix for this issue, though, it ought to be removed.

[Barry]

A further update: this appears to be the result of a very recent change in the Eventbrite API, for which we received only a relatively small amount of advance notice.

We’re working on this and will post further updates as things progress – thanks once again for all your patience.

[Barry]

Lothar: please disregard my last question, I’m able to locate it. I’m curious: if you edit the event (again, on eventbrite.com) is the event set to a “password protected” status (even if no password is set), or anything like that?

[Barry]

Hi guys,

I’m sorry for the difficulties and disruption.

Though you’re all welcome to follow along we’ll be primarily focused on helping the original poster – Lothar (@rensh) – in this topic. If you need help specific to your own installations, please do go ahead and create fresh topics of your own and one of the team will be happy to help 🙂

Lothar: could you provide me with a link to the eventbrite.com version of the event (corresponding with the one in your screenshot), by private reply if you prefer?

[Barry]

Hi Shah,

Sorry to hear you are experiencing difficulties.

With (Event Rocket-powered) RSVP facilities enabled as well as some tickets for WooCommerce Tickets, I see both ticket forms as expected.

While we can’t help directly with Event Rocket on this forum, I wonder if you could confirm whether deactivating Event Rocket makes any difference (to the display of the WooCommerce Tickets form)? If not, could you reply and let me know how your tickets are configured – what are the start and end sales dates and what is the stock level, for instance?

Last but not least, could you provide your System Information by way of private reply?

Thanks!

[Barry]

Hi @graphicpilot,

I’m sorry for the disruption and would love to gain some further insight into these issues.

Firstly, did the problem occur immediately after importing those events – or was a further edit made locally (ie, in WordPress) before they disappeared/before they were inadvertently marked as private on EventBrite?

Also, did this all occur after the 3.10 updates, or did it occur with the previous version (and do you still face it now that you hvae 3.10 in place, when you/your client try to import fresh events from Eventbrite)?

[Author]

Posts