[Brook]

Hopefully the team at Tribe can work on an easier way to show the ticket meta to all users to hook it in and display it anywhere as required as this new feature develops as I can see huge potential in it. I appreciate this feature is new so the more contributions and ideas on how it can be used will surely help move it forward.

Definitely. I am sad this is such a pain. And not only are we trying to make it easier to pull that data and show it anywhere, one feature request we would like to build is showing this information either by default or as an option you can tick in WP Admin. But until then we have to rely one some fairly in depth customizations like the one you are building.

What is giving you trouble with the checkout page? Have you tried hooking into the same action George used in his snippet?

add_action( <span class="pl-s"><span class="pl-pds">'</span>woocommerce_email_before_order_table<span class="pl-pds">'</span></span>, <span class="pl-s"><span class="pl-pds">'</span>add_attending_events_above_woo_order_info<span class="pl-pds">'</span></span>, <span class="pl-c1">10</span>, <span class="pl-c1">2</span> );

Cheers!

– Brook

[Brook]

Thank you for clarifying Lisa! I now get the problem. Yes that is a bug and one we’re working to fix. I am hoping that it will get patched in version 4.2.5 of our plugin, which is due for release in 2 weeks time. But we have not finished scoping that release yet and so I can not say for sure if it will stay in there. Either way I have added your topic to the list of those affected and bumped the priority of that ticket. This means that we will respond to you when a release is ready with a fix, so that you can then hit update and watch the problem disappear. 🙂

I wish I had better news on that front. Right now the only option for fixing this is to downgrade to a past version of the plugin that this worked in (Downgrading a plugin).

Does that all make sense and answer your questions?

Cheers!

– Brook

[Brook]

Howdy Oliver,

Geoff had me look this at this yesterday and today, along with another senior dev. First of all I am very sorry that our response times are not fast enough. I am sorry for the timezones too, that obviously amplifies the pain.

As you probably know our terms of service outline that we typically response once every 24 hours. This is what you agreed to when purchasing our products. For customers like you who are in a pinch we always do our best to respond faster. And Geoff has been doing awesome here. But response times will almost always be on the order of hours, and even then due to the reality of our support setup it might border 24 at times.

If your senior developer have no instructions or testing methods to resolve this by the end of today we will have to move on and fix it ourselves for our client.

I totally get that. We are a digital agency too and have tight deadlines at times, and have been in the same boat. When you’re paying for asynchronous support, and you need something faster, your only available options are either changing the deadline or being your own support. We will continue doing our best to help, but if our fastest times aren’t fast enough it’s going to have to fall on you. If you want a refund in light of this or any other reason please know we will happily provide one, we do not want you to be unhappy with our product or service. You have a couple more days for our usual 30 day refund window. We will happily give you one past this if we can, but sometimes credit card companies put a maximum time limit on things and 30 days is when some of them start.

Unfortunately I can not see any helpful topic or a specific target to resolve the issue in your senior developer response, he/she did not give any testing instructions or indications to where we should look into.

I am very sorry that our communications have not clearly conveyed to you what we’re thinking. Allow me to try to outline what we’ve tried, and what you will need to do at this point.

At the outset Geoff tried reproducing this on his system. He placed an order for 6 tickets, each had attendee info. The 6 orders went through, the attendee info appears on the attendee page, in the tickets email, and so forth. Yesterday one of our senior devs tried the same thing. Today I did it again. We have each tried to determine why yours is clearing after 5, and have not had success. We’ve tried this test with various versions of PHP and in a variety of server environments, in each case all 6 orders and their info went through.

For our debugging we only see that the
const META_KEY = ‘_tribe_tickets_meta’;
is not being saved in the database once you register more than 5 tickets, there is nothing showing in the dev tools no errors no warning and no feed back of any type.

That is good to know. Really the API that would post those events is almost all WordPress, so any errors that might might get generated would come from WordPress.

Could you try the following three things to glean more info?

1) Do you have WP_DEBUG enabled, and perhaps WP_DEBUG_LOG ? Once that’s enabled try another test order. Does your debuglog show anything?

2) What do your MySQL logs show? WP engine has some great MySQL logging that might help indicate any errors.

3) Could you try the following:

1. Create a new event, fill in a few details, hit public
2. Add a WooCommerce ticket to this event. Give the is WooCommerce ticket a single meta field, let’s make it a required text field and call it “Attendee phone number”. Save the ticket.
3. On the front end order 6 of those tickets, fill in random numbers in each of those 6 attendee fields. Hit purchase.
4. Approve the order.
5. Now in your Tickets Email that you will receive, is the attendee info in each?
6. If you visit the attendees page do you see 6 attendees? Is each of their meta present?

Hopefully one of those will shed a lot more light on this. It might give you an idea on what the problem is or what further diagnostic steps to try. If you can wait for our assistance, please let us know how each of those three things goes. That will help us too come up with more ideas for narrowing down the problem, or might let us know outright what’s going on.

Does that all make sense?

Thank you for working with us until now Oliver. I am truly sorry this has been such a pain. We will continue doing our best to help here. Cheers!

– Brook

[Brook]

That is good to know Janice, thanks for pointing this out.

Showing WooCommerce orders does yield a bunch of queries. From what I have seen in the past these are all unfortunately necessary, but I’ll keep this in mind for the next performance audit. Maybe there is something more we can do here?

That is a big reduction! Where you including events in the main blog loop, or did you have some widgets on that page? If you had for instance two Minical widgets, I could see it causing a lot of duplicate queries.

Thanks you for getting back. I’m happy to hear you are getting things under control. If there is more I can do to help please let me know, I’d love to. The above questions are more just for my information, it’s always good to know how people are using the plugin so we can optimize in the future.

