[vladtheinhaler]

Hi, I’ve enabled both wp_debug and wp_debug_log but have no experience with them, so I’m not sure what to look for. I tried these things but don’t notice anything that seems relevant:

– enabled both debug/log functions above
– looked on the front end and in the admin controls for any alerts or messages
– went to the Event Calendar page and clicked the “Export Events” button, and looked for any alerts or messages onscreen. . . didn’t see any
– looked in the /wp-content/ directory for a debug.log file and didn’t see one

Is there anything I’m missing here, or does the lack of onscreen errors and/or log file mean there are no warnings to report?

[vladtheinhaler]

This reply is private.

[vladtheinhaler]

I’ve tried all that you’ve suggested above, and the issue persists. Here’s a link to the staging site so you can see for yourself:

https://staging1.region1hmcc.org/region1hmcc-event-calendar/

Note that there is one plugin active on this staging site that’s not a Tribe/EC plugin: but it’s just a tool that connects to the SiteGround server that allows me to clear cached files without having to log into cPanel. FWIW I even disabled this one before sending this reply, but just to avoid confusion, I’m noting that I have reactivated this one, which for obvious reasons, seems like a low-risk plugin for the issue we’re talking about.

[vladtheinhaler]

This reply is private.

[vladtheinhaler]

Update: I have created a staging site and disabled a) the custom theme and reverted to 2017 and b) all plugins except EC, EC Pro, and EC Community. The problem persists. Just wanted to clarify that because I don’t think I checked the appropriate boxes when I submitted the ticket. . .

[vladtheinhaler]

STOP THE PRESSES, this issue is solved. The site was running on a preview URL (since it’s a redesign of a site that’s already up and running) so it wasn’t using any of SiteGround’s server-side caching and other speed-boosting goodies. Early this morning when traffic would be low, I did a test go-live using Cloudflare DNS so I could switch back and forth with minimal propagation delays. Turns out, just switching to the “real” domain so I could take advantage of server-side caching made the load times drop from 6.5 seconds to < 2 seconds!

I’ve never seen so much improvemment between a dev site and a live site at the real domain on SG before, but this has really made me a believer in their SuperCacher. Anyway, thanks for your suggestions above, and sorry for the needless posts on this issue. . . case closed.

[vladtheinhaler]

Just had two thoughts that seemed worth adding to the mix:

1. I remembered Query Monitor was running, and once I turned it off, the site was back to its normal 6.5 second loading time from when I first opened the ticket. The extra time seems to have been due to QM, so no new worries there.

2. I slightly misstated one possibly important thing in an earlier post: I get a 3-3.5 second Home page load when the EC/EC Pro plugins are entirely deactivated, not just by removing the widget from the Home page. If I just remove the widget, times are still long, but not quite as long as if the element is present, maybe a 1 second savings or so.

Don’t know if either of these nuances is important, but just trying to make sure you have all available information.

[vladtheinhaler]

Hi, I just:

1. updated both plugins
2. cleared the SG Optimzer (server level cache) and Cloudflare cache
3. unchecked the Month View cache for EC, saved, rechecked, resaved

Home page now loads in 7.5 seconds, slightly slower than when I did the above :/

[vladtheinhaler]

I finally had a chance to install QM and see that it gives me a vast amount of output, so I’m not clear exactly what diagnostics you’d find useful. A good place to start: QM does identify one Slow Query, which it associates with Events Calendar, and here’s a dump of all the output about that, below. I’ve also attached a screen grab of the Slow Query info summary itself, just to make sure I’m looking in the right place. If I’m understanding this correctly, the slow query is only adding 0.0919 seconds, which would hardly explain the 3-4 second page load difference I’m observing with EC active, but it’s the only info I see that seems relevant.

And now, the log:

Query Monitor
Settings
Pin Panel Open
Close Panel
Overview
Slow Queries (1)
Queries
Queries by Caller
Queries by Component
Duplicate Queries (95)
Request
Template
Scripts
Styles
Hooks & Actions
Languages
HTTP API Calls (1)
Transient Updates
Capability Checks
Environment
Conditionals
Query Caller Component Rows Time
SELECT option_name, option_value
FROM wp_wrightoptions
WHERE autoload = ‘yes’
–
wpex_get_template_part()
wp-content/themes/Total/framework/template-parts.php:121
get_template_part(‘partials/page-single-layout’,”)
wp-includes/general-template.php:155
locate_template()
wp-includes/template.php:647
load_template(‘wp-content/themes/Total/partials/page-single-layout.php’)
wp-includes/template.php:690
get_template_part(‘partials/page-single-content’)
wp-includes/general-template.php:155
locate_template()
wp-includes/template.php:647
load_template(‘wp-content/themes/Total/partials/page-single-content.php’)
wp-includes/template.php:690
the_content()
wp-includes/post-template.php:240
apply_filters(‘the_content’)
wp-includes/plugin.php:203
do_shortcode()
wp-includes/shortcodes.php:197
preg_replace_callback()
wp-includes/shortcodes.php:319
do_shortcode_tag()
wp-includes/shortcodes.php:319
vc_do_shortcode()
wp-content/plugins/js_composer/include/helpers/helpers.php:1311
WPBakeryShortCode->output()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:570
WPBakeryShortCode_VC_Row->content()
wp-content/plugins/js_composer/include/classes/shortcodes/vc-row.php:35
WPBakeryShortCode->loadTemplate()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:478
wpb_js_remove_wpautop()
wp-content/plugins/js_composer/include/helpers/helpers.php:236
do_shortcode()
wp-includes/shortcodes.php:197
preg_replace_callback()
wp-includes/shortcodes.php:319
do_shortcode_tag()
wp-includes/shortcodes.php:319
vc_do_shortcode()
wp-content/plugins/js_composer/include/helpers/helpers.php:1311
WPBakeryShortCode->output()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:570
WPBakeryShortCode->content()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:458
WPBakeryShortCode->loadTemplate()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:478
wpb_js_remove_wpautop()
wp-content/plugins/js_composer/include/helpers/helpers.php:236
do_shortcode()
wp-includes/shortcodes.php:197
preg_replace_callback()
wp-includes/shortcodes.php:319
do_shortcode_tag()
wp-includes/shortcodes.php:319
vc_do_shortcode()
wp-content/plugins/js_composer/include/helpers/helpers.php:1311
WPBakeryShortCode->output()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:570
WPBakeryShortCode->content()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:458
WPBakeryShortCode->loadTemplate()
wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:478
dynamic_sidebar(‘pages_sidebar’)
wp-includes/widgets.php:743
WP_Widget->display_callback()
wp-includes/class-wp-widget.php:372
Tribe__Events__Pro__Mini_Calendar_Widget->widget()
wp-content/plugins/events-calendar-pro/src/Tribe/Mini_Calendar_Widget.php:47
Tribe__Events__Pro__Mini_Calendar->do_calendar()
wp-content/plugins/events-calendar-pro/src/Tribe/Mini_Calendar.php:194
tribe_get_template_part()
wp-content/plugins/the-events-calendar/src/functions/template-tags/general.php:151
tribe_show_month()
wp-content/plugins/the-events-calendar/src/functions/template-tags/month.php:42
Tribe__Events__Template__Month->setup_view()
wp-content/plugins/the-events-calendar/src/Tribe/Template/Month.php:891
Tribe__Events__Template__Month->get_daily_events()
wp-content/plugins/the-events-calendar/src/Tribe/Template/Month.php:827
Tribe__Events__Template__Month->get_cutoff_details()
wp-content/plugins/the-events-calendar/src/Tribe/Template/Month.php:690
tribe_end_of_day()
wp-content/plugins/the-events-calendar/common/src/functions/template-tags/date.php:113
tribe_get_option()
wp-content/plugins/the-events-calendar/common/src/functions/template-tags/general.php:29
Tribe__Settings_Manager::get_option()
wp-content/plugins/the-events-calendar/common/src/Tribe/Settings_Manager.php:86
Tribe__Settings_Manager::get_options()
wp-content/plugins/the-events-calendar/common/src/Tribe/Settings_Manager.php:66
get_option()
wp-includes/option.php:90
wp_load_alloptions()
wp-includes/option.php:197
Plugin: the-events-calendar 427 0.0919

[vladtheinhaler]

Yes, if I remove the Events widget on my site’s home page, the page loading time drops from about 6.5-7.5 seconds to 3-3.5 seconds. The 3-3.5 second range is about what I’ve seen on *many* sites using the same WordPress config (core, theme, plugins) but without The Events Calendar, so if I remove the calendar widget from the sidebar and make no other changes whatsoever, the page loads about as fast as I’d expect.

I have to run at the moment so can’t install Query Monitor right now, but I’ll try that tomorrow and see if it provides any insights.

[vladtheinhaler]

Two things to add:

– this is a cross-post with the free WordPress community forum. . . didn’t realize that my purchase of two premium add-ons entitled me to Premium, so I posted there first, but was relieved to find out I could post here as well. Okay to close or delete the post in the other forum, or whatever you want, once it’s resolved here!

– this project is close to go-live, so I’m in a hurry (of course) so if this convo goes on for more than a round or two (with 24-48 hours between rounds) the client will be distressed. anything you can suggest to cut to the chase and/or condense rounds of tests/questions into fewer messages would be greatly appreciated.

[Author]

Posts