WPcom_Admin_Menu: Add special cases that don't have menus extended

[mreishus]

Changes proposed in this Pull Request:

• When visiting /wp-admin?service-worker, do not add any actions to admin_menu, as all the page does is return a static js file. All work is wasted.
  • Requests to this are handled by gutenberg
    https://github.com/WordPress/gutenberg/blob/b54c2d88fa883e47822ce8088de5592ad4bacbf0/lib/pwa.php#L21-L34
• Same with /wp-admin/index-yourstuff.php and /wp-admin/index-hotstuff.php: They do not render menus and end up going through JITM code for ultimately no effect.

For more background info, see p55Cj4-1xc-p2

Jetpack product discussion

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

Testing instructions:

• Visit /wp-admin?service-worker. Before and after the patch, the data returned should be exactly the same.
  • BEFORE: On WPCOM, /wp-admin?service-worker will cause get_top_messages() in jitm-engine.php to run, however, the data will not be used, as there is nowhere to display the messages.
  • AFTER: /wp-admin?service-worker will not cause get_top_messages() in jitm-engine.php to run
• Same with /wp-admin/index-yourstuff.php and /wp-admin/index-hotstuff.php

Logging screenshots before/after

Loading /wp-admin/ on my simple site before changes (JITM rendered 5 times)

Loading /wp-admin/ on my simple site after changes (JITM rendered once)

[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: March 1, 2022.
• Scheduled code freeze: February 22, 2022.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello mreishus! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D74790-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

[mreishus]

Less than ideal: I'm now able to visit /wp-admin/themes.php?service-worker on my simple site, and see the themes page with non-enhanced menus.

The new method used prevents this, as it only checks for ?service-worker on index.php.

[mreishus]

For the PHP 8.1 WP master unit tests, I'm seeing this failure:

  Fatal error: Uncaught Error: Class "Requests_Cookie_Jar" not found in /tmp/wordpress-master/src/wp-includes/class-requests.php:591
  Stack trace:
  #0 /tmp/wordpress-master/src/wp-includes/class-requests.php(365): Requests::set_defaults()
  #1 /tmp/wordpress-master/src/wp-includes/class-wp-http.php(394): Requests::request()
  #2 /tmp/wordpress-master/src/wp-includes/class-wp-http.php(632): WP_Http->request()
  #3 /tmp/wordpress-master/src/wp-includes/http.php(162): WP_Http->get()
  #4 /tmp/wordpress-master/src/wp-content/plugins/jetpack/jetpack_vendor/automattic/jetpack-a8c-mc-stats/src/class-a8c-mc-stats.php(140): wp_remote_get()
  #5 /tmp/wordpress-master/src/wp-content/plugins/jetpack/jetpack_vendor/automattic/jetpack-a8c-mc-stats/src/class-a8c-mc-stats.php(127): Automattic\Jetpack\A8c_Mc_Stats->do_server_side_stat()
  #6 /tmp/wordpress-master/src/wp-content/plugins/jetpack/class.jetpack.php(4756): Automattic\Jetpack\A8c_Mc_Stats->do_server_side_stats()
  #7 /tmp/wordpress-master/src/wp-content/plugins/jetpack/class.jetpack.php(1142): Jetpack->do_stats()
  #8 /tmp/wordpress-master/src/wp-includes/class-wp-hook.php(303): Jetpack->push_stats()
  #9 /tmp/wordpress-master/src/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters()
  #10 /tmp/wordpress-master/src/wp-includes/plugin.php(470): WP_Hook->do_action()
  #11 /tmp/wordpress-master/src/wp-includes/load.php(1100): do_action()
  #12 [internal function]: shutdown_action_hook()
  #13 {main}
    thrown in /tmp/wordpress-master/src/wp-includes/class-requests.php on line 591
  Script tests/action-test-php.sh handling the test-php event returned with error code 255

I'm not sure if it's related to these changes?

[mmtr]

We currently maintain the Nav Unification activation logic for Simple sites in the wpcom codebase (in the show_unified_nav function which lives in wp-content/mu-plugins/masterbar.php), so I guess it makes sense to also add these new checks there?

[mreishus]

I did some testing (the patch is in D75746-code). It looks like it's another way to accomplish the same thing, either this PR or D75746-code is needed, but no extra benefit from both. Maybe D75746-code is better because it keeps the wpcom specific exemptions in wpcom and out of jetpack? I'd be fine w/ closing this PR and going for D75746-code.

[obenland]

I think keeping wpcom's special case on wpcom in D75746-code makes sense. With WordPress/gutenberg#38810 about to be merged you could even keep it to just the *stuff.php file checks.

[mmtr]

I'd be fine w/ closing this PR and going for D75746-code.

Let's do that then 🙂

[mreishus]

Deployed D75746-code and made a note to remove the ?service-worker exemption after WordPress/gutenberg#38810 is merged

[mreishus]

Even though Gutenberg has removed the service worker, it's still installed in my browser and continues to make requests to /wp-admin/?service-worker=true. It seems safer to keep the workaround (D75746-code), unless there's a way to programmatically uninstall the service worker (I don't know of one).