Update JITMs to use new v3 endpoint by getdave · Pull Request #101783 · Automattic/wp-calypso

getdave · 2025-03-24T15:38:20Z

Related to #

Proposed Changes

Use the new wpcom/v3/jitm endpoint on the Public API directly for non-Jetpack requests (see PCYsg-OT6-p2 for scenarios where Calypso code might run in a "Jetpack context").

Note: JP contexts continue to use the Jetpack endpoint. ~~We can update that in a followup PR.~~ Actually we can't because we're modifying the schema.json in this PR which would break those contexts. So we need to fix it!

Why are these changes being made?

As part of p58i-kwy-p2 JITMs received a new endpoint in 177578-ghe-Automattic/wpcom.

This endpoint is available on the Public API and thus calling it directly avoids the additional network hops involved in calling the endpoint on the Jetpack site.

The current route for the request is: Calypso request -> Proxy request to JP site -> jetpack/v4/jitm -> Public API JITM endpoint

The proposed new route for the request is: Calypso request --> Public API JITM v3 endpoint.

The new v3 endpoint on the Public API routes all JITM requests via the Jetpack mechanics.

This change should improve the speed at which JITMs load in Calypso.

Testing Instructions

Update your SB
Add the following to 0-sandbox.php - 3774b-pb/#php
Check out this Calypso PR.
Build
In Calypso visit /home/ for a Simple site.
You should see the test JITM at the top fo the screen (see screenshot) below.
You should see the Free domain with an annual plan JITM in the sidebar.
Open Network in dev tools. Filter by jitm. Reload. Check that you can see requests going to Public API wpcom/v3/jitm.
Now test you can dismiss the JITM using the X icon on the JITM message in the UI. When clicked you should see a POST network request to the JITM endpoint with the response being true.

Testing Odyssey stats:

Build get both Jetpack and Calypso running
Use a tunnel to connect to your Jetpack site
Add the following to 0-sandbox.php - 3774c-pb/#php
Ensure that your Jetpack site is connecting to your wpcom sandbox using the JETPACK__SANDBOX_DOMAIN const
cd ~/Sites/wp-calypso/apps/odyssey-stats
STATS_PACKAGE_PATH=~/Sites/jetpack/projects/packages/stats-admin yarn dev
Open the Stats page: /wp-admin/admin.php?page=stats
Dismiss the message that asks you if you're enjoying Stats
Confirm you see a JITM
Open your console and go to the network tab
Filter for JITM
Confirm that request is to the v3 endpoint

Screenshots

Pre-merge Checklist

Has the general commit checklist been followed? (PCYsg-hS-p2)
Have you written new tests for your changes?
Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
Have you checked for TypeScript, React or other console errors?
Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
- For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

github-actions · 2025-03-24T15:38:32Z

Calypso Live (direct link)

	https://calypso.live?image=registry.a8c.com/calypso/app:build-139967

Jetpack Cloud live (direct link)

	https://calypso.live?image=registry.a8c.com/calypso/app:build-139967&env=jetpack

Automattic for Agencies live (direct link)

	https://calypso.live?image=registry.a8c.com/calypso/app:build-139967&env=a8c-for-agencies

matticbot · 2025-03-24T15:48:29Z

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~6 bytes added 📈 [gzipped])

Details

name                 parsed_size           gzip_size
entry-subscriptions        +34 B  (+0.0%)       +6 B  (+0.0%)
entry-stepper              +34 B  (+0.0%)       +6 B  (+0.0%)
entry-main                 +34 B  (+0.0%)       +6 B  (+0.0%)
entry-login                +34 B  (+0.0%)       +6 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~194 bytes removed 📉 [gzipped])

Details

name          parsed_size           gzip_size
staging-site       -386 B  (-0.0%)     -102 B  (-0.0%)
hosting            -386 B  (-0.0%)     -102 B  (-0.0%)
home               -386 B  (-0.0%)      -92 B  (-0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~109 bytes removed 📉 [gzipped])

Details

name                            parsed_size           gzip_size
async-load-calypso-blocks-jitm       -386 B  (-0.5%)     -109 B  (-0.5%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

matticbot · 2025-03-24T15:58:37Z

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

blaze-dashboard
notifications
odyssey-stats

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/use-new-jitm-endpoint on your sandbox.

getdave · 2025-03-24T16:03:36Z

client/state/data-layer/wpcom/sites/jitm/schema.json

 {
 	"$schema": "http://json-schema.org/draft-04/schema#",
-	"properties": {
-		"data": {


IN my testing the data wrapper isn't included for the new wpcom/v3 endpoint. However, it is presumably included by the jetpack/v4 endpoint.

Therefore we actually need to fix the doJetpackFetchJITM calls as well otherwise we risk breaking JITMs in those contexts.

If anyone knows the best way to test that scenario it could save me a lot of time 🙏

I've asked for some input in p1742832462839269-slack-C03N25JPCE4

Left a response there. TL;DR: I believe that after Automattic/jetpack#39714 we don't really need special Jetpack site treatment.

I tested three flavors of a JITM REST request and here are the results 🙂

/jetpack-blogs/:site/rest-api?path=/jetpack/v4/jitm returns a body that is of type { data: [] }, i.e., the array with messages in on a data field of the response JSON body.

the same /jetpack/v4/jitm done directly and locally on a Jetpack site returns a body that is of type [], i.e. the messages array is the top-level object in the response JSON body.

the new /wpcom/v3/sites/:site/jitm also returns the array directly in body, with no data field.

It turns out that adding data is a feature of the /jetpack-blogs/:site/rest-api endpoint. In the source (WPCOM_JSON_API_Jetpack_Blog_Endpoint::process_rest_api_request) there is a statement at the end that wraps the response:

return array( 'data' => $body, );

This PR removes usage of variant 1 (/jetpack-blogs) and replaces it with variant 3. That means that there are no longer responses that return a data field. Neither doFetchJITM (variant 3) nor doJetpackFetchJITM (variant 2) use it. That means that data can be removed from the schema. Is my reasoning correct?

The doJetpackFetchJITM flavor (local /jetpack/v4/jitm) request is used in Odyssey Stats when the Calypso-built widget is running inside a self-hosted Jetpack site's WP Admin. Maybe Automattic/jetpack#39714 disables that, but I don't immediately see how that disabling is done and have some doubts.

I also tested the locale query param and it doesn't seem to have any affect. But maybe it should! It makes sense to localize the messages. If the JITM tells me "Free domain with an annual plan", this message should be localized. I also tested the (native) _locale=de param but it doesn't work either.

Currently looking for support in working out how to test in the "Jetpack" context as the endpoint is conditionally called.

To test this, just open a Stats page in Atomic site's WP Admin. Note that the stats UI code (webpack chunks for JS and CSS) is loaded from widget.wp.com/odyssey-stats/v1. It doesn't ship with the Jetpack plugin itself.

You'll see that the Odyssey app will be fetching JITMs from the local /jetpack/v4/jitm endpoint (wp:jetpack_page_stats:admin_notices) and renders a div with CSS class jetpack-jitm-message-container. Which will be empty unless there is actually a JITM to display.

This is the doJetpackFetchJITM code path at work 🙂

How does the the jetpack_display_jitms_on_screen filter in Automattic/jetpack#39714 fit into that? It disabled the "Jetpack native" UI to display JITMs on the Stats page, precisely because the Stats page now has its own UI to display JITMs, the one I just described above.

I still have some doubts whether Post_Connection_JITM really does any essential work besides maybe caching.

True. Difficult to ascertain. We could have ignored it but who knows what relies on it.

It's worth trying to remove the additional complexity and just call JITM/Engine directly. But that's totally not a blocker today, it's more like a followup idea.

I think that's a totally valid observation. For Dotcom we will always be connected to JP so the Pre/Post Connection aspect is largely redundant.

The main point is that this body of work creates consistency is how we call and fetch JITMs across all sites and apps.

It also has the additional benefit of removing a redundant network request with Calypso proxying it's request to the endpoint on the JP site (which would in turn send the request to the Public API). Now Calypso just directly calls the public API.

@jsnajdr Once this ships do you think we should remove the jetpack/v4/jitm endpoint? Or do we leave in place forever for backwards compatibility?

Do you mean the one in the Jetpack plugin? Or the rest-api?path=/jetpack/v4/jitm one on WP.com? I'd rather keep both of them for now, at least for some time. Let's watch the stats how often they get called. My experience is that legacy resources very rarely drop to zero usage, there is always someone somewhere who loads them 🙂

I thought they were the same endpoint?

rest-api?path=/jetpack/v4/jitm is calling the jetpack/v4/jitm on the remote JP site

jetpack/v4/jitm is in the Jetpack plugin and can be called directly or via the proxy

Happy to leave them around for now.

I thought they were the same endpoint?

There's one caveat: rest-api?path=/jetpack/v4/jitm also works on Simple sites where there is no remote JP site to call. It's implemented in jetpack-direct-call, directly using the JITM Engine. It's another implementation that used directly the JITM primitives, it doesn't forward the REST request to another REST handler.

client/state/data-layer/wpcom/sites/jitm/index.js

getdave · 2025-04-04T15:05:15Z

We need to update testing instructions for stats pages on:

Calypso
WPAdmin (via PCYsg-Pp7-p2)

This will ensure the JITMs work.

Also we need to remember to updte instructions to say dimiss any Calypso notices else the JITMs aren't even requested 🤦

scruffian

I've tested this and it works in both environments. I'd also wait for a review from @jsnajdr before merging, since he knows the code better than me.

jsnajdr

Yes, this looks good. Thanks for the gruelling work getting this through the finish line 🙂

client/state/data-layer/wpcom-http/index.js

client/state/data-layer/wpcom/sites/jitm/index.js

getdave · 2025-04-08T08:37:20Z

Yes, this looks good. Thanks for the gruelling work getting this through the finish line 🙂

Thank you for helping out 🙇

getdave · 2025-04-08T09:09:07Z

Updated the docs to include a note about dismissing Notices in order to see JITMs.

PCYsg-Pp7-p2

getdave · 2025-04-08T11:25:37Z

Reaching out to original dev team on this for some support with Deployment. See p1744111326087799-slack-C034TMVE5CM

getdave · 2025-04-08T12:46:17Z

Deployment Status

Calypso app on WordPress.com - tested and verified a test JITM will appear on WordPress.com.
The Odyssey Stats App - see 180009-ghe-Automattic/wpcom. This will now be deployed in a followup PR.

* Test using new endpoint * Update to restore comment * Update tests * Try running all calls to new endpoint * Allow calling local wpcom endpoint when running in Jetpack * Fix Post requests * Remove redundant code now shape is same * Resolve code review changes * Update tests to include isLocalApiCall * Move config check to runtime to enable mocking in tests * Provide test coverage for path change * revert whitespace change * Update with dedicated path tests

getdave requested review from MaggieCabrera, draganescu, jeryj, matiasbenedetto, scruffian and tyxla March 24, 2025 16:01

matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Mar 24, 2025

getdave self-assigned this Mar 24, 2025

getdave added the [Feature] JITM Just In Time Messages - pop-up tips and suggestions that appear on the dashboard and sidebar. label Mar 24, 2025

getdave requested a review from jsnajdr March 24, 2025 16:01

getdave commented Mar 24, 2025

View reviewed changes

tyxla reviewed Mar 25, 2025

View reviewed changes

client/state/data-layer/wpcom/sites/jitm/index.js Show resolved Hide resolved

jsnajdr reviewed Mar 28, 2025

View reviewed changes

client/state/data-layer/wpcom/sites/jitm/index.js Show resolved Hide resolved

jsnajdr reviewed Mar 28, 2025

View reviewed changes

client/state/data-layer/wpcom/sites/jitm/index.js Outdated Show resolved Hide resolved

jsnajdr reviewed Mar 28, 2025

View reviewed changes

client/state/data-layer/wpcom/sites/jitm/index.js Outdated Show resolved Hide resolved

getdave marked this pull request as ready for review April 4, 2025 14:59

scruffian approved these changes Apr 4, 2025

View reviewed changes

jsnajdr approved these changes Apr 4, 2025

View reviewed changes

client/state/data-layer/wpcom-http/index.js Outdated Show resolved Hide resolved

client/state/data-layer/wpcom/sites/jitm/index.js Outdated Show resolved Hide resolved

getdave added 6 commits April 8, 2025 12:10

Test using new endpoint

9e8d30b

Update to restore comment

057e039

Update tests

e6a0d9b

Try running all calls to new endpoint

2212435

Allow calling local wpcom endpoint when running in Jetpack

ab94a3a

Fix Post requests

a49beaa

getdave added 7 commits April 8, 2025 12:10

Remove redundant code now shape is same

b6f6a59

Resolve code review changes

a4afb16

Update tests to include isLocalApiCall

2a57057

Move config check to runtime to enable mocking in tests

f4ec44e

Provide test coverage for path change

5dcefde

revert whitespace change

e73fbcb

Update with dedicated path tests

9587076

getdave force-pushed the update/use-new-jitm-endpoint branch from 14400a0 to 9587076 Compare April 8, 2025 11:10

getdave merged commit 5ad6db8 into trunk Apr 8, 2025
13 checks passed

getdave deleted the update/use-new-jitm-endpoint branch April 8, 2025 12:10

github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Apr 8, 2025

kangzj mentioned this pull request Apr 9, 2025

Odyssey Stats: use jetpack/v4/jitm endpoint for Jetpack version < 14.5 #102519

Merged

8 tasks

Comments

Conversation

getdave commented Mar 24, 2025 • edited by scruffian Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed Changes

Why are these changes being made?

Testing Instructions

Testing Odyssey stats:

Screenshots

Pre-merge Checklist

Uh oh!

github-actions bot commented Mar 24, 2025 • edited by matticbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matticbot commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matticbot commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

getdave commented Apr 4, 2025

Uh oh!

scruffian left a comment

Choose a reason for hiding this comment

Uh oh!

jsnajdr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

getdave commented Apr 8, 2025

Uh oh!

getdave commented Apr 8, 2025

Uh oh!

getdave commented Apr 8, 2025

Uh oh!

Uh oh!

getdave commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deployment Status

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

getdave commented Mar 24, 2025 •

edited by scruffian

Loading

github-actions bot commented Mar 24, 2025 •

edited by matticbot

Loading

matticbot commented Mar 24, 2025 •

edited

Loading

matticbot commented Mar 24, 2025 •

edited

Loading

getdave commented Apr 8, 2025 •

edited

Loading