search

Automattic / jetpack

Security, performance, marketing, and design tools — Jetpack is made by WordPress experts to make WP sites safer and faster, and help you grow your traffic.
https://jetpack.com/
Other
1.59k stars 798 forks source link

Jetpack causing other plugins filters/hooks to flag _doing_it_wrong #13536

Open chickenn00dle opened 5 years ago

chickenn00dle commented 5 years ago

*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…’,
‘<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}

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...',
'<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}

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

kraftbj commented 5 years ago

This is a bit frustrating because, as the OP mentioned, it isn't anyone's fault. These plugins are hooking into the attributes assuming it will be during page generation, which is normally safe for conditionals since the query is done.

In our case, we run it for a blocked login page so there is no query. I suppose we could mock up a query or investigate if there is an alternative for the same use, or be very opinionated and remove filters?

stale[bot] commented 4 years ago

This issue has been marked as stale. This happened because:

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.