Forum Replies Created
-
Posts
-
Howdy Karl,
Please pardon our delay in getting back to you. This bug had only 3 people report it, which made it a lower priority than bugs which got 4+ reports.
In my tests this is now fixed. I am running the latest versions of Event Tickets and Woo Memberships. When I setup a % based discount in Woo Memberships it is reflected properly on the single event page where you would actually make the purchase/add it to your cart. It lists the full price, but it’s crossed out and the discount is shown.
Please let us know if you are still experiencing issues on the latest versions. Cheers!
– Brook
Howdy Big Fish,
I looked into this and am not able to determine what the problem is. WordPress registers both the symlinked and realpaths using wp_register_plugin_realpath(). Our code here relies on plugins_url(), thus it should be able to accept either the symlink or realpath all while returning the proper URL.
None of us have Capistrano setup so we can not test your exact scenario. What happens if you create a test plugin, and pass plugins_url() both parameters, with __FILE__ as the second parameter? Does it return the correct URL, or does it contain the release/xxxxxx bits? If it does not return the correct URL, near as I can tell your server is somehow not compatible with WP’ handling of symlinks. Unfortunately that’s not a bug we can fix. If it is returning the correct URL, there might be something we can do.
I really appreciate you taking the time to reach out and share your findings. I wish I was able to find a solution for you right off the bat.
– Brook
Howdy again Jeremy,
We accidentally logged two tickets for this bug. Your topic here was associated with the duplicate, and so you did not get notified when we fixed this issue a while back. I am very sorry for the delay.
I wanted to confirm with you that you are no longer facing and problems from this. We included an update mechanism in a prior maintenance release. So, if you are running the latest versions of Pro you should be able to import recurrences rules from older versions with no problems. It sounds like you were already able to update all of your old recurrence rules and are not waiting on us. But, if for some reason you are still facing problems please reach out and let us know.
Cheers!
– Brook
Howdy Mediengruppe Thüringen,
I would love to help with this as well. Cliff asked me to take a look because I really enjoy optimization and performance.
Thank you for sharing the background info on what you have tried and what data you have. It looks like you also have two questions:
what’s the suggested server scaling for this huge amount of data? Maybe you got some advice for tuning the MySQL server for our special needs?
Good questions! To best help you I need to learn just a little more about your current server.
- Do you know what storage engine your wp_posts and wp_postmeta database tables are using, perhaps MyISAM or InnoDB? Out of the two InnoDB is basically always preferable, especially for performance.
- Where are you hosted, and what plan are you on? Is it something you could share a link to?
- Do you know how much RAM your database server has? Sometimes your database server is separate from your actual web server, and sometimes it has less RAM. So if your wp-config file doesn’t have the MySQL server set to localhost you might need to double check if your database server has a different amount of resources available.
- What version of MySQL are you running?
- Assuming your website is setup to use InnoDB everywhere, and you know how much RAM it has available, are you able to move some or all of the database into RAM using settings like this? That’s actually a pretty solid brief guide to tuning MySQL servers. If you have the access needed to tune your server like that, I would strongly recommend it.
15 second load times are crazy high, especially for the two queries you shared. That is a sign you either need to tune your server configuration, or have outgrown the server by quite a lot. With the above questions answered we should know a lot more definitely what’s going on, and provide some more advice from there.
Cheers!
– Brook
Howdy Kevin!
I’d love to jump in and explain some things. Performance is a huge passion of mine.
I’m going to reiterate what I said before about the changelog. Why is this not listed anywhere in the change log?
This is some tremendously valuable feedback and I really appreciate your sharing it. I too rely on changelogs in the software I deploy.
This absolutely should have been in our changelogs. That it wasn’t is a slipup on our end. I have made a note to talk about this a bit more on our next dev scrum. We are in the throes of changing when our changelogs get written, and this is one is a good example of where we can improve our new process of a bit to make it as effective as the old one.
Can someone explain to me why this function is hooked to to normal posts? I’m seeing it firing on regular posts that are using get_post_meta, not just the tribe_events CPT. This should only fire on posts that need it. I’m also not sure this is object cache friendly. Most posts are not going to have the “chunked post meta” set, but this function has to run its query to figure that out. You have added a new query to every page load for us that didn’t normally have to run before because the calls to get_post_meta were cached.
Unfortunately there is no way to predict which queries a page will make before it makes them. Any page could have a widget, shortcode, or get_posts() request that would query a chunkable post. So it becomes necessary to do two things:
- Get a list of chunkable posts. It makes sense to store that list in the wp_options table, get it on autoload, and then cache it in memory for the duration of the page.
- Hook into the post meta filters. In the hooked function, check if the current post is the cached list. If not, bail thus incurring the minimal performance impact.
This would be a typical WordPress way of doing things, and near as I can conjure would be the most performant way to go about it.
It appears that this is story post-specific settings in the options table as well? Any explanation here? The proper way to store a post-specific value is to store it in postmeta, not options
From what I am seeing in the code, the chunked meta data itself is being stored in the postmeta table. But the settings, such as which post types are chunkable, is stored in wp_options. Is this behaving differently on your system? Or are only IDs and post types being stored in the options table.
Please do let me know if you have any more questions.
Cheers!
– Brook
Howdy Chris,
Thank you for all your testing and sharing of information.
It was really bothering me that I could not reproduce this. I tried it a few more times, when I finally was able able to. It turns out if I select a value that appears above the default one in the dropdown list, it works. If I select one underneath, it doesn’t. Hence the discrepancy between your IE11 experience and mine.
This only happens when a default value is selected for the venue, only in IE11, and only if the other value selected is underneath the default.
The dropdown itself is powered by Select2. I found a bug reported to them. After watching the video I believe it to be the same issue, so I confirmed that I too was seeing this problem on a site. If you are already registered on Github, another comment on that issue saying you have the same problem might help communicate that this is something multiple people are experiencing.
For now I am going to leave it in their hands to come up with a fix. To be perfectly blunt, we have a backlog of bugs of our own that we are working to patch, and do not have time right now to patch ones in others libraries. When it does get patched in the “upstream” we can eventually integrate that fix into our plugins.
For now, the easiest workaround would be to have no default venue. Then the dropdown should work as expected, at least it has been thus far in my tests.
Please let me know if you have any questions. Cheers!
– Brook
Howdy Chris!
Cliff asked me to jump in since I run Windows. I have the latest patches for Internet Explorer 11 running natively on Windows 10. When I go to http://www.visitporterin.com/events/community/add and click on Venue the drop down appears, and I can select any item properly. The same expected behavior is happening on my local install as well.
Are you running any addons in IE that might cause you experience to deviate from mine? What version of Windows are you running? Is it a VM?
Cheers!
– Brook
Howdy Kevin,
Thanks for the detailed report and debugging. It is helpful to know where the error stems from.
This could be considered a bug in Advanced Post Cache. If it needs to run after all other filters, which in this case it appears to, it should be attaching itself with a large priority number. A priority number equal to PHP_INT_MAX would be perfect, as that is the absolute last thing that can run.
A pull request to Advanced Post Cache could fix that problem with The Events Calendar and any other plugin that uses this WP Filter.
Or, if you wish to remove_filter() for that method, and then reattach it with a higher priority you should be able to correct this conflict without altering either plugin.
Does that all make sense?
Cheers!
– Brook
Howdy Lisa,
I believe this has been fixed in a recent release. Can you update to the latest version and let us know if you are still experiencing any errors?
Cheers!
– Brook
I also wanted to add I really appreciate your understanding of our timetable. I do not have an update on when our fix will be scheduled yet. I asked the dev that was originally assigned the ticket what was going on, but he did not know. So I have just asked our strategist. As soon as I know something I will let you know. It is my hope we can tackle this very quickly and save you the time. But, that’s a lofty hope.
Either way I will get back when I know more.
– Brook
Howdy William,
Sure thing! Here is the repo. The view itself was a separate plugin you could download and install.
The snippet framework it implements was a precursor to our Extension framework. It’s basically a less polished way of making it easy for us to create miniature plugins for our products.
Tribe__Snippet__Month_Builder is convoluted, it is a modified a version of our old month class with the performance improvements tacked on. Modifying that old class, was what spurred us to rewrite the whole thing. It’s just too messy. Tribe__Snippet__Templates__Year makes use of the month builder, basically it shows how to implement. It too is convoluted due to legacy code.
I really hope that can help.
Cheers!
– Brook
I would have no problems sharing the proof of concept with you, but it’s not going to help you any. The proof of concept was for an an annual view. This view is basically 12 minicals on the same page. The purpose of writing it was two fold: a) To give us a jump start on an annual view. b) To see if we could rapidly speed up the minical.
But the problem is it will take a lot of work to alter the actual current minical to use this new code. Further, the code was built atop an old version of our Template class, and would not be compatible with the recent versions of the calendar. We are currently rewriting our Template classes, especially Month view. Current releases of Month view already include some of the proposed improvements. Once all the improvements are in place then we can rewrite annual view and the minical, both of which will be modified versions of the new month view.
All in all, it’s a fairly long path between here and our final solution, a solution that will speed up a broad section of our code. We have already started down it, and released some improvements. But, those will not directly impact the minical for a little while more.
Does that make more sense. Do you want me to share the code anyways?
Cheers!
– Brook
