Forum Replies Created
-
Posts
-
Dear Andras,
a lot of questions… Here are my answers:
– Does the staging contain exactly the same data / events etc.? Can you reproduce the issue there as well?
=> yes, it is a complete copy of the db and all files of the wp installation. It was created on Monday morning, german time. The incidents happened on Monday afternoon and evening.– How many events have been published to the calendar?
=> approx. 300 (growing)– What hosting environment is being used? Shared or dedicated? Operating system? Same used for staging and production?
=> shared environement. approx. 50 other customers. staging and production are on the same system, even in the same db (different tables)– Does the same performance issues pop up in a default WordPress environment? (Default theme, only calendar plugins.)
=> can’t say. Because the problem is created by a search/filter activity from a visitor. And we can’t keep running the production system in this setup.– Might be helpful to install the Query Monitor plugin to help diagnose any specific functions that might be at play.
=> note sure what you mean by this. Can you explain further?– Could you send me a database dump and possibly the wp-contents folder so we can test your setting as well in different environments?
=> we do a complete backup every night (db + all files ). Can send you the copy from Monday morning as zip. It’s 1 GB – How can I upload it?– event aggregator imports are deactivated now in the setup.
Best regards
UweDear Andras,
nice to have an ticket with you again 😉
To your questions:
1. When did it happen: yesterday we had 2 cases, one (the first sql command) at around 11:43 am German time and secondly at around 23:30 pm german time
2. The page . hard to say, most probably they come from our main event page: https://finde-deinen-malkurs.de/kurse/list/?tribe_paged=1&tribe_event_display=list&tribeHideRecurrence=1 (this is at least the only place, where you can use the filter and search options)
3. No, there is no Aggretator import running neither scheduled nor manually.
By the way, we also have in the meanwhile a staging environment running. In case you need access, pls let me know.
Best regards and good luck for the investigation
Uwe
Dear Cliff,
good news for this topic. The avada guys found the root cause. It was due to too man “div-tags” in the event posts. This tags came in from certain copy & paste activities from some organizer websites (we copied the content of events).
We removed mostly all of this div tags and now all works fine again.
Thanks for your support.
Regards Uwe
Dear Courtney,
thanks for your quick response. The image has “normal” size of 400px x 368px. Normally we scale down all images to the height of 368px- Unfortunately I cannot simply switch off all plugins because we only (still) have the production environement.
For your information, I have in parallel opened a ticket at Avada because I assume it’s somehow a mix of Avada php/css and Tribe …
I investigated further and found out, that the height (if you see the produced html code) is calculated dynamically and is added to the instruction:<span class=”tribe-events-event-image” style=”background-image: url(‘<?php echo $url; ?>’); -webkit-background-size: <?php echo Avada()->settings->get( ‘ec_bg_list_view’ ); ?>; background-size: <?php echo Avada()->settings->get( ‘ec_bg_list_view’ ); ?>; background-position: center center;”></span>
So, the height parameter appears after the … background-position: center center; . And this “height-calculation” comes somehow from an js of Avada, I guess.
But anyway, maybe you can support this case as much as possible from the Tribe team.
Best regards
Uwe
