Forum Replies Created
-
Posts
-
Thank you again Mike for testing that snippet with a base theme. Have you tried Gergana’s solution? It is truly odd that Cliff’s snippet was not working for youand to be up front we have no idea why it wouldn’t. But, Gergana’s solution goes about this a different, yet elegant, way. If you create a theme override as outlined there, does add to cart bypass the cart page?
Just so you guys know we are keenly aware of the need to show ticket info and be able to edit it in the cart. We have listed this as an upcoming feature/request here. If it is something you would like to see us implement, please vote on it. This will not bypass the cart page though. Bypassing the cart page will break WooCommerce for websites which offer products other than just tickets, and will hamper the ability for users to purchase tickets for multiple events at once. So our general solution will not be to bypass the page, but we would like to show the info and allow people to edit it as needed.
Thank you all for sharing your solutions and tips. Please let me know if any of you still need assistance or have open questions that stemmed from the solutions shared. Cheers!
– Brook
Thank you guys for helping us look into this. I think we have isolated the issue. It has cropped up for users who have a different WordPress Address than their Site Address. Typically it will be something like the WordPress URL is https://example.com while the Side URL is http://example.com. Could you go to WP-Admin > Settings > General and double check your options there? If they are different from each other, such as one being HTTPs, could you alter them to match if possible? That should resolve the issue for now, while we work to release an actual patch in the future.
Does that all make sense? Did that work for you guys? Please let me know.
Cheers!
– Brook
Thanks for getting back Gerry. I think we have isolated this issue. It has cropped up for users who have a different WordPress Address than their Site Address. Typically it will be something like the WordPress URL is https://example.com while the Side URL is http://example.com. Could you go to WP-Admin > Settings > General and double check your options there? If they are different from each other, such as one being HTTPs, could you alter them to match if possible? That should resolve the issue for now, while we work to release an actual patch in the future.
Does that all make sense? Did that work for you? Please let me know.
Cheers!
– Brook
Howdy Thomas,
Thank you for reaching out, I would love to help you find a solution for this. I am one of the performance nuts on our team, it’s a big passion of mine.
Thanks for all of the information you have shared. I have reviewed your site and I am not finding anything super anomalous about it. Fixable performance issues typically boil down to odd settings or giant post databases. But your site seems to be well configured.
A one second TTFB is very good. For WordPress hosts I often see 3+ seconds, and DreamHost is just over 3 seconds on average. Are you on on the DreamPress hosting plan perchance? It sounds to me like your issue is likely related to being on a shared server. When one or more other websites on your server is seeing a lot of traffic, your load time increases. That would explain the fluctuations in your load times. You were saying that even with all plugins enabled you saw a ~1 second load time, but that it has fluctuated to 4 now. When browsing your site I saw it vary from 2 to 8 seconds.
One thing that might help speed your site up a bit is to cleanup any old post revisions and empty the trash. The WP Optimize plugin can help you do this with ease. This might trim the size of your post database by a noticeable amount. The smaller your post database is the faster your site will be.
What is your end goal here? Are you trying to get consistent 1 second page loads? If so sadly I think the only thing you can do is get a dedicated host like a VPS. This will basically give you your own server, so that no other website on the same server can’t slow you down when they are under load.
Or did you just want to know why enabling calendar plugins is causing slowness? Due to how WordPress works post meta date searches are incredibly slow. So any calendar built according to WordPress best practice will have a huge performance handicap. This is just an unfortunate side effect of WordPress’ flexibility. Because of that we have to work very hard to make our plugins as fast as possible, and we do. We run regular performance audits in a wide variety of situations. Anytime we find an area we are ripe for improvement we’ll release an update for it. And while there are a few things our last audit found, none of them seem applicable to your configuration. You have already configured your site nicely when it comes to performance.
Does that all make sense? Does it help answer your questions?
Cheers!
– Brook
Thank you for redoing the test Alexander! That does make sense.
The issue is that your theme does not call the_title() anywhere. WooCommerce expects this, or get_the_title(), to be called at least once during the content body. The first time that it is called WooCommerce will override it with the Woo page title.
The best solution here would be to add the_title() to your theme, inside the content area/loop. Doing that will not only show the current page title, but it should also stop WooCommerce from inserting its title in place of the event title.
Does that all make sense? Will that work for you? Please let me know.
Cheers!
– Brook
Howdy Rachel,
I would love to help you with this.
The wp_options table for the site has a row in it with the key tribe_events_calendar_options and inside of this you will find all options for the calendar, including the one you are looking for here. You will notice that this contains a serlialized array. You could either copy this array from a working install after setting up everything how you like. Or you could unserialize it and modify as needed, then reserialized.
Does that all make sense?
Cheers!
– Brook
Howdy Again Greg,
As with before I will make sure Geoff B. see your topic when he’s online. He is our translations expert so he is well suited to answering this.
Unfortunately though I don’t think this is something we can fix on ‘our side’. WordPress.org democratized translations a while back. Their goal was to make translations more accurate, which is certainly understandable. But, they also made translations much slower, and removed plugin author’s power over translations.
The best solution is for people to participate in WordPress.org Translations, voting on accurate ones to speed up their adoption. And then play the waiting game. Democracies can be a bit slow after all. 🙁 Sadly this waiting game must be played after every single plugin update. Thus, it often makes sense to not update right away, and wait for the new update to get translated before clicking update.
Geoff B knows more here. There are some workarounds you can do from your side that will help speed things up. He can walk you through these if you’re interested.
Cheers!
-Brook
Howdy Greg,
I am sure Geoff B. would love to pick up where he left off. As you’ve probably noticed he often responds towards the end of the day, so he might not be online for a few more hours. But when he is I will make sure he sees this.
In the mean time I looked up that ticket you were wondering about (issue# 66822). This is the sort of ticket that will be slotted for a major release, such as “4.4” or “4.5”. Right now we are working on 4.4 and expect to have it out before the end of the year. After that we will begin work on 4.5.
Unfortunately though this ticket is not yet slotted for a release, and so it might be 4.5 or significantly later when it gets released. I know that’s not what you wanted to hear, and I hate to be the bearer of such news. But the unfortunate reality is that even with our giant team we still have a lengthy queue of things we plan to build. So the whole process usually takes many months.
Maybe Geoff can work with you in the mean time to find a workaround, something that will work well enough in the intervening months?
Cheers!
-Brook
Well that is unexpected, but a conflict seems to be the only possible explanation. The more I look at this the more that explanation makes sense. Likely it’s your theme since your theme does not appear to be showing the_title() anywhere. You will need to isolate what is conflicting before a fix might be possible. Do you mind trying the conflict test again. In particular make sure you switch themes to an unmodified version of the Twenty Sixteen theme.
I have searched and searched and not seen anyone else with this issue. Do you have a link to that thread?
Cheers!
– Brook
Thanks for letting us know Peter. That is the third report we have seen. We are still trying to isolate whether or not it might be a conflicting theme or plugin, or perhaps an issue unique to a given browser version. What browser and version are you using?
Cheers!
-Brook
I can understand that fear. Fortunately those pages are all marked noindex. Google will however crawl a few of them, just to make sure they have spidered your site reasonably well. If you use Google’s Admin Dashboard you might see them mention crawling those pages. However, according to Google’s official documentation they will not index them and they will not impact SEO since they aren’t indexed.
– Brook
Ooops, my last response must not have submitted properly. Sorry for the delay.
The likeliest cause of this is that something else is filtering the WordPress filter “the_title” without properly checking to see if the post_type matches the thing they wish to filter. In laymen’s terms, you likely have a conflict with your theme or one of the other plugins causing this. You can test to see if this is the problem by switching themes to the default Twenty Sixteen theme. Then deactivate all other plugins except these ones:
- The Events Calendar
- Event Tickets
- Event Tickets Plus
- Event Tickets: Additional Email Options
- WooCommerce
Now try creating a new order. The problem should go away. If it does, can you try reactivating plugins one at a time until this issue resurfaces? Which plugin is or theme is causing the conflict? It might be possible to create a compatibility patch, but it might not. We will need to know which one is conflicting before we can research further.
Does that all make sense? Please let me know.
Cheers!
– Brook
Thanks for getting back Thomas. Yeah like George said the only bug that was fixed, at least that was relevant to your topic, is this one:
where our plugins’ scripts and stylesheets were being served over HTTP when they should’ve been served over HTTPS, or vice versa.
Which of course you were already able to work around.
there are missing the organizers and/or sometimes the venues are missing .. but of course not anytime
We are working on this. It is now a priority 1 bug, and something we are going to address in the next maintenance release (which will either be 4.4.1 or 4.3.4). We have already done about half the work on it, but were not able to quite get it completed when the rest of the current 4.3.3 was ready.
Status Off Most sheduled imports is
Triest: Daily
Last Import: unknownThis I might be able to help you with right now. The most likely cause of that would be if WP Cron was disabled. WP Cron is the only way to schedule things in WordPress. It can be disabled, and is sometimes even disabled by website hosts.
Could you try temporarily installing the WP Crontrol plugin? This will add a tool to WP Admin > Tools called “Cron Events”. It will show you a list of all cron jobs scheduled on your server. Could you find the one called “tribe_aggregator_cron” and see when it’s Next Run is scheduled. Is the next run time in the past? What happens if you click “Run Now. Do any of your automatic imports switch from “Unknown” to having run just now?
Cheers!
– Brook
