is_page was called incorrectly

  • Resolved scmsteve

    (@scmsteve)


    5 years, 4 months ago

    With debugging logging turned on, I am seeing these messages:

    PHP Notice: is_page was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.0.) in /home/webuser/public_html/wp-includes/functions.php on line 4773

    Inserting some debugging there to print a backtrace points to your plugin:

    Backtrace: #0 /home/webuser/public_html/wp-includes/query.php(570): _doing_it_wrong(‘is_page’, ‘Conditional que…’, ‘(This message w…’)
    #1 /home/webuser/public_html/wp-content/plugins/ti-woocommerce-wishlist-premium/public/tinvwl.class.php(469): is_page(1260564)
    #2 /home/webuser/public_html/wp-includes/class-wp-hook.php(288): TInvWL_Public_TInvWL->add_ogp(‘lang=”en-US”‘)
    #3 /home/webuser/public_html/wp-includes/plugin.php(208): WP_Hook->apply_filters(‘lang=”en-US”‘, Array)
    #4 /home/webuser/public_html/wp-includes/general-template.php(3836): apply_filters(‘language_attrib…’, ‘lang=”en-US”‘, ‘html’)
    #5 /home/webuser/public_html/wp-includes/general-template.php(3851): get_language_attributes(‘html’)

    I didn’t include the entire backtrace to save space, hopefully that is enough.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter scmsteve

    (@scmsteve)

    5 years, 4 months ago

    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.

    Plugin Author templateinvaders

    (@templateinvaders)

    5 years, 4 months ago

    Hi @scmsteve

    We checked the mentioned code and can’t reproduce the same notice.

    Our method hooked into ‘language_attributes’ filter and the query already set on that moment in default WordPress setup. Language attributes method designed to use in templates which always loaded after the query processed (https://codex.wordpress.org/Query_Overview). It means that the query wiped before this filter for some reason on your WordPress setup.

    You can send us access to the staging setup with this issue if you need help with debugging!

    P.S. We see that you got the same issue with another plugin and it looks like you need to check all code that hooked to pre_get_posts on first look.

    Kind regards.

    Thread Starter scmsteve

    (@scmsteve)

    5 years, 4 months ago

    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, 4 months ago by scmsteve.
    Thread Starter scmsteve

    (@scmsteve)

    5 years, 4 months ago

    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. 🙂

    Plugin Author templateinvaders

    (@templateinvaders)

    5 years, 4 months ago

    Hi @scmsteve

    We’ll add an extra condition in an upcoming update but you see that it’s a wrong way to fix this issue.

    Conditional query tags already have the same condition that runs doing_it_wrong_trigger_error.

    Jetpack forcing display custom HTML for the login page and using the mentioned method in the markup when the query still not set or already wiped for some security reason.

    Kind regards.

    Thread Starter scmsteve

    (@scmsteve)

    5 years, 4 months ago

    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, 4 months ago by scmsteve.
    Plugin Author templateinvaders

    (@templateinvaders)

    5 years, 3 months ago

    Hi @scmsteve

    The extra condition added in the latest update.

    Thanks!

    jnnfx

    (@jannnfe)

    5 years, 3 months ago

    Have this Error, deleting Products from the wishlist

    Die Website weist technische Schwierigkeiten auf.

Fatal error: Uncaught Error: Call to a member function get_title() on null in /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-content/plugins/ti-woocommerce-wishlist/public/wishlist/view.class.php:494
Stack trace:
#0 /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-content/plugins/ti-woocommerce-wishlist/public/wishlist/view.class.php(365): TInvWL_Public_Wishlist_View->wishlist_actions(Array, true)
#1 /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-includes/class-wp-hook.php(286): TInvWL_Public_Wishlist_View->wishlist_action(Object(WP))
#2 /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#3 /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-includes/plugin.php(531): WP_Hook->do_action(Array)
#4 /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-includes/class-wp.php(750): do_action_ref_array('wp', Array)
#5 /mnt/data/home/315135.cloudwaysapps.com/zfpzweauq in /mnt/data/home/315135.cloudwaysapps.com/zfpzweauqu/public_html/wp-content/plugins/ti-woocommerce-wishlist/public/wishlist/view.class.php on line 494
    Degas

    (@degas)

    5 years, 3 months ago

    I have the delete issue using the product-remove button, but Actions > Remove works fine

    Plugin Author templateinvaders

    (@templateinvaders)

    5 years, 3 months ago

    Hi @jannnfe and @degas

    This issue fixed in the latest release.

    Thanks for the reports.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘is_page was called incorrectly’ is closed to new replies.