[Barry]

OK – and the proposed solution (that I linked to) doesn’t solve this?

If so it may be more appropriate to speak to our esteemed colleagues across at WooThemes: this is really something that happens at WooCommerce level, WooCommerce Tickets has no real control over the order flow.

(You can bear this out by creating a test product – unrelated to tickets – and then running through a test purchase.)

[Barry]

OK, can you post your system information in here (this can normally be found at the bottom of the Events > Help admin screen). Thanks!

[Barry]

…Another “less extreme” thing to try is simply changing the template in Events > Settings > Display to Default Page Template. I appreciate you may have good reasons not to use this, but its just possible that will give you an easy, straightforward solution without resorting to a child theme or other approaches.

[Barry]

Ahh, I see – so in this case the problem is when events are pushed from WordPress to Eventbrite, rather than being an import issue?

[Barry]

Hi Darren!

So essentially you want orders to automatically complete, is that correct and does this help if so?

[Barry]

Hi fmas490,

I’m sorry this is causing you further difficulties.

Can you confirm what your actual timezone setting is (in WordPress > Settings > General) and point me to an Eventbrite URL so I can see if I can replicate this?

Thanks!

[Barry]

Hi Calum,

So basically you want to figure out what the user’s current location is and pre-populate the location field? If so, definitely possible, but it’s very much custom development territory.

There are various libraries and so on that would be helpful here (check out Net_GeoIP for instance) but something like this is really a modification we’d need to leave in your hands 🙂

Does that answer your question?

[Barry]

Hi Serhan,

I’m sorry you and your client are hitting these problems.

If you don’t have a large number of events and things are timing out there are a few steps worth trying:

• First and foremost, please do take the time to run through our standard troubleshooting steps in case this problem stems from a conflict with your theme or with another plugin
• Consider increasing the amount of memory available (see here and here)

Do either of those help?

[Barry]

Hi John,

That definitely sounds unusual.

I’m guessing you haven’t manually edited the stock levels; but can you confirm if you have completed any operations such as refunding orders or anything of that nature?

[Barry]

Sure, can you try adding this to your theme’s functions.php file?

add_filter( 'wootickets-tickets-email-enabled', 'no_wooticket_emails' );

function no_wooticket_emails() {
    return 'no';
}

If you hit any further obstacles with this (or indeed have any other questions) please do create a new thread though – as we do try to enforce a policy of one-issue-per thread to help keep things manageable and ensure fair access to support for all our customers.

At this point I’ll go ahead and close out this thread – thanks once again for your support 🙂

[Barry]

Thanks – I can replicate this now! You can collapse your test site and kill the credentials you provided (or indeed feel free to keep them around a while longer, to test out my proposed solution).

So generally in the WordPress world it’s expected that themes will include something called a wp_footer() call and this should almost be the last thing that is sent to the browser. One of the things plugins like ours use this for is delivering Javascript code – needed, for example, by our countdown widget.

Headway does indeed include a wp_footer() call but it calls it before the countdown widget is set up. The countdown widget then tries to add some Javascript in the footer – but the opportunity has passed, as wp_footer() has already been called.

This fairly skeletal child theme show a simple way of working around this; would you be able to upload it to your site and try it out?

[Barry]

Thanks for your patience so far.

I’ve repeated the same test as before (but with Headway 3.7.10 – thanks to the Headway team for helping out there) however I remain unable to replicate. As before, perhaps there is some key detail or setting I’m missing? Here’s what I propose:

• Can you set up a test site (where we are able to login and make changes etc)
• Add only our plugins plus Headway
• Nothing else should be added at this point – configure the countdown widget and check to see if you can replicate the same issue within the main events page
• Please reply with a link so we can observe this and also a login so we can do some further testing/figure out what the critical differences are between your setup and ours

If that’s doable and you don’t mind us troubleshooting on the test site we can hopefully figure things out from there 🙂

Thanks!

[Barry]

It’s registered within lib/the-events-calendar.class.php … do bear in mind though that we strongly caution against modifying core plugin files. There is always a better way!

With all that said, this sort of modification is a tad beyond the scope of what we can help with here on the support forums so at this point I’ll go ahead and close out the thread – I do hope the above plugin search link helps (or that you find some other solution) 🙂

Thanks again!

[Barry]

Hi!

And interestingly, why show the order status in the attendee list if it will only ever show completed orders?

It doesn’t only show tickets held in completed orders: what we’re really listing are issued tickets.

You might after all complete an order, resulting in tickets being issued, but then cancel or refund the order. There’s no way to claw back the tickets that have been emailed out and a cancellation (or refund) doesn’t always mean the ticket is void – so we provide the order status column to provide extra information to help vendors and their staff make informed decisions when checking in attendees.

However the issue here is that I’ve also just sent tickets to someone (me, in my test case) who hasn’t paid. That’s not really a workable solution either.

Hmm, well I understand your situation, certainly, but I’m not sure there is an easy answer.

If they haven’t paid and you don’t know for a fact that they are going to attend and hand over the money, should they really be added to the attendee list? I do realize that broadly meets the sort of workflow you’re aiming for, so I mean that as more of a general question – since with this solution we’re striving to meet everyone’s needs as best we can.

With that in mind, we’d welcome any feature requests you might post along these lines and that would also have the added benefit of letting other users comment upon and up-vote your idea.

I’m curious why the “on-hold” status was created if not to accommodate a “pay at hte door/reserve a seat” scenario? And how it could be useful if they don’t show up on the list so we know they have to pay at the door?

WooCommerce is a general purpose e-commerce engine and WooCommerce Tickets simply rests on its shoulders 🙂

There are a range of possible order states but none are added or implemented by WooCommerce Tickets itself. “On hold” for instance could be useful where there is a need to take an order out of the normal flow, perhaps because there is a dispute or suspicion of fraud, or some other reason – a lot depends on individual use cases.

Does that clarify things at all?

[Barry]

OK.

At this point can you run through our standard troubleshooting steps and, before you start reactivating your plugins/theme, can you repeat the permalink flush step?

Please note that if you happen to be using a caching plugin you should pay close attention to the plugin author’s recommended steps for completely removing caching (as it’s possible for the effects of caching to persist after the plugin has been deactivated).

Are you able to access the main events page at that point?

[Author]

Posts