Query Monitor blames WPForms, but is it normal?

  • Resolved Robin Labadie

    (@robin-labadie)


    2 weeks, 1 day ago

    Hi there,

    I’ve noticed while reporting an issue to WPForms, thanks to Query Monitor, that WPForms was blamed for an error that was actually due to another plugin (TranslatePress). More precisely, it points to ErrorHandler.php from WPForms, while this script didn’t cause the original error.

    Here is an example: 

    Deprecated
    rtrim(): Passing null to parameter #1 ($string) of type string is deprecated    

    wp-includes/formatting.php:2819
        WPForms\ErrorHandler->error_handler()
        wp-content/plugins/wpforms-lite/src/ErrorHandler.php:171
        rtrim()
        wp-includes/formatting.php:2819
        untrailingslashit()
        wp-includes/formatting.php:2804
        trailingslashit()
        wp-content/plugins/translatepress-multilingual/includes/class-url-converter.php:437
        TRP_Url_Converter->get_url_for_language()
        wp-content/plugins/translatepress-multilingual/partials/language-switcher-shortcode.php:22
        TRP_Language_Switcher->language_switcher()
        wp-includes/shortcodes.php:434
        do_shortcode_tag()
        wp-includes/shortcodes.php:434
        preg_replace_callback()
        wp-includes/shortcodes.php:273
        do_shortcode()
        wp-content/plugins/translatepress-multilingual/includes/gutenberg-blocks/ls-shortcode/ls-shortcode.php:142
        TRP_Gutenberg_Blocks->{closure}()
        wp-includes/class-wp-hook.php:324
        do_action('trp/language-switcher/render_callback')
        wp-content/plugins/translatepress-multilingual/includes/gutenberg-blocks/ls-shortcode/ls-shortcode.php:24
        TRP_Gutenberg_Blocks->{closure}()
        wp-includes/class-wp-block.php:519
        WP_Block->render()
        wp-includes/class-wp-block.php:499
        WP_Block->render()
        wp-includes/class-wp-block.php:499
        WP_Block->render()
        wp-includes/class-wp-block.php:499
        WP_Block->render()
        wp-includes/blocks.php:2061
        render_block()
        wp-includes/blocks.php:2113
        do_blocks()
        wp-includes/blocks/template-part.php:154
        render_block_core_template_part()
        wp-includes/class-wp-block.php:519
        WP_Block->render()
        wp-includes/blocks.php:2061
        render_block()
        wp-includes/blocks.php:2113
        do_blocks()
        wp-includes/block-template.php:260
        get_the_block_template_html()
        wp-includes/template-canvas.php:12

    Extension : wpforms-lite

    Upon disabling WPForms, the error becomes:

    Deprecated
    rtrim(): Passing null to parameter #1 ($string) of type string is deprecated	

        wp-includes/formatting.php:2819
        rtrim()
        wp-includes/formatting.php:2819
        untrailingslashit()
        wp-includes/formatting.php:2804
        trailingslashit()
        wp-content/plugins/translatepress-multilingual/includes/class-url-converter.php:437
        TRP_Url_Converter->get_url_for_language()
        wp-content/plugins/translatepress-multilingual/partials/language-switcher-shortcode.php:22
        TRP_Language_Switcher->language_switcher()
        wp-includes/shortcodes.php:434
        do_shortcode_tag()
        wp-includes/shortcodes.php:434
        preg_replace_callback()
        wp-includes/shortcodes.php:273
        do_shortcode()
        wp-content/plugins/translatepress-multilingual/includes/gutenberg-blocks/ls-shortcode/ls-shortcode.php:142
        TRP_Gutenberg_Blocks->{closure}()
        wp-includes/class-wp-hook.php:324
        do_action('trp/language-switcher/render_callback')
        wp-content/plugins/translatepress-multilingual/includes/gutenberg-blocks/ls-shortcode/ls-shortcode.php:24
        TRP_Gutenberg_Blocks->{closure}()
        wp-includes/class-wp-block.php:519
        WP_Block->render()
        wp-includes/class-wp-block.php:499
        WP_Block->render()
        wp-includes/class-wp-block.php:499
        WP_Block->render()
        wp-includes/class-wp-block.php:499
        WP_Block->render()
        wp-includes/blocks.php:2061
        render_block()
        wp-includes/blocks.php:2113
        do_blocks()
        wp-includes/blocks/template-part.php:154
        render_block_core_template_part()
        wp-includes/class-wp-block.php:519
        WP_Block->render()
        wp-includes/blocks.php:2061
        render_block()
        wp-includes/blocks.php:2113
        do_blocks()
        wp-includes/block-template.php:260
        get_the_block_template_html()
        wp-includes/template-canvas.php:12

    	Extension : translatepress-multilingual

    So the WPForms support is interested in knowing your thoughts on the unexpected issue of reporting alerts for a different plugin. I’m interested too!

    Do you think this is an issue with Query Monitor, or an issue with error handling from WPForms?

    The original topic where we discovered this is here: https://www.ads-software.com/support/topic/code-deprecation-may-be-related-to-core-wp/
    You may want to comment out there directly if you have useful insight to provide to WPForms. This is popular plugin, helping them would help the whole community!

    (PS : I’m a long time Query Monitor user, it’s awesome and I keep recommending it all around. Thank you for your work for the WordPress community!

    • This topic was modified 2 weeks, 1 day ago by Robin Labadie. Reason: More details and more synthetic sentences

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author John Blackbourn

    (@johnbillion)

    WordPress Core Developer

    Thanks for the report.

    Detecting exactly which component is responsible for an error (or anything else with a stack trace) is an art rather than a science. A good example is when a theme calls a plugin, or a plugin calls another plugin. Which should get the blame? It may be impossible to determine, especially if unexpected parameters are passed.

    Query Monitor mostly chooses the plugin that’s nearest the top of the stack trace, which is the correct thing to do 99.9% of the time. In your case, QM has no way to know that WP Forms is intercepting the error with its own error handler and therefore adding an item to the stack trace. QM will see this and blame WP Forms. The crux of the problem is that multiple error handlers will always argue with one another to some degree.

    Thread Starter Robin Labadie

    (@robin-labadie)

    Thanks for your quick reply! That’s kind of what I was afraid of (error interception results in kind of a false positive for the interceptor).

    I would tend to think WPForms should maybe find a way to only intercept only its directly related errors. But maybe they have a good reason to proceed as they currently are. Or maybe that was just for the sake of simplicity for their tool’s development.

    I wonder what would be the best approach about this. Maybe a checkbox to enable/disable their error interceptor tool? I’m just a sysadmin, so your insight on this would be more valuable than mine!

    Would you have a suggestion or recommendation to make to WPForms? They seem very interested in improving their script!

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.