Project

General

Profile

Actions

Bug #14885

closed

Long Loading Times -- Wordpress Admin Site

Added by Marilyn Weber over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
WordPress Plugins
Target version:
Start date:
2021-10-10
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Via ZD:

"The load times for my Wordpress Admin pages are extremely long. It often takes 30-40 seconds to click between pages. The load time for my public facing site seems fine. But the Wordpress Admin pages in particular are having this issue.

Is this problem unique to my site or something others are also experiencing?

Wordpress Admin --- long load times

https://assessatcuny.commons.gc.cuny.edu/wp-admin/

Public Site – load time fine

https://assessatcuny.commons.gc.cuny.edu/"

Actions #1

Updated by Marilyn Weber over 2 years ago

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?

Actions #2

Updated by Raymond Hoh over 2 years ago

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.

Actions #3

Updated by Raymond Hoh over 2 years ago

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!

Actions #4

Updated by Boone Gorges over 2 years ago

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.

Actions #5

Updated by Raymond Hoh over 2 years ago

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.

Actions #6

Updated by Raymond Hoh over 2 years ago

  • Category name set to WordPress Plugins
  • Status changed from New to Staged for Production Release
  • Assignee set to Raymond Hoh
  • Target version set to 1.18.21

I've added a fix here: https://github.com/cuny-academic-commons/cac/commit/639cab15127c5cff89973a5344a647e7d1753729

I've basically removed Tribulant's cache lookup from their custom get_option() method since that method already calls on WP's get_option() function, which has an object cache built-in.

Actions #7

Updated by Marilyn Weber over 2 years ago

Thank you! Both from me and the user.

Actions #8

Updated by Boone Gorges over 2 years ago

Thanks, Ray!

Actions #9

Updated by Boone Gorges over 2 years ago

  • Target version changed from 1.18.21 to 1.18.22
Actions #10

Updated by Raymond Hoh over 2 years ago

  • Status changed from Staged for Production Release to Resolved

Looks like Tribulant added my suggestion to the latest version of newsletters-lite, which was deployed as part of today's maintenance release, 1.18.21. See https://github.com/cuny-academic-commons/cac/blob/11f95626af01b7fc6ed5bfeb0e9aa6ac1ad28d78/wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php#L10196-L10198.

Going to close this one.

Actions

Also available in: Atom PDF