Cheers!

– Brook

[Brook]

Thanks for clarifying Chad. This should be easy enough to do with a WP filter. I just wrote up something you can insert into your functions.php which will add CSS classes to the month view events:

https://gist.github.com/elimn/310d67f65c2bebdfce2ca42146f6ebcb

The class you would want to target would be ‘tribe-month-multiday-start-date’. Style that with CSS and you should be golden.

Did that do you what you needed?

Cheers!

– Brook

[Brook]

You are welcome! I am happy that helped!We do have a performance improvements coming down the line that will help further, so things should only get better with future update.

Thank you for getting back!

• Brook

[Brook]

Howdy Thomas,

I would love to help you with this.

That brief bug did seem to leave an impact. Not only is your single event loading slow as you mentioned, but your /all/ page is showing some duplicated. We have a full description of the bug along with a cleanup plugin that you can run that will erase any remnants of that issue. If I were you I would install that cleanup plugin, then play the waiting game. It tried to do its cleanup as fast as it can without slowing down the server, so it works in the background. It might take a few days to a week to finish, but each hour that passes your site will get a bit faster. Does running that help significantly?

In the mean time you might be able to help by limiting the amount of events shown per page. Currently you have it set to show 50 events on your main view. While that is great for preventing people from needing to click to the next page, it also means that the main events page puts 50x the load of a normal page on your database (not the single events because of the bug, but 50x than one of your other regular WP pages). If you go to WP-Admin > Events > Settings and change the # of events per page to something like 10, the page should load noticeably faster. Once your single event page is loading fast again, you might change this back to your original. But hopefully until then this should help.

Does that sound like a plan?

Cheers!

– Brook

[Brook]

Oh that’s beautiful. Thank you for sharing. I’ve not seen someone put the form there but I really like. We might have to make that the customization aye?

Cheers!

– Brook

[Brook]

This reply is private.

[Brook]

Hmm, what would happen if someone clicks that link? Let’s say you have two tickets available for the events, a VIP and a regular, which would it add? I dont’ think it would be wise to skip that page. It seems like it would be a necessary step for the user to select quantity and ticket type before something enters their card.

Would you rather just include the ticket sales area underneath each item in the list view? That way they could select ticket quantity and type without having to go to the single event page.

Cheers!

– Brook

[Brook]

Howdy Lisa,

I would love to help you with this.

From what I gather you are just trying to generate the term list, using wp_terms_checklist(), for the post on the ( /events/community/edit/event/{ID}/ ) page.

This should be easy enough to do. The first argument that wp_terms_checklist() is the post id. So you can just pass it that.

If you are doing this inside of our template file then you can obtain the event ID from either of these variables:

 $event->ID
 $tribe_event_id

If you are outside of the template look you can still obtain the event ID doing this:

global $wp;
$event_id = $wp->query_vars[ 'tribe_community_event_id' ];

Now that you have the event ID just pass it to

wp_terms_checklist( $event_id, $args );

Obviously you will still need to setup $args. But you should be able to generate that checklist now anywhere on the page. Does that do what you wanted?

Cheers!

– Brook

[Brook]

Howdy Pascha,

I would love to help you with this.

The view you are loading there, Month view, can place a very large load on your database. To help alleviate this we created the Month View Cache. Do you have that enabled in WP-Admin > Events > Settings > Display ? If not, could you try enabling it?

Even with that enabled though we have noticed one portion of the page that is not getting cached in the latest version of The Events Calendar . It’s the JSON-LD results. For now we advise disabling JSON-LD on month view if you are hitting performance issues. You can do that by pasting the following snippet at the top of your theme’s functions.php file. Replace the opening “<?php” with this snippet, as this snippet includes that opening tag.

https://gist.github.com/elimn/9ce1c3e64d060b758e22627b815455ae

With that snippet in place, and the cache enabled, are you seeing much faster page load times on Month View? The first load might be a little slow while it generates the cache, but after you reload the page a couple of time I expect it will speed up dramatically. Does it?

Cheers!

– Brook

[Brook]

Howdy Janice,

I would love to help you with this. Performance is my specialty.

Thanks for sharing all the details you’ve collected to date. It’s of interested that only one of the pages has so many duplicate queries. Does it have a lot of widgets on it perchance? Right now I am just seeing the “we’ll be right back” message, so I can’t tell what’s supposed to be showing.

Would you be interested in generating a new, temporary, admin account for me to login with and view the Query Monitor output? If so could you respond in a private reply here with the Username/password you’ve created. Once I’m done inspecting the site I’ll let you know so you can delete the account.

We do frequent performance audits on our plugin and our last one about a month back yielded a few areas that are ripe for improvement. We have already released updates for some of those, but have a couple major ones coming down the line. One deals with Month View, the other the Mini Calendar widget. It is possible these will help you. It is possible I will find some other areas to improve after inspecting your site with Query Monitor. Or it is possible you just need a faster server and will want to look into upgrading. Whatever the outcome though I am happy to help you figure out the available options.

Cheers!

– Brook

[Brook]

Howdy papertower,

I would love to help you find the proper hook. Based on your description I think you could just use the WP action ‘save_post‘. Or more specifically, use the action save_post_tribe_events which will only fire when saving the post type tribe_events. It works the same as save_posts but does not fire as often.

I just tested it to double check. This fired for every post saved including the followup recurrences:

function tribe_temp_test( $post_id, $post) {

}
add_action( 'save_post_tribe_events', 'tribe_temp_test', 2, 2 );

Did that do the trick?

Cheers!

– Brook

[Brook]

You are welcome! Thank you for getting back and sharing the solution.

Cheers!

– Brook

[Author]

Posts