Jetpack causing other plugins filters/hooks to flag _doing_it_wrong

*From #2377058-zen

I am not entirely sure this is exactly your problem, but I have at least two
other plugins that are logging warnings when debugging is turned on saying that
they are 'doing it wrong'. I inserted code to create a backtrace, and see that
when this happens it is triggered by Jetpack.

For example, here is one:

```
[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…’,
‘

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(‘

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}
```
The other one is similar, in which their code is being called as a result of the
'language_attributes' being called when outside of the $wp_query.

I am not sure why this is happening, or if you can change your code to unhook or
bypass that filter if you are doing something when $wp_query is not defined?

One of the developers (Temple Invaders) gave me this information:

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

Here was another backtrace that triggered a similar problem in another plugin:

```
[23-Sep-2019 22:10:56 UTC] SCM_DEBUG: Function: is_singular; Version: 3.1.0;
Message: Conditional query tags do not work before the
query is run. Before then, 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_wron
g_run('is_singular', '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_singular', 'Conditional que...',
'3.1.0')
#4 /home/simplych/public_html/wp-includes/query.php(727):
_doing_it_wrong('is_singular', 'Conditional que...', '3.1.0')
#5
/home/simplych/public_html/wp-content/plugins/wpseo-woocommerce/wpseo-woocommerce.php(733):
is_singular('product')
#6 /home/simplych/public_html/wp-includes/class-wp-hook.php(288):
Yoast_WooCommerce_SEO->og_product_namespace('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...',
'

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('

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}
```
Both of them seem to be triggered by the same Jetpack module/function.

In looking further, it seems that you may only be calling language_attributes() for when you output the page.

It is frustrating, though, that this is rippling through and causing these messages in the debug log and there is seemingly no way to get it resolved because it is “nobody’s fault”.

Any thoughts on how to move this forward if it is not something you can address would be helpful. :)

Read modules/protect/blocked-login-page.php and modules/protect.php, focusing on the blocked-login rendering path that calls language_attributes(). Reproduce the blocked-login flow with debugging enabled and inspect the reported backtraces; done means the flow no longer causes unrelated plugins' conditional-query warnings.

Written by the indexing model from the issue text.