[Kelly]

Hi, ggeiger. I apologize that you’re experiencing problems, too.

It’s looks to me that you’ve turned off month view on your site. (The other views show events.)

Would you mind starting a new thread so that we can help you get back in business?

Thanks! 🙂

[Kelly]

Hi, cecapra. Great question!

Here’s a post that should get you back in business: https://theeventscalendar.com/support/forums/topic/wootickets-showing-up-twice-on-my-event/#post-68895 (Basically, you need to add that priority.)
Also, please be aware that our normal response time is 24 hours. We appreciate your understanding about that. 🙂

Hope that helps!

[Kelly]

Hi, Ben! Thanks for your patience while we got you an answer on this one.

Basically, the events cost field is universal, so this behavior exists to prevent confusion where costs are also being set for tickets. It can be overridden though. Here’s a snippet of code to add to your theme’s functions.php file (or some other suitable place) that should make the cost field UI display regardless of ticketing plugin:

add_filter( 'tribe_events_admin_show_cost_field', '__return_true' );

Please give that a whirl and let me know how it goes. Thanks!

[Kelly]

Hi, John. Thanks for your patience while we got things straight on this one.

The crux of the matter is that when you refund a ticket (using WooCommerce), that doesn’t necessarily put it back into stock. There are in fact times where you may want to refund the purchase price of the ticket and continue to honor it.

As such, even though there are ways to compute the number of tickets that you’re talking about showing (the total less any that are refunded), we can’t rely on that always being the desired outcome for our users.

A couple of options are open to you here:

1. You could create something on the backend of your site to compute the value of tickets (total and sold) based on what you’ve described (total – refunded). That’s outside of the scope of this forum, but if that’s something you feel comfortable tackling on your own, we’re happy to help if you get stuck along the way.
2. You could post a suggestion on our User Voice forum page. We prioritize features based on the response they receive there. If there is a call from the community to implement this sort of logic, we’re happy to consider it.

Hope that clears up any confusion!

[Kelly]

Hi, maxhenry. Thanks for your follow-up. 🙂

As I mentioned earlier, this is a limitation of the Eventbrite API and not something that we have control over. As long as you use multiple TLD’s with Eventbrite, you will have issues where the ticket boxes for events not under the TLD that you have specified do not appear.

For us to write something that would allow a user to specify this on a per event basis would be cumbersome to the vast majority of users (who standardize on a single TLD) and would be a major change in the product. If it’s a feature that you feel that the community would be eager for, please do suggest it on our User Voice forum (https://tribe.uservoice.com/forums/195723-feature-ideas). We prioritize implementation of features based on the response they receive there.

Unfortunately, this is not something that can be fixed for your installation of TEC.

Is there anything else I can help you with?

[Kelly]

Hi again, Quentin! Well, I hate to tell you, but it looks like you’ve found a bug in our latest release.

We’ll get right on fixing that, but in the meantime, you’ll need to edit the file directly. Sorry for the extra hassle!

[Kelly]

Hi, Quentin! That’s great that you feel comfortable digging into all of this.

The WooCommerce Tickets UI that you see in the event editor is itself injected using the tribe_events_tickets_metabox_advanced action and you could also use that same action. I’m afraid there are not any more specific hooks at this time, but if you find you run into difficulties, we’d certainly welcome any feature request you might make along these lines. (If so, feel free to post away over on https://tribe.uservoice.com/.)

I hope that helps!

[Kelly]

Hi, tommyacquario. We’re happy to help. Would you mind restating your issue? Thanks!

[Kelly]

Hi, bluecanoe. Since it’s been a couple of weeks, I’m going to close this thread. Please feel free to start a new one (and please reference this one by URL) if the issue is still ongoing.

Thanks for being a TEC user! 🙂

[Kelly]

Thank you, Wayne! 🙂 As soon as I have something concrete to report, I’ll post here.

Happy new year!

[Kelly]

Hi, highasp. You are indeed seeing a bug in our current release. Our apologies for that.

This all stems from needing to swap out the legacy datepicker that we’ve been relying on for one that works with the current state of things. Unfortunately, this turns out to be a huge lift that affects many aspects of our plugin(s). As such, it’s taking more time than we’d hoped to make sure that everything is in order.

That said, we are aiming for this to ship with the upcoming release that we’re working on at the moment. If there’s any way that we can get an interim solution to you before then, rest assured that we’ll make that happen.

Again, apologies for the issues with February. Please know that this is a top priority for us and we’ll get out a fix as soon as we possibly can.

Thanks for your patience!

[Kelly]

Howdy, folks. You are indeed seeing a bug in our current release. Our apologies for that.

This all stems from needing to swap out the legacy datepicker that we’ve been relying on for one that works with the current state of things. Unfortunately, this turns out to be a huge lift that affects many aspects of our plugin(s). As such, it’s taking more time than we’d hoped to make sure that everything is in order.

That said, we are aiming for this to ship with the upcoming release that we’re working on at the moment. If there’s any way that we can get an interim solution to you before then, rest assured that we’ll make that happen.

Again, apologies for the issues with February. Please know that this is a top priority for us and we’ll get out a fix as soon as we possibly can.

Thanks for your patience!

[Kelly]

Howdy, folks. You are indeed seeing a bug in our current release. Our apologies for that.

This all stems from needing to swap out the legacy datepicker that we’ve been relying on for one that works with the current state of things. Unfortunately, this turns out to be a huge lift that affects many aspects of our plugin(s). As such, it’s taking more time than we’d hoped to make sure that everything is in order.

That said, we are aiming for this to ship with the upcoming release that we’re working on at the moment. If there’s any way that we can get an interim solution to you before then, rest assured that we’ll make that happen.

Again, apologies for the issues with February. Please know that this is a top priority for us and we’ll get out a fix as soon as we possibly can.

Thanks for your patience!

[Kelly]

Hi, kimrubenstein. Great question!

Looking at the page you linked, I notice that it’s at a different URL than the one that is linked from the “View All Events” link in your menu bar. Could that be the root of the problem?

[Kelly]

Hi, Quentin. That’s certainly unexpected behavior.

You’re definitely putting them in the correct place. I’m surprised that they’re not being recognized. Have you had a chance to confirm that if you make the same changes to the files in the plugin dir that the changes are effective?

[Author]

Posts