scmsteve

Excellent points. We have JetPack running with security scans, so I don’t think malware is the issue, although if you had a different recommendation for a scanner I wouldn’t mind giving it a shot. I’ll keep digging, thanks.

But isn’t that RAM usage just the max PHP allocated memory for that ONE page load/invocation? And for the instance of doing a plugin update (one or more plugins doesn’t matter), it is repeatable every time I update a plugin, even when most of the time the loading of the page to do the update is only around 40MB, the ‘inner’ page with the list of plugins that got updated shows 180MB. This one time I saw higher RAM usage on the first page was an exception. I’m not saying there couldn’t be bots/etc hitting it, although we are running protection against them and litespeed real-time stats isn’t showing that it is being hit very much at all. As for malware, I would think if it were due to a plugin/etc that it got into the site, it would have transferred to the test site as well. Perplexing for sure.

Thanks so much for the thoughts. There are only few plugins that are not enabled on the test site, but I temporarily disabled them on the live site and it didn’t make a difference. They are also using the same theme.

Yes, we have OPcache turned on.

This one is a puzzle, as the live and test site and nearly identical, and I cannot duplicate this on that site (or in a separate docker instance I run at home of the same site). And another host running on that same hosted system on a different cpanel account has no issues.

Hopefully it will turn up eventually.

NOTE: Just loaded the ‘Installed Plugins’ page… 987 queries, 57.65seconds, 180MB of RAM. Really? {sigh} . But it isn’t that high every time which is also puzzling.

• This reply was modified 5 years, 5 months ago by scmsteve.

By the way, I’ve tried debug bar, debug objects, etc, but they aren’t helping. For example, the most repeatable test, updating a plugin, has the intial admin page load which is not high in memory usage, and that is what debug objects catches, but then it provdes the output of the actual update in an iframe I believe, but that is not caught by debug objects so I can’t see what memory usage was. usageDD does show here, but has no breakdown.

As i say, I’ve done the plugin/theme dance, and it seems irrelevant in this case because the test site, which is a duplicate of all the same code/etc, is not having this problem. That is why I am looking for something deeper than the usual things. Hosting plans with more memmory/etc have nothing to do with how much RAM wordpress is using to do a plugin update, for example. Nor should caching, although we do have caching.

The bottom line, I’m not looking for standard ‘performance optimization’ boilerplate, I’m looking to find a way to get wedged into WordPress in some way as to find out what is consuming so much RAM.

I wish I could help, but on one of the sites I work with the wp cli command is missing, even though the plugin is installed and active, but yet it works on the other sites, even a test copy of this site. Very strange.

Seems the WP_CLI environment variable is not getting set for some reason so the plugin isn’t adding the command. A few other plugins have the same issue, troubleshooting our wp-cli install now.

• This reply was modified 5 years, 5 months ago by scmsteve.

How does one fix this problem then? ??

I will say the same thing I said to the other developers, though… And, as a side note, your plugin is causing a considerably larger number of these messages than the other plugins just because it is called much more frequently. The other ones are called by JetPack’s protect module when it blocks a login, yours is being called by the WooCommerce Memberships plugin on a much more frequent basis.

Yes, WordPress calls doing_it_wrong to tell you that you shouldn’t be calling them in such a case. I believe you should be checking first for sanity, that WordPress warning is only there to tell you that you haven’t done that. If all things are written properly, that warning should never happen. It should not be normal that a debug log is getting a lot of those warnings if all the code is written to watch for proper use, but we can agree to disagree on that point. That is sort of like saying that PHP will complain if you call a method on a null object. Yes, it will, but with bad side effects and a much harsher result. That is why you should check for yourself before letting that happen. ??

In this case, it is WooCommerce memberships perhaps doing something that is forcing those action/filter calls in a time when nobody else is expecting them to happen. But I would contend that if you are hooking into an action or filter, it is up to you to ensure a sane state of conditions when you then act. People just have WP_DEBUG off by default and/or are not paying attention, so they don’t see this. Plus, the default logging will not tell you why it is happening because it provides no backtrace. That frustrated me for quite a while before I was motivated to find which plugins were doing it.

I am not trying to cause a problem, I was simply trying to report that the code was causing an warning message. As I said, I found that I can disable them from our logs and just pretend that everything is right in the world. ??

Yes, WordPress calls doing_it_wrong to tell you that you shouldn’t be calling them in such a case. I believe you should be checking first for sanity, that WordPress warning is only there to tell you that you haven’t done that. If all things are written properly, that warning should never happen. It should not be normal that a debug log is getting a lot of those warnings if all the code is written to watch for proper use, but we can agree to disagree on that point. That is sort of like saying that PHP will complain if you call a method on a null object. Yes, it will, but with bad side effects and a much harsher result. That is why you should check for yourself before letting that happen. ??

In this case, it is JetPack perhaps doing something that is forcing those action/filter calls in a time when nobody else is expecting them to happen. But I would contend that if you are hooking into an action or filter, it is up to you to ensure a sane state of conditions when you then act. JetPack is not a small or little-used plugin, so it seems that our site is not the only one affected, people just have WP_DEBUG off by default and/or are not paying attention. Plus, the default logging will not tell you why it is happening because it provides no backtrace.

I am not trying to cause a problem, I was simply trying to report that the code was causing an warning. As I said, I found that I can disable them from our logs and just pretend that everything is right in the world. ??

• This reply was modified 5 years, 6 months ago by scmsteve.

Or, as another approach, maybe I can just hook into the ‘doing_it_wrong_trigger_error’ filter and have it not log them at all since I can’t fix them. ??

