@adrianb – Hmm, except the query you listed there is for Ultimate Member, so it actually may be that they are doing something incorrectly or maybe just not as specifically as they mean to.
IE we load popup conditions to see which popups should be loaded on any page (all cacheable). We do that using standard WP methods for loading pages/post meta, but if UM is looking for a certain event to happen and triggering their query there, then likely they need to look at caching the results for the rest of the page load rather than calling for it over and over.
We are constantly trying to reduce loads & queries, in fact v1.4+ reduced overall queries by half, so I think this is more a combination of how we load popups (the only way really we can until WP API works fully) and them not caching queries.
That said if you enabled something like W3 total cache and turned on Query, Object & Page caching any popup maker hits would disappear after caches were primed.
I just made a note on my todo list to try and duplicate the specific query you mentioned by installing PM & UM and looking over queries and PHP Profiler reports. May be able to track down the issue, no promise that it can be solved from the Popup Maker side though.
I would love to hear any more specifics you found, but I would suggest some type of caching in general for objects & queries as that can greatly increase performance.
Hmm, no I don’t think it has anything to do with Ultimate Member. I do not have that plugin installed. The um is just the table prefix in wp-config.php:
$table_prefix = 'um_';
And yes, a good caching plugin is certainly good for performance, I just assume the many calls by Popup Maker was a bug of sorts.
@adrianb – Gotcha, sorry have ran into several other issues with UM lately, all resolved so far.
I will be running profiler later today again, but tbh I don’t know that I expect to see a huge hit, but will keep a look out for any queries we can nix and any memory leaks.
Any other info you provide may help so keep it coming.
Not much other than each post type gets two identical queries each. For someone with only post, page and attachment post types it probably isn’t that much, but since I have another 14 posts types it adds up.
Here are two screenshots from Query Monitor reporting: http://imgur.com/a/KU5GV
@adrianb – I think I know exactly where the issue is. Our conditions dropdowns are primed with 10 results from each post type, but that should only run on the popup editor page, and since we use AJAX search likely isn’t needed at all. Let me see what I can do with Performance Profiler and Query Monitor over the next few days.
@adrianb – Found found and found. I just spent the last few hours running profiling and query monitoring. Now down to just 5 queries on the average page load, mileage may vary, but that is down from 24 avg, so massive improvment. Also if you have any type of persistant caching your set as I changed several usages of get_posts to use WP_Query which is object cachable, meaning you can likely reduce that by another 3 queries, add page caching and your down to 0.
2 of the queries are in our tracking API framework (optin only, we promise), but those will be addressed in a future update as they need to be patched in the framework itself.
Now not all sites will see this drastic of a reduction, but just to test I created 12 popups and loaded them all on the page. 1 popup or 12 made no difference, still 5 queries (remember 2 don’t count).
This will be in v1.4.9 shortly, if you would like to test for me and confirm I would love the feedback.
@adrianb – I didn’t focus on the admin at all, though I will in the future, but front end fixes seemed imperative.
I can give it a try and compare to 1.4.8, where/how do I get the beta version?
@adrianb – If you can email us (support at wppopupmaker.com) I will send it to you. Our Github repo has build routines that are only run committed during release, so if you grabbed it now none of those would be done without installing NodeJS.
