[Austin]

I’m having the same issues with Event Tickets and Event Tickets Plus v4.7.1 on one of my customer sites. Downgrading to both plugins to v4.7 resolves the issues. While attempting to go through my own troubleshooting steps I’m seeing some strange behavior. I’m not seeing any errors using Chrome DevTools or in PHP error logs. When I clone my live site (running v4.7.1 with issues) over to staging the issues go away. The live site and staging sites are running identical themes and plugins. The only thing I can think that is different is that the staging site has emails disabled. Is there anything email related in the v4.7.1 update?

[Austin]

Perfect. Thanks for the details and the explanation. I’m still perplexed as why all of the events had different post parents as well. The post parent IDs seem to increment in a sequence. I suspect someone keep breaking the series with unique info. I was able to successfully remove my events by modifying the SQL to target a specific title rather then a post parent.

[Austin]

I installed the ‘Recurring Event Cleanup Tool’ unfortunately it’s not seeing the out of control event. It’s only showing legitimate recurring events, not the 24,000 orphaned events. I assumed that’s due to the fact that the parent event is already deleted. Is there anyway through SQL I can bulk select them? It doesn’t look they are sharing any similar info. The post_parent columns are unique. Anything else which I could target which would be common in either the wp_posts or wp_postmeta table?

[Austin]

I discovered the conflict was due to the plugin ShiftNav – Responsive Mobile Menu. Something in their CSS stylings prevents the dropdowns from working on the frontend. If anyone else runs into it, I was able to fix by changing the following block of code to a position: static;.

.shiftnav-wrap {
  padding: 0;
  margin: 0;
  background: none;
  position: relative;
  max-width: 100%;
  overflow: hidden;
}

[Austin]

This reply is private.

[Austin]

This reply is private.

[Austin]

Ok so disabling JSON LD on Month View took the load time from over 20 secs to around 9 secs. Thanks for the tip.

[Austin]

Sounds great. Look forward to trying out the optimized queries.

It looks like this particular site is just slow all around. Any general recommendations? The frontend: http://telhai.staging.wpengine.com/events/ is taking over 20 secs.

[Austin]

After spending some time with this theme I was able to resolve my issues. In case anyone runs into a similar situation, here is my solution.

In the parent theme, this was the problem code: https://cloudup.com/csfNZcqWP5s. I was able to set things right in my child theme with the following code added to the functions.php file: https://cloudup.com/c-Ir7z6ilBf. Hope that helps someone out there.

[Austin]

Like I said, I’m running an identical copy of plugins and theme on my locally computer. The issue is not happening there. And yes if I switch to a basic theme the issue goes away. I still want to resolve this issue with this particular theme.

[Austin]

I found a work around: https://searchwp.com/support/topic/wpengine-long-query-killed-query/. With that said, I assume WP Engine’s recommendations would be for you guys to clean up the queries so that it’s not as long. I still have not received a response from them. I’ll consider my issue resolved.

[Austin]

Ok, I pulled this from my logs: https://cloudup.com/cIzrQcIEv5S. I found this which explains long and killed queries on my web host, WP Engine: http://wpengine.com/support/long-query-killed-query-error-logs/. Any thoughts or suggestions?

[Austin]

[Austin]

Indeed that’s because I manually fixed the problem by adding in the following two .js files:

For what ever reason I can’t figure out why they aren’t being included by the plugin. I shouldn’t have to write them into my theme file.

[Author]

Posts