Local development: jetpack-10.6/3rd-party/debug-bar/class-jetpack-search-debug-bar.php

[jonathanstegall]

Expected/Desired Behavior

I'd expect to be able to run this repository locally, as is generally the case. I should also be able to run the debug bar.

Actual Behavior

As of today, presumably with the release of Jetpack 10.6, I'm getting a fatal error on all local page loads, and I can't run the debug bar.

This screenshot shows the error that sits where the debug bar normally is. My logs look like this:

[10-Feb-2022 19:14:19 UTC] PHP Fatal error:  Uncaught Error: Call to a member function get_last_query_info() on null in /Users/jonathanstegall/Sites/minnpost-wordpress/wp-content/mu-plugins/jetpack-10.6/3rd-party/debug-bar/class-jetpack-search-debug-bar.php:101
Stack trace:
#0 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-content/mu-plugins/debug-bar/debug-bar.php(370): Jetpack_Search_Debug_Bar->render()
#1 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-includes/class-wp-hook.php(307): Debug_Bar->render('')
#2 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array)
#3 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-includes/plugin.php(474): WP_Hook->do_action(Array)
#4 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-includes/general-template.php(3058): do_action('wp_footer')
#5 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-content/themes/minnpost-largo/footer.php(68): wp_footer()
#6 /Users/jonathanstegall/Sites/minnpost-wordpress/wp-includes/template.php(770): require_on in /Users/jonathanstegall/Sites/minnpost-wordpress/wp-content/mu-plugins/jetpack-10.6/3rd-party/debug-bar/class-jetpack-search-debug-bar.php on line 101

Steps to Reproduce the Problem

1. Update this repository.
2. Try to run a page.

[rinatkhaziev]

@jonathanstegall we're unable to reproduce neither locally nor on production currently, do you mind sharing the output of wp jetpack module list?

[jesse-greathouse]

@jonathanstegall thank you for reporting this to us. Im particularly interested in your use of this plugin and I want to support it as best as I can.

I'd expect to be able to run this repository locally, as is generally the case. I should also be able to run the debug bar.

I absolutely agree. I just want to understand how you're running this plugin locally, so we can be sure that we haven't accidentally excluded your use-case with a recent update.

The better I can understand how you're running this plugin locally, will assist how I frame the troubleshooting and support.

[jonathanstegall]

Sure, here's the output of wp jetpack module list:

+-----------------------+----------+
| slug                  | status   |
+-----------------------+----------+
| carousel              | Inactive |
| comment-likes         | Inactive |
| comments              | Inactive |
| contact-form          | Inactive |
| copy-post             | Inactive |
| custom-content-types  | Inactive |
| custom-css            | Inactive |
| enhanced-distribution | Inactive |
| google-analytics      | Inactive |
| gravatar-hovercards   | Inactive |
| infinite-scroll       | Inactive |
| json-api              | Active   |
| latex                 | Inactive |
| lazy-images           | Active   |
| likes                 | Inactive |
| markdown              | Inactive |
| masterbar             | Inactive |
| monitor               | Active   |
| notes                 | Inactive |
| post-by-email         | Inactive |
| publicize             | Inactive |
| related-posts         | Active   |
| search                | Active   |
| seo-tools             | Inactive |
| sharedaddy            | Inactive |
| shortcodes            | Inactive |
| shortlinks            | Inactive |
| sitemaps              | Inactive |
| sso                   | Active   |
| stats                 | Active   |
| subscriptions         | Inactive |
| tiled-gallery         | Inactive |
| verification-tools    | Inactive |
| videopress            | Inactive |
| widget-visibility     | Inactive |
| widgets               | Inactive |
| woocommerce-analytics | Active   |
| wordads               | Inactive |

[rinatkhaziev]

@jonathanstegall by what means did you get search module activated locally in the offline mode?

[rinatkhaziev]

@jonathanstegall can you provide more details on your setup? We have several eyes on this but nobody can reproduce

[rinatkhaziev]

For the time being you have two options to address this: 1) either disable the search module, in that case the Jetpack Search Debug Bar panel won't get loaded or 2) Pin the version locally to 10.5 as described in the docs https://docs.wpvip.com/how-tos/test-jetpack-on-vip-go/#h-pinning-to-a-version

[jonathanstegall]