I have reported a similar issue to some other plugins, but they are being triggered by something JetPack is doing. This one seems to be triggered by something WooCommerce Memberships is doing if you follow the backtrace. So if you don’t have that installed you probably won’t duplicate the problem.

Or, as another approach, maybe I can just hook into the ‘doing_it_wrong_trigger_error’ filter and have it not log them at all since I can’t fix them. ??

• This reply was modified 5 years, 6 months ago by scmsteve.

Complete backtrace shows that the call in this particular instance was initiated by something in JetPack that triggered the filter/action you are hooked into at a time when it isn’t appropriate to call is_page().

[23-Sep-2019 22:10:56 UTC] SCM_DEBUG: Function: is_page; Version: 3.1.0; Message: Conditional query tags do not work before the query is run. Before t
hen, they always return false.
[23-Sep-2019 22:10:56 UTC] SCM_DEBUG: Backtrace: #0 /home/simplych/public_html/wp-includes/class-wp-hook.php(286): scm_doing_it_wrong_run(‘is_page’, ‘
Conditional que…’, ‘3.1.0’)
#1 /home/simplych/public_html/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(”, Array)
#2 /home/simplych/public_html/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
#3 /home/simplych/public_html/wp-includes/functions.php(4746): do_action(‘doing_it_wrong_…’, ‘is_page’, ‘Conditional que…’, ‘3.1.0’)
#4 /home/simplych/public_html/wp-includes/query.php(570): _doing_it_wrong(‘is_page’, ‘Conditional que…’, ‘3.1.0’)
#5 /home/simplych/public_html/wp-content/plugins/ti-woocommerce-wishlist-premium/public/tinvwl.class.php(469): is_page(1260564)
#6 /home/simplych/public_html/wp-includes/class-wp-hook.php(288): TInvWL_Public_TInvWL->add_ogp(‘lang=”en-US”‘)
#7 /home/simplych/public_html/wp-includes/plugin.php(208): WP_Hook->apply_filters(‘lang=”en-US”‘, Array)
#8 /home/simplych/public_html/wp-includes/general-template.php(3836): apply_filters(‘language_attrib…’, ‘lang=”en-US”‘, ‘html’)
#9 /home/simplych/public_html/wp-includes/general-template.php(3851): get_language_attributes(‘html’)
#10 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect/blocked-login-page.php(344): language_attributes()
#11 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect/blocked-login-page.php(285): Jetpack_Protect_Blocked_Login_Page->display_page(‘Jetpack has loc…’, ‘<p><p>Your IP a…’, NULL, true)
#12 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect/blocked-login-page.php(291): Jetpack_Protect_Blocked_Login_Page->protect_die(‘<p><p>Your IP a…’, ‘Jetpack has loc…’, NULL, true)
#13 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect/blocked-login-page.php(213): Jetpack_Protect_Blocked_Login_Page->render_recovery_form()
#14 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect.php(637): Jetpack_Protect_Blocked_Login_Page->render_and_die()
#15 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect.php(496): Jetpack_Protect_Module->kill_login()
#16 /home/simplych/public_html/wp-content/plugins/jetpack/modules/protect.php(906): Jetpack_Protect_Module->check_login_ability()
#17 /home/simplych/public_html/wp-content/plugins/jetpack/class.jetpack.php(1871): include_once(‘/home/simplych/…’)
#18 /home/simplych/public_html/wp-includes/class-wp-hook.php(286): Jetpack::load_modules(”)
#19 /home/simplych/public_html/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#20 /home/simplych/public_html/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
#21 /home/simplych/public_html/wp-settings.php(394): do_action(‘plugins_loaded’)
#22 /home/simplych/wp-config.php(196): require_once(‘/home/simplych/…’)
#23 /home/simplych/public_html/wp-load.php(42): require_once(‘/home/simplych/…’)
#24 /home/simplych/public_html/wp-login.php(12): require(‘/home/simplych/…’)
#25 {main}

I know that if I modified your plugin code (which I did to test) for all instances where you were using one of those calls, and first tested to be sure the global $wp_query was set, the warnings go away. The same with the other plugins that I have reported to, becuase I am frustrated by having a log filled up with these messages about ‘doing it wrong’. ?? It is also frustrating that everyone points the finger at everything else, it is hard to get problems resolved.

Our test site probably will not reveal this, as we don’t have JetPack fully configured on there so I don’t believe it is calling out the same filters at the same times.

Does the above (complete) backtrace help at all?

UPDATE: I also have sent a message to JetPack about possibly having them change something, as it is the same module of JetPack, the Jetpack_Protect_Module, that is causing the problem here and in the YOAST WP-SEO WooCommerce plugin. The other one I have reported and am working on is with InstantSearch+ and it is not triggered by JetPack, but by WOoCommerce Memberships.

• This reply was modified 5 years, 6 months ago by scmsteve.

It was the latest version as of today when I was testing. I did resolve it locally by doing the check for the global $wp_query being defined when is_search was tested for, but it will of course be overwritten by the next update. The message only shows up when WP_DEBUG is on, but it is quite frequent when it is on, filling up a log file rather quickly and making it hard to find the other things you are looking for.

Just looking through where is_page() is used, maybe adding “global $wp_query” to those functions/methods and then using “isset( $wp_query)” before using is_page() in order to be sure this warning is not printed. Yes, if it fails with false then it won’t hurt your functioning, but it seems that it would do the same after the above changes and would eliminate the warning.

By the way, this seems to be because while $wp_query is passed to you as an argument, which you are checking, the problem is that global $wp_query is not set which is why the “doing it wrong” is being called. So it seems if you tested for the global $wp_query being set before calling is_search() it would fix the problem.

• This reply was modified 5 years, 6 months ago by scmsteve.