CUNY Academic Commons

I do see exactly what he means, and it is not the case on my sites. This seems to be only for this one site - any ideas?

The lag is caused by the Newsletters Lite plugin.

The main offender is the get_fields() call: https://github.com/cuny-academic-commons/cac/blob/de282b6137cde40af1a1d00ef6e41d285f325ee0/wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php#L7095. The second offender is the check_table() call: https://github.com/cuny-academic-commons/cac/blob/de282b6137cde40af1a1d00ef6e41d285f325ee0/wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php#L6964.

Both calls appear to be some part of an update routine. According to the Query Monitor plugin, the first query runs more than 700 times on a pageload, while the second one runs about 200 times. Together, they cause the roughly 50-60 second load time in the admin area.

I need to do some more debugging to see what Newsletters Lite is doing, but perhaps we can suggest switching this site over to an external newsletter alternative as in #11878. I think we were recommending Tinyletter, but not sure if there is an updated ticket about this.

I've fixed the issue.

The NewsLetters Lite plugin uses its own object cache to cache its own options: https://github.com/cuny-academic-commons/cac/blob/de282b6137cde40af1a1d00ef6e41d285f325ee0/wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php#L10178.

During the updating_plugin() method, it checks the saved version against the file version before doing its update routine: https://github.com/cuny-academic-commons/cac/blob/de282b6137cde40af1a1d00ef6e41d285f325ee0/wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php#L10548.

When grabbing the saved version, this value was old and not the same as the value in the DB.

So I purged the cached value with wp_cache_delete( 'version', 'newsletters' ) and this fixed the issue!

Nice sleuthing, Ray!

Did you see any obvious reason why there was a mismatch between the cached value and the value in the database? I realize these things are very hard to debug, but perhaps if there's an obvious fix we could suggest upstream, it would be worthwhile.

Is there any way we can detect this kind of problem in the future? It feels odd that the plugin would rely on a cached value during something like an upgrade routine - maybe we could skip it, and force the plugin to fetch directly from the database? Maybe this is a long shot, and maybe it's a case that won't come up again in the future, but it might be worth a bit of investigation.

It feels odd that the plugin would rely on a cached value during something like an upgrade routine

It's an architectural problem. Their option fetching routine has a cache, so Tribulant needs to purge their cache entry after the upgrade is complete. I took a quick look at their codebase and it looks like they never delete or update any option in their object cache! Crazy!

This means that there could be other issues with the plugin and older, cached values.

I've made a post in their support forum here and Tribulant says they are looking into it.

In the meantime, I can probably patch newsletters-lite so their options object cache is properly updated and deleted when needed.

Thank you! Both from me and the user.

Thanks, Ray!