@rinatkhaziev hm I'm assuming that search was activated by downloading a backup of the site's database? I don't really change it from the import. I don't think I have any code activating it apart from the data backup, at least not that I know of.

[rinatkhaziev]

@jonathanstegall I scoured the main repo and did find the place where the filter adds the version but it's gated by if ( 'local' !== VIP_GO_ENV ) {, I'm assuming this is set up correctly on your end, so the import theory sounds plausibly.

wp jetpack module deactivate search should, hopefully, do the trick.

Keep in mind, that once you disable the module it's likely you won't be able to activate it via CLI command as it would error:

wp jetpack module activate search
Error: Search could not be activated.

[jonathanstegall]

@rinatkhaziev running wp jetpack module deactivate search does work for me, yes. That is, I don't see anymore errors in my logs, and the local page loads work as they should. Do you think I'll need to run this whenever I download a new copy of the site's database? It's not super often that I do that, so it's not a huge deal, but definitely something to document.

[jesse-greathouse]

Hi, @jonathanstegall. Unfortunately the plugin configuration is in the database tables so this will have to be addressed when you do a local refresh of your live site data.

[rinatkhaziev]

@jonathanstegall you can use the same approach with the filter by explicitly removing search from there when VIP_GO_ENV === 'local', this way the filter will override the option. The block I'm talking about is in the main repository at client-mu-plugins/plugin-loader.php#L100-L108

Something like this should prevent you from trouble:

add_filter( 'jetpack_active_modules', function( $modules ) {
    foreach( $modules as $i => $m ) {
        if ( 'search' === $m ) {
            unset( $modules[ $i ] );
        }
    }
    return $modules;
} );

We found the solution and it's going to be included in the next Jetpack release.

Thanks for reporting!

[rinatkhaziev]

@jonathanstegall is this still an issue on the latest version Jetpack?

[jonathanstegall]

@rinatkhaziev thank you for asking! I've definitely stopped using the pinned Jetpack version without any issue. I've also just run the wp jetpack module list and here is the output:

+-----------------------+----------+
| slug                  | status   |
+-----------------------+----------+
| carousel              | Inactive |
| comment-likes         | Inactive |
| comments              | Inactive |
| contact-form          | Inactive |
| copy-post             | Inactive |
| custom-content-types  | Inactive |
| custom-css            | Inactive |
| enhanced-distribution | Inactive |
| google-analytics      | Inactive |
| google-fonts          | Inactive |
| gravatar-hovercards   | Inactive |
| infinite-scroll       | Inactive |
| json-api              | Active   |
| latex                 | Inactive |
| lazy-images           | Active   |
| likes                 | Inactive |
| markdown              | Inactive |
| masterbar             | Inactive |
| monitor               | Active   |
| notes                 | Active   |
| post-by-email         | Inactive |
| publicize             | Inactive |
| related-posts         | Inactive |
| search                | Inactive |
| seo-tools             | Inactive |
| sharedaddy            | Inactive |
| shortcodes            | Inactive |
| shortlinks            | Inactive |
| sitemaps              | Inactive |
| sso                   | Active   |
| stats                 | Active   |
| subscriptions         | Inactive |
| tiled-gallery         | Inactive |
| verification-tools    | Inactive |
| videopress            | Inactive |
| waf                   | Inactive |
| widget-visibility     | Inactive |
| widgets               | Inactive |
| woocommerce-analytics | Active   |
| wordads               | Inactive |
+-----------------------+----------+

I'm realizing, though, that since we were originally discussing this we started using Enterprise Search, both locally and remotely. So I'm not sure if I'm still in a place where the issue would show up for me, if it does exist.

I do currently use these filters in plugin-loader.php, as well:

// make sure to remove search and related post modules.
add_filter(
    'jetpack_active_modules',
    function( $modules ) {
        foreach ( $modules as $i => $m ) {
            if ( 'search' === $m ) {
                unset( $modules[ $i ] );
            }
            if ( 'related-posts' === $m ) {
                unset( $modules[ $i ] );
            }
        }
        return $modules;
    }
);

So I'm not sure if that is helpful feedback, but I haven't had any recent issues, in any case.

[github-actions[bot]]

This issue has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed.

This is an automation to keep issues manageable and actionable and is not a comment on the quality of this issue nor on the work done so far. Closed issues are still valuable to the project and are available to be searched.