Previews: Fix for previewing posts on sites with mapped domains.#15061
Previews: Fix for previewing posts on sites with mapped domains.#15061
Conversation
|
You can trigger an installable build for these changes by visiting CircleCI here. |
…nto issues/14220-previews-for-mapped-domains
|
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
|
|
||
| private static func unmapURL(post: AbstractPost, url: URL) -> URL? { | ||
| guard | ||
| let components = URLComponents(url: url, resolvingAgainstBaseURL: false), |
There was a problem hiding this comment.
Suggestion - if this was a var you wouldn't need comps below.
There was a problem hiding this comment.
Oh ha! I never realized guard var was allowed! TIL. Thanks!
|
Hey @aerych . Here are my testing results. Successes: Failures: Both of these behaved the same:
|
ScoutHarris
left a comment
There was a problem hiding this comment.
See testing results.
|
Thank you @ScoutHarris !
For this one I found two scenarios where the preview wouldn't show. One was when proxied 😬. The other depended on the site's permalink format. I've pushed an update that should take care of this case. Would you mind trying again?
Arg! I even had a recording of this working. :( Sadly, it looks like I was testing this under special circumstances so my expectations were off. The preview is not expected to be shown in this case so, what you saw was probably expected and not a regression, but please confirm!
Yeah. I omitted this because these previews were not expected to work in this scenario. (No autosave post type.) :) Ready for another peek! |
|
Hey @aerych .
I'm not sure what's wrong but my .blog site doesn't show unsaved edits in the preview. I tried on a real device, so I wasn't proxied.
|
|
Just in case using a device mattered, I repeated the above test on my iPhone 11 Pro (iOS 13.7) and I'm seeing the same result. (I did use different test text just to be sure.) The previous test was in the iPhone 11 Pro (iOS 14) simulator. I'm wondering if the issue you're seeing might be due to a glitch with the cookie auth (not sure yet how to test this). I can look into this angle tomorrow. |
…nto issues/14220-previews-for-mapped-domains
|
That was a merry little debugging adventure :) So happy you happened to test with an Atomic site! After logging in to your test site as an editor (thank you again!) I was able to reproduce the issue there. To recap our chat conversation, the issue turned out to be that for Atomic sites, the value of their Some investigation revealed the trick Calypso uses is to load wp-login.php with a redirect to the desired page. In the case of Atomic sites with SSO enabled the redirect is fairly seamless. In cases where SSO is not enabled, there is still a prompt for credentials as a semi-graceful fallback. It's not perfect, but better than the current situation. I've updated the PR with some logic that checks for public atomic sites and rewrite the request URL to proxy through wp-login.php. I tested with your test site and it was working for me there. I also created an ephemeral atomic site to test with but, interestingly, these sites do not report themselves as being atomic (?!) via the REST API and so regular wpcom auth is attempted. This is something that needs to be addressed server-side, not in the app, so 🤷 for now. I'll open an Android issue regarding Atomic published post previews. Ready for another peek! cc @diegoreymendez in case you're interested in this as well. |
ScoutHarris
left a comment
There was a problem hiding this comment.
Excellent debugging skillz!! It is in fact working as advertised. Well done!
![]()
| } | ||
|
|
||
| authenticationService.loadAuthCookiesForWPCom(into: cookieJar, username: username, authToken: authToken, success: { | ||
| done() |
There was a problem hiding this comment.
Fairly minor, but this jumped out at me while looking at the code. I think you can simplify the success param to just be:
success: done,(Without the {}s and ()s)
There was a problem hiding this comment.
True. If you don't mind I think I'll leave it as is so it's consistent with the other methods in that class. Thanks for taking a peek!
…nto issues/14220-previews-for-mapped-domains
…nto issues/14220-previews-for-mapped-domains
|
Thank you @ScoutHarris and @diegoreymendez ! |
Fixes #15266 Prior to #15061 (or b01f2e6 to be specific), post previews on sites with custom domains used the sites public URL (not the mapped `*.wordpress.com` one). This PR restores the previous behavior by reverting a small change that led to the `preview=true` query parameter being added to post preview URLs.



Fixes #14220
This PR adds new logic to preview URLs to ensure that previewing on a site with a mapped domain will use the site's unmapped URL rather than the mapped URL. This will let our preview browser use existing auth cookies rather than having to make a complicated series of requests to obtain an authenticated session.
@ScoutHarris could I trouble you for a review? Also ccing @guarani who has looked into this previously.
** Merge after landing related changes to WordPressKit.
To test:
Prep:
Scenario 1: Mapped Domain Draft Preview
Scenario 2: Mapped Domain Published Preview
Scenario 3: Unmapped Site Draft Preview
Scenario 4: Unmapped Published Preview
Scenario 5: Jetpack Site Draft Preview
Scenario 6: Jeptack Site Published Preview
Scenario 7: Self-hosted Site Draft Preview
PR submission checklist:
RELEASE-NOTES.txtif necessary.