Forum Replies Created
-
Posts
-
Thanks for sharing the previous versions.
- I could envision a lot of reasons for the delay. One possibility is that event you’re trying to update was originally created in 4.2.2 or prior.
- Duplicate events was one obvious symptom to the problem in 4.2.2. However, it did not duplicate in every case. When the recurrences rules are improperly serialized, weird and hard to predict things can happen.
- The chance is small, but certainly still possible. As my last comment mentioned, please make sure to make a database backup before running the tool, just to be safe. The tool mostly makes use of the plugins public API to trigger a recurrence rebuild for select events, and even after reexamining its code I see no reason why it would have issues here.
- Recurrence rules are only accessed at certain times by our plugin. I could certainly see room for them getting corrupted in one update, and the problem not revealing itself for a while.
- That looks like a solid fix. I would leave that in their for now. The tool actually trigger a recurrence rebuild for affected events, so it is quite possible it will work better in unison with your “hack”.
I understand where you are coming from, it is very possible this old bug which improperly serialized those rules is unrelated. But, so far you are the only person I’ve seen with this issue since the days of 4.2.2. We have many thousands of users, and the latest update has been out for a couple of weeks now. So it be odd if that update introduced a bug like this and yet it only affected your site.
Please let me know if you have any more questions, or if that tool helped.
Cheers!
– Brook
Howdy Brian,
Thank you very much for sharing your research into this issue. As you have already seen Cliff suspects this problem might be related to a couple of topics, and you shared a few more.
While Cliff is himself a very skilled developer, he did ask for me to look at these topics as well and see if I found anything. One thing that has become abundantly clear is that not all of these issues are related. One is almost certainly a conflict from Ninja Forms. Another likely stemming from a bug that can crop up when international characters are in the Attendee Meta Label. In both cases, different symptoms were shown in the screenshots. Yet, some of the other topics are like yours: they neither run Ninja Forms or are in in a foreign language. So, it is likely that there is at least one or more issues being faced in these topics.
To help us figure out what is happening in your case, would you mind taking some screenshots of the problem? In addition, if you are interested in creating a new temporary admin account for us to login with and view the problem for ourselves, that could shed even more light on the issue. All we will do is observe, seeing the page in question, plus perhaps a few settings pages, just to confirm we know exactly what is happening on your site. We do not plan to change any settings or anything like that.
Does that all make sense? Will that work for you? Please let me know.
Cheers!
– BrookHowdy Alex,
I was researching a similar issue when I came across your topic here. We hit this once before a while back. Ninja Forms was accidentally breaking all WP List Tables, including the Attendee List one. Adding this snippet to the functions.php file disable Ninja Forms on the Attendee list page, and fixed the issue. Does it work for you?
https://gist.github.com/elimn/a944c3f0772f25d5abc5fb0a28d91eab
Cheers!
– Brook
Howdy Erica!
I’d love to help you with this, thank you for clarifying what is happening.
If you share a link to the website I might be able to offer you the CSS you’ll need to patch it. I can’t promise anything except that I’ll give it my best effort.
Based on your screenshot I’m guessing those items are inheriting a negative text-indent from somewhere. Typically your theme is the primary thing that adds CSS everywhere, but sometimes it can be a plugin or something else odd. Using a browser inspector any CSS expert can look at the element, see what CSS it’s inheriting and from where, and thus find ways to fix the problem. So I can try that, or whoever you typically use for CSS issues should be able to as well.
Cheers!
– Brook
What news! I am happy to hear this.
I want to explain the “bug” that is causing your slowness. Due to an oversight in our planning JSON+LD is not cached when you enable month view caching. So each time the page reloads it has to rebuild the JSON+LD section.
We are working to cache JSON+LD in the future, which will eliminate this issue. In the mean time, simply disabling it as you did is a great solution. This section is often not used or needed.
One thing I want to mention, on occasion the page will still take a while to load. Each time you add or update an event, the cache must be rebuilt and the page will slow one time. But once it gets rebuilt, it will be fast for all of your visitors again.
Please us me know if you ever need anything else. Cheers!
– Brook
Excellent! I am happy you got the page to load. That does help shed more light on the issue.
I noticed that when you click the next/prev buttons while in Month view, they load decently quick. These buttons reload the content area of the page with the new month. This led me to conclude that the primary thing slowing down your site is JSON+LD, because that will not be reloaded when you click next/prev month.
I further realized that the snippet I shared to disabled JSON+LD has stopped working in recent versions of WordPress. I just updated it. Would you mind removing the code from your functions.php that I had you add before, and replacing it with the updated version?
I’m going to email our web host and find out if they can make sense of that but its shows up for nearly every page served. The site is undergoing lots of development so very well could get fixed but in the meantime doesn’t seem to affect performance…
Good call on contacting the host. I’d agree, this is unlikely to be related to your performance issue.
We have a lot of events which are not really events but merely time slots for people to sign up for (like you would book an appointment at gym or in this case an art studio). Those are not important to show on a month view ever, would it help if I set all of those with the “Hide From Event Listings” flag = Yes? Would the month view then skip over them? I’m not sure how that view is built.
Setting the flag should speed things up a bit. But, if you don’t necessarily want to hide those listings, why not try hiding the JSON+LD markup again and seeing if that helps dramatically?
Cheers!
– Brook
Howdy again,
Thank you for clarifying!
Since you said the ticket was getting deleted, and not the attendee, I wanted to have a second look at your code. The code is not complete, so I can not test it out and there are a few gray areas. However I think I understand why the ticket and not the attendee is getting deleted.
Inside your delete ticket function you are calling Tribe__Tickets_Plus__Commerce__WooCommerce__Main::get_instance()->delete_ticket(). But instead of passing it the attendee ID in the second argument, you appear to be passing the ticket ID. This method will delete anything you pass to it, so if you send it a Ticket ID and not an attendee it will delete the ticket. Your programmer can view the code that powers it in: /event-tickets-plus/src/Tribe/Commerce/WooCommerce/Main.php and go down to line 973, or simply enough can just change the Ticket ID to the attendee ID. Likely this will fix the bug you’ve encountered.
Did that help?
Cheers!
– Brook
Howdy Michael!
Because Cliff knows I love performance topics he reached out and asked me if I had any ideas on what might be going on here.
First of all, thank you very much for enabling logging and taking the time to click around. That is very helpful.
Your server is generating a 500 error when a month is viewed. Usually the server has a separate set of logs for 500 errors. Do you know where the “server error logs” are located on you server? Do they indicate an error message, such as “memory exhaustion” that coincides with the time/date that you attempted to view a Month?
Based on how many events are showing up in Week view, it would seem Month is probably try to show about 150 events. Put simply, that’s a lot! While you shared a link to a single category, Month view still has to sort through ~150 events total before deciding which ones to display.
Due to the nature of Month View, which can show up 126 event titles and descriptions on one page, it is the slowest calendar view. This is why the view has built-in caching. Have you enabled Month View cache in WP Admin > Events > Display? If not, would you mind trying to enable this? Further, would you mind adding this snippet to your theme’s functions.php file? That snippet disables JSON+LD in month view, which due to a current bug can further speed up month view. With this in place, does Month View load?
If not, could you try temporarily deactivating the Filter Bar plugin, then seeing if you can load Month View? You can reenable it as soon as your done and not lose any data or anything. Filter Bar is a very powerful plugin, and a side effect of some of its capabilities is that it can slow things down a bit. Thus, disabling it might help speed things up just enough to bypass the memory exhaustion or timeout that is apparently happening. Knowing if it does will give us a little bit more info to diagnose with.
Does that all make sense? Do you mind trying those things?
Cheers!
– Brook
Howdy Mike,
Thank you for taking the time to reach out, and especially share your logs. Performance is incredibly important to us, and more than once log sharing has helped us to isolate issues on certain server types or configurations.
The reason performance is so important to us is because WordPress’ flexibility in some situations imposes astounding overhead. With meta date queries, like you shared last year, it is hundreds of times slower than it could be. As you can imagine a calendar has to do a lot of date queries. Thus any calendar built according to the WordPress best practice has a severe performance handicap, and we have to continually work very hard to make it fast.
JOINs in particular are painfully slow, and we investigate them all to see which we can remove. At times our programmers have been very inventive with finding ways to remove these.
That said, it’s not like our software is perfect. No large piece of software can claim it’s performing the best it can, this is always an ongoing battle. Right now we have a few performance issues with The Events Calendar we’re working to address. But the notable ones are all limited in scope, and do not affect every page. Do any of these sound like they might be affecting you?
- Admin page has an unnecessary JOIN when you have hidden the date columns. Your log did not indicate what page was being viewed, tho other logs might. Was the page that was being loaded when the server crash an admin one?
- Month view with caching enabled is not caching JSON+LD. A workaround is available for disabling JSON+LD. Was the page Month view?
- Minicalendar widget does some unnecessary queries. Do you have the Minical enabled?
- There are some other miscellaneous issues, all causing a very small performance impact. Some fixes for these are being worked on, and might result in page load speeds that are ~2% faster.
Please let me know if you have any question. Performance is a big passion of mine and I’d love to dive in as deep as you want.
Cheers!
– Brook
Thanks for sharing your debug log! That is a new bug, and one we are working to fix.
Right now the fix is in QA. If everything goes to plan then the fix will be released alongside 4.1.1, sometime within 1 week. Here we go again! I am sorry you have hit two bugs in a row, hopefully this will be the last one.
– Brook
Howdy Again Bram,
I am very sorry for the delay. This topic was mismarked on our end as already having a response!
Is Woo return an extension? If so.. which extension are you talking about
Do you know the customer himself needs to be able to cancel? so not the admin!As an admin you can refund a Woo order by following these steps.
However, since it sounds like you need the customers themselves to make this request through the website you might be interested in this extension: WooCommece Extension: Returns and Warranty Requests. Put simply, this extension adds a button to the user’s “My Orders” page. The button can be labeled anything you want it to be, such as “Request refund”, “Cancel order”, etc. When someone clicks this button they are given a short form they can fill out, and when they submit the form an email is sent to you with the return request. From there you can approve or disapprove the return. The extension has a lot of other features you probably don’t need if you’re just selling tickets, so you could ignore those.
Just in case the above is not what you’re looking for, I want to circle back to your original question:
Everything works.. except one BIG thing.. if a user clicks delete on the front-end the WHOLE ticket gets deleted.. It only needs to delete this specific attendee.. not the whole ticket.
It sounds like you would be happier with updating the status of the Order, rather than using our delete_ticket() method. You could set the status of the order to refunded using Woo’s API. When the order is refunded the ticket still remains in your list, but it is clearly marked as refunded and the “Check In” button is not available.
The only difficulty here is that an entire order needs to be refunded. Let’s say one person checks out with two tickets in their cart, then later decides they want to return one of them but keep the other. If you set the order status to refunded, both tickets will become unavailable. I suspect this might be what your developer was referring to when they said “it’s not possible”. Does this situation happen very often, or is it rare enough you could handle this “manually”? If you can not handle this manually, then what your developer has already built is your only good option.
Does that all make sense? Will that work for you? Please let me know.
Cheers!
– Brook
Howdy again Eric,
I would love to help you find a solution for this, as best I can.
This is likely possible to do. The jQuery plugin which powers that dropdown/search is called Select2. As of Select2 version 4.0 the search function can be modified. Here is an example modification that likely works exactly like you want. The problem is that we are using Select2 version 3.5.
You or your PHP developer could dequeue our version of Select2 and enqueue a newer version of it, such as 4.0. From there following this example you could swap out the “matcher” algorithm for one of your own, likely you would be happy just copying the one from that example.
Does that make sense?
Cheers!
– Brook
I am going to pass this along to our strategist. Here’s what I am expecting to happen:
- For starters, we will make it so that the Featured Events never changes automatically, you must always manually set it. This is a bug to my mind.
- Later on we will add a feature that saves editted events as drafts, when you have set your site to manually approve events. This will not affect Featured Events directly, but it will give admins the chance to manually change the status if they so choose.
Thank your for the feedback. I am going to add your topic to the bug ticket, that way you will get notified as soon as a fix is released for this.
Cheers!
– Brook
Howdy Dirk,
Thanks for your patience over the long weekend.
It’s by far the most requested feature by organizers and even more by customers, but now we know that we can disappoint them ;).
I really appreciate you sharing this feedback. I’m going to share it with our strategist.
We’ll also install the suggested extension but it does only effect customers with an account right?
Yes. It gives the ticket purchaser the ability to view their past tickets. It also supports RSVPs, whoever RSVP’d can view the tickets associated with those. But if you have setup Woo so that users can purchase products without creating an account, then they will not be able to view their tickets.
Cheers!
– Brook
