Search: avoid registering the widget when the module is not active

[jeherve]

Fixes #21587

Changes proposed in this Pull Request:

The Jetpack_Search class will not be loaded if the Search module is not active. So let's not register the widget when the feature is not available.

Jetpack product discussion

• N/A

Does this pull request change what data or activity we track or use?

• No

Testing instructions:

• On a site connected to WordPress.com, where you have a plan but where the Search module is inactive.
• Go to Jetpack > Settings and enable Extra Sidebar Widgets
• Go to Appearance > Widgets
• You should not see any errors.
• Activate the Search feature.
• You should be able to use the Jetpack Search Widget.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello jeherve! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D69277-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: December 7, 2021.
• Scheduled code freeze: November 30, 2021.

[gibrown]

FYI, this was intentional for classic search so that the user could activate search by just adding the widget. But I think with instant search it is no longer needed.

[kangzj]

Hi @jeherve Thanks for the PR. The logic look fine - but when I tested on this branch and master, both worked. That is to say, when I disabled search module, on both branches the Search (Jetpack) widget became unavailable. When I looked further, it seemed the file widgets/search.php is not loaded when search module is disabled. But I haven't looked the mechanism yet. Any idea? Thanks.

[jeherve]

when I disabled search module, on both branches the Search (Jetpack) widget became unavailable.

Hm, that is an odd one. I've only tested this using the test site in p8oabR-K9-p2#comment-5572 so I do not really have more details I'm afraid.

[samiff]

I was able to see the fatal Jeremy had mentioned with the search module deactivated:

[24-Nov-2021 18:37:59 UTC] PHP Fatal error:  Uncaught Error: Class 'Jetpack_Search' not found in /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/modules/widgets/search.php:428
Stack trace:
#0 /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/modules/widgets/search.php(301): Jetpack_Search_Widget->widget_instant()
#1 /var/www/html/wp-includes/widgets.php(1224): Jetpack_Search_Widget->widget()
#2 /var/www/html/wp-includes/rest-api/endpoints/class-wp-rest-widget-types-controller.php(520): the_widget()
#3 /var/www/html/wp-includes/rest-api/endpoints/class-wp-rest-widget-types-controller.php(490): WP_REST_Widget_Types_Controller->get_widget_preview()
#4 /var/www/html/wp-includes/rest-api/class-wp-rest-server.php(1140): WP_REST_Widget_Types_Controller->encode_form_data()
#5 /var/www/html/wp-includes/rest-api/class-wp-rest-server.php(987): WP_REST_Server->respond_to_request()
#6 /var/www/html/wp-includes/rest-api/class-wp-rest-server.php(414): WP_REST_Server->dispatch()
#7 /var/www/html/wp-includes/rest-api.php(370): WP_REST_Server->serve_request()
#8 /var/www/html/wp-includes/class-wp-hook.php(303): rest_api_loaded()
#9 /var/www/html/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters()
#10 /var/www/html/wp-includes/plugin.php(518): WP_Hook->do_action()
#11 /var/www/html/wp-includes/class-wp.php(388): do_action_ref_array()
#12 /var/www/html/wp-includes/class-wp.php(750): WP->parse_request()
#13 /var/www/html/wp-includes/functions.php(1291): WP->main()
#14 /var/www/html/wp-blog-header.php(16): wp()
#15 /var/www/html/index.php(17): require('/var/www/html/w...')
#16 {main}
  thrown in /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/modules/widgets/search.php on line 428

With this PR patched, the fatal is fixed.

When I looked further, it seemed the file widgets/search.php is not loaded when search module is disabled.

If the search module is deactivated, then jetpack/modules/search.php (the module index file) won't load which is to be expected. However, with Extra Sidebar Widgets active, then the jetpack/modules/widgets/search.php file is being included, which has that jetpack_search_widget_init() call outside its main class.

jetpack/projects/plugins/jetpack/modules/widgets.php

Lines 14 to 33 in 5e20900

	function jetpack_load_widgets() {
	$widgets_include = array();
	foreach ( Jetpack::glob_php( dirname( __FILE__ ) . '/widgets' ) as $file ) {
	$widgets_include[] = $file;
	}
	/**
	* Modify which Jetpack Widgets to register.
	*
	* @module widgets
	*
	* @since 2.2.1
	*
	* @param array $widgets_include An array of widgets to be registered.
	*/
	$widgets_include = apply_filters( 'jetpack_widgets_to_include', $widgets_include );
	foreach( $widgets_include as $include ) {
	include_once $include;
	}

I also did a check with all of the modules deactivated, but didn't see any other PHP errors when editing widgets, just some JS notices of block registration failures do to missing modules.

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D69277-code, and commit it.
Once you've done so, come back to this PR and add a comment with your changeset ID.

Thank you!

[samiff]

r235602-wpcom

[kangzj]

@samiff Thanks for looking into this, really appreciate that 👍