REST API: Use home URL as unmapped URL

[mmtr]

Fixes Automattic/wp-calypso#36837

Changes proposed in this Pull Request:

Uses the site URL used as the value of the unmapped_url option returned when requesting a site via REST API.

WordPress.com sites stores in the siteurl option the *.wordpress.com domain of a site, but this does not apply for Jetpack sites where that option could be the default value (same mapped domain as the home URL) or a custom URL defined by the user (i.e. subdirectory installs) that is not intended to be used as unmapped URL.

Given that Jetpack sites don't have an unmapped URL (they all have a mapped domain and can be accessed only through that mapped domain), this PR ensures its value fallbacks to the home URL (which is actually the mapped domain).

This was resulting in issues like Automattic/wp-calypso#36837, caused by Calypso building a wrong preview URL due to the unmapped URL pointing to the subdirectory where the WordPress files live.

Quick note to understand the differences between site and home URLs, since it can be very easy to confuse them:

• Site URL: it is where the admin pages are, along with all the other parts of WordPress, such as the folders /wp-content/ and /wp-include. The value of this setting is displayed in the "Settings > General" screen as "WordPress Address (URL)". It is defined by the WP_SITEURL constant and stored in the siteurl site option.
• Home URL: it is the public-facing part of a site. The value of this setting is displayed in the "Settings > General" screen as "Site Address (URL)". It is defined by the WP_HOME constant and stored in the home site option.

Is this a new feature or does it add/remove features to an existing part of Jetpack?

Fix an existing bug in the REST API shared with WP.com

Testing instructions:

• Set up a Jetpack site with WordPress installed in a subdirectory:
  • Method 1: official and long way.
  • Method 2: hacky and quick way. We'll fake the site URL to make WordPress believe it is in a subdirectory. Since it is actually not in a subdirectory, this will result in the admin pages being unusable, but it'll be enough for testing the front-end and the API.
    • Spin up a JN site running this branch.
    • Connect it to your WordPress.com account.
    • Activate the Hello Dolly plugin, and add this to it with the Plugin Editor:

add_filter( 'site_url', function ( $site_url ) { return $site_url . '/wp'; } );

• Apply D34373-code and sandbox public-api.wordpress.com.
• Make a GET request to https://public-api.wordpress.com/rest/v1.1/sites/<YOUR_JETPACK_SITE>?fields=ID,URL,options&options=unmapped_url.
• Verify the unmapped_url option points to the home URL of your site.
• Go to https://wordpress.com/posts/<YOUR_JETPACK_SITE>.
• Preview a post using the contextual menu on the right:

• Make sure the post is previewed successfully and you don't get a 404 error.
• Repeat steps with a Simple site and confirm posts can be previewed too.

Further testing

• Check there are no regressions in other places where the unmapped URL is used, for both Jetpack and Simple sites:
  • Site redirect (Simple sites only). The unmapped URL is used in the "thank you" screen:
  • Customizer. It should load the *.wordpress.com URL in an iframe for Simple sites, and redirect to the WP Admin customizer for Jetpack sites.
  • Preview a site. It should successfully preview a site with no 404 errors.
  • Preview a post with the classic editor. It should successfully preview a post with no 404 errors.
  • Stats spark line (Simple sites only). The image displayed points to wp-includes and it is built using the unmapped URL:
    .

Proposed changelog entry for your changes:

REST API: Use home URL as unmapped URL

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello mmtr! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer, review, and approve D34373-code before merging this PR. Thank you!

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: November 5, 2019.
Scheduled code freeze: October 29, 2019

Generated by 🚫 dangerJS against 12e95f1

[gwwar]

Noting that D34373 has green tests. Not sure how to re-trigger the PR check here. We might need to rebase?

[kwight]

One way to test this is with a JN site and the home_url filter in a plugin:

1. Create a JN site with the JP Beta plugin also installed, and this branch selected.
2. Connect the site to your WordPress.com account.
3. Activate this branch in the Beta plugin.
4. Activate the Hello Dolly plugin, and add this to it with the Plugin Editor:

add_filter( 'home_url', function () { return 'testing'; } );

With D34373-code on a sandbox and the API sandboxed, we should be able to make the API calls above and get the correct unmapped URL.

[kwight]

🎉

[kwight]

With a standalone, subdirectory install on Linode that appears to be working properly, the site URL looks like <domain>/index.php, so calls to /posts on WordPress.com produce a preview View link of https://<domain>/index.php/2019/10/23/hello-world/ (this happens even on JP stable, so it's not directly connected to this PR).

[mmtr]

One way to test this is with a JN site and the home_url filter in a plugin:

Subdirectory installs typically have a home URL pointing to the root address (i.e. example.com) and a site URL pointing to the directory (i.e. example.com/wp), so we would need to use the site_url filter in this case

With a standalone, subdirectory install on Linode that appears to be working properly, the site URL looks like <domain>/index.php, so calls to /posts on WordPress.com produce a preview View link of https://<domain>/index.php/2019/10/23/hello-world/ (this happens even on JP stable, so it's not directly connected to this PR).

Seems to be normal, given the site has a custom permalink:

Does Calypso refuse from previewing those links?

[mmtr]

I think there is an issue with the Linode site and probably it is not correctly configured. Trying to load a post (i.e. https://<domain>/index.php/2019/10/23/hello-world/) results in a Document root with no WP. WP is installed in /wordpress. error.

I'm trying now setting up a local env with Chassis, which seems to install WordPress in a subdirectory out-of-the-box.

[mmtr]

I'm trying now setting up a local env with Chassis, which seems to install WordPress in a subdirectory out-of-the-box.

No luck with this since the site is not publicly available (so Jetpack cannot connect to it) and ngrok doesn't help given that it only exposes the site under http (making the site unpreviewable in WordPress.com).

[mmtr]

Updated the testing instructions with the fake method suggested by @kwight. I tried that and it seems to work (despite being impossible to load the admin pages).

[gwwar]

Mob tested with @mmtr @kwight and @gwwar. For a subdirectory install, verified a 404 preview before and a working preview after with this branch and diff applied.

Kudos to @griffbrad for providing the testing site! ✨

[kwight]

🚢

[jeherve]

This seems to work well in my tests. Merging.