[Barry]

Hi Robert 🙂

I’d actually envision that if the data is correctly laid out in the database there’d be no reason to programmatically trigger anything. Reading your replies, I’m not sure if everything is indeed set up correctly (in terms of one parent post/many child posts, per chain of events)?

I’d love to help further on this one, but it is pretty much custom development territory and so is something that you’ll largely have to drive forward yourself, I’m afraid.

Thanks!

[Barry]

Hi Robert,

You could try calling the relevant method programmatically:

TribeEventsGeoLoc::instance()->generate_geopoints_for_all_venues()

Setting that to run sometime after or during the init action would probably be wise – if you call it too early it may fail for a variety of reasons 🙂

Good luck!

[Barry]

Hi metaeitaly,

You and your client are understandably frustrated – and while there isn’t too much we can do right now I would like to address some of the points you raised.

So in 2014 you are selling a product that can only work with one language at once???? This is ridicolous!

I don’t think it is fair to say it is ridiculous, 2014 or not: let’s remember that this is not an easy problem to solve.

WordPress has some decent localization capabilities and our plugins are pretty much 100% compatible with those. We have also gone to great lengths over the years to work with the community in order to build and ship a plethora of language packs with our plugins – I hope that alone tells you that we are serious about supporting the international community.

However, at least currently, the ability to dynamically switch between languages is not something WordPress can do by itself. Consequently, there is not a uniform standard for us to meet that would allow us to achieve compatibility with all the varying multi-language plugins that exist out there.

I would posit this as an alternative viewpoint: setting multi-language plugins aside for the moment, we know that our pagination links (and almost everything our plugin outputs) can be translated and that this all works as expected. That’s the result of our efforts to use WordPress’s localization facilities throughout our codebase.

Given that, why are these plugins, whose job is translation and nothing but translation, failing to translate the string?

I’m not passing the blame, I have zero doubt that they are doing their best and are bound to hit up against various hurdles, but I do want to emphasize that this isn’t only a problem for us to solve.

I really hope that you will provide me a solution that makes links working properly in a very short time because I really don’t know what else can I do! And client is asking me why pagination links don’t work!!!

Have you approached the plugin author about this and have they assessed why they are unable to translate those particular strings?

If there is any feedback they can relay or specific failings in our code that stop them from doing their job then we are absolutely open to investigating changes, so long of course as they don’t compromise our ability to follow the prevailing WordPress standards generally.

In summary, we realize this is a challenging problem and a source of frustration for many users – and welcome any further input from you, The Events Calendar community at large and indeed authors/developers of translation plugins – but right now I’m afraid there simply isn’t a “plug in and play” workaround we can provide.

[Barry]

Our pleasure!

I’ll go ahead and close this thread since it sounds like you’re all sorted – but if we can help with anything else please don’t hesitate to create new threads as needed and one of the team will be only too happy to help.

Last but not least, if you have a moment to spare, we’d love to hear your thoughts on The Events Calendar across on our plugin review page 🙂

Thanks again!

[Barry]

Pretty puzzling.

So, putting the referer part of the first log entry aside for the moment (I’m concerned that may be a little misleading), do you know that those log entries relate to this particular subsite? Or is this a general log for the site/network as a whole?

As in my first reply, it’s important also to remember that a LONG QUERY warning is a potential indicator of problems – but isn’t always a reliable one. The fact that they are a little longer than a very simple select statement doesn’t necessarily mean they are poorly performing as a consequence.

Given you are experiencing the actual 502s on random, non-event related pages of this particular subsite I wonder if you need to look elsewhere for the source of this problem … as the fact is these queries and the presence of our plugins on your network may have nothing to do with the problem.

• If the 502s are specific to one subsite that doesn’t make use of The Events Calendar, have you been able to explore something basically similar to our own standard troubleshooting steps but in relation to other plugins/your theme?
• Could you touch base with WP Engine and ask if the logging of queries could be tweaked to include the length of time they take to complete?
• If you can’t get anywhere with the above then, as a last-ditch troubleshooting measure, could you even temporarily deactivate our plugins – place a suitable “The calendar will be live again soon” notice up or something similar – and see if the 502s continue or abate?

Thanks for bearing with us, here. It’s a tricky thing to troubleshoot particularly given the specific nature of the problem on your network  – but hopefully between us and your host we can help you to uncover a few answers 🙂

[Barry]

Hi metaeitaly,

I’m sorry you are experiencing difficulties.

1. my site is in foreign language (I’m no more using WPML because your plugin conflict with it!) and works fine except the previous/next links of each kind of view that, once clicked, load previous/next page in english. If reload page it shows correct language.

I can definitely see this when I visit the URL you provided – yet not locally. If I configure things to use any number of different languages the pagination links stay consistently in the relevant language: they do not revert to English.

For the avoidance of any doubt, while I see you noted having moved away from WPML are you using any language plugins beyond WordPress’s own native ability to switch language?

[Barry]

Hi there jamieskinner00,

We’re always happy to help (or at least, in the case of customizations, point you in the right direction as best we can 🙂 ) but it is massively appreciated if you can create new threads of your own for each issue you need help with.

If you’d like to go ahead and create a new thread and provide some specifics one of the team will be only too happy to help (please do review our Themer’s Guide first of all, though, as that covers many of the basics of safely customizing the plugin).

Thanks again!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi Courtney,

Thanks for posting!

Please note that the discussion in this topic took place back in 2012 and numerous things in our plugins, not to mention Gravity Forms, may have changed in the interim 🙂

(Plus, generally speaking, it’s always best to create a new topic of your own rather than post in someone else’s.)

I also need to highlight that the level of support we can provide wherever you integrate with another plugin – Gravity Forms included – is pretty limited. In the “old days” Gravity Forms was popular because Community Events hadn’t yet been created (and, once it was released, of course was not initially as mature a solution as it is now) – so we were more inclined to go that extra step.

Now, however, Community Events would definitely be our recommended plugin if you need a frontend form to accept new event submissions: if you choose to take a different approach that is largely something you’ll need to drive forward by yourself or with the assistance of a developer.

With that in mind I’ll close this topic: if you do have any further questions on this please feel free to post a new topic – but, again, I’d emphasize the level of support we can provide on this one may be limited.

Thanks again!

[Barry]

OK – and just to confirm (because I see you marked this as resolved) do you need any further assistance?

[Barry]

Hi Zachary,

Thanks for getting in touch.

The closest I’ve seen is this thread from this July [https://tri.be/support/forums/topic/abandoning-events-calendar-pro/], in which Caleb wrote that the issue could be resolved by removing the limit on WPEngine’s side:
========
This is a known issue with WP Engine, since they limit the length of SQL queries. Try adding the following to your wp-config.php file, which should hopefully disable that limit in WP Engine:
define( ‘WPE_GOVERNOR’, false );
========
I asked WPEngine if I should do this, and they said that this would prevent the error from being logged but would not prevent the error itself. So I don’t think that will solve my issue.

Exactly so: stopping those queries from being logged won’t prevent the queries from happening so it’s all to the good that they are logged.

WP Engine log long queries for valid reasons but it is definitely worth keeping in mind that a long query in of itself is not necessarily a poorly performing one – its just a potential indicator of problems.

We don’t have very many events. Maybe a few dozen, none recurring. Our site is hosted on WP Engine at the “Professional” tier. This should be more than enough to handle our traffic.

It certainly sounds like you have ample resources, especially for such a small number of events. Of course, one thing I don’t know is how much traffic your site is receiving – but let’s proceed on the assumption that it isn’t excessive given available resources.

So my main question is how do I get the plugin to stop generating these long query errors. My secondary question: Do you think the long query could be related to the 502 errors.

Basically, there is no particular way for you to stop these long query errors – which might more properly be described as warnings (nothing is necessarily going wrong and longer queries can in fact be better performing queries, depending on the context).

I am curious about the 502 errors, though, particularly given your other note:

Interestingly, the 502s are not generally seen on the events page but on random pages on a subsite of our multisite network.

Are you able to replicate the same problems on your staging site? If so, can you run through our standard troubleshooting/conflict test steps and potentially eliminate the potential for a conflict stemming from another plugin?

It definitely isn’t unknown for our plugin to generate long query warnings – but the fact that you have only a dozen or so events raises something of a warning flag in my mind (I wouldn’t actually expect our plugins by themselves to trigger these warnings with so few events) … might some other plugin, or your theme, be impacting on the query?

Can you share one of the actual queries in question?

Thanks!

[Barry]

Hi!

Can you try adding the following code to a suitable location (your theme’s functions.php file should be fine) and see if that helps to mitigate this issue?

/**
 * Workaround for themes, plugins and customizations that rely on
 * redirect_canonical() *not* redirecting when pagination is used
 * on a static front page.
 */
add_action( 'init', 'modify_pro_canonical_filter' );
 
function modify_pro_canonical_filter() {
    if ( ! class_exists( 'TribeEventsPro' ) ) return;
 
    $pro = TribeEventsPro::instance();
    $filter = array( $pro, 'filter_canonical_link_on_recurring_events' );
 
    remove_filter( 'wp', $filter, 10, 1 );
    add_filter( 'template_redirect', $filter, 20, 1 );
}

Let me know how you get on!

[Barry]

Hi kqed,

That sounds like an interesting problem to solve 🙂

We’re a bit limited in terms of how much assistance we can provide for custom development tasks, but I want to highlight first of all that the meta key for the end date is actually _EventEndDate (note the leading underscore). If changing that by itself doesn’t help, might it be possible to steer away from tribe_get_events() in this situation and use WP_Query directly?

If you reference the orderby section of the WP_Query docs you can see it is possible to order against a meta key:

codex.wordpress.org/Class_Reference/WP_Query#Order_.26_Orderby_Parameters

If that doesn’t work it may be that you need to do some more advanced work and change the where clause using other filters and hooks provided by WP_Query.

I hope that at least provides some paths you can explore – and good luck!

[Author]

Posts