Wp-calypso: Jetpack: can't access sites where URL matches an old mapped WordPress.com site

Created on 14 Jul 2016  ยท  25Comments  ยท  Source: Automattic/wp-calypso

I believe this is a fairly recent issue, the following used to work, at least up until a week ago:

Steps to reproduce

  1. Start by creating a WordPress.com site.
  2. Add a domain mapping to that site, to map it to a domain you already own.
  3. You can now access this site's settings in Calypso using the new mapped URL in the Calypso URL.
  4. Change the domain's NS records to point the domain to a new hosting provider.
  5. Create a new site on that host, and install WordPress.
  6. Install and activate Jetpack.
  7. Up until very recently, you were then able to access that site's settings in Calypso using the site URL in the Calypso URL.
  8. Right now, however, that site URL loads the old WordPress.com site settings.

A good example is blog ID 94957111, that now loads settings from 33644320.

Jetpack [Pri] High [Type] Bug

Most helpful comment

All tickets and forums threads have now been replied to if needed.

All 25 comments

More discussion here: p7rcWF-6N-p2

Also have this issue for sites where the domain is registered with us and then the user moves to Jetpack site.
Reported in 472831-chat

More discussion here: p2MSmN-5rU-p2

This is still pending a fix on the domains API side, on WordPress.com.

Tested and confirmed that I cannot access a Jetpack site in Calypso if I setup a mapped domain there and then move to a Jetpack setup.

  • WP.com site: madefortesting347 (Blog ID 105644731)
  • Pressable site: watchingstormsrollby.me (Blog ID 127398684)

These posts actually belong to the madefortesting347 WP.com site:

screen shot 2017-04-14 at fri apr 14 12 02 59 pm
Seen at https://wordpress.com/posts/watchingstormsrollby.me using Firefox 52.0.2 on Mac OS X 10.12.4 logged in as user157 unproxied.

These are the posts I expected to be able to see in calypso for watchingstormsrollby.me:

screen shot 2017-04-14 at fri apr 14 12 05 26 pm
Seen at https://watchingstormsrollby.me/wp-admin/edit.php using Firefox 52.0.2 on Mac OS X 10.12.4 logged in as watchingstormsrollby via Pressable.

@enejb has been working hard on fixing this: p7rcWF-gm-p2, not sure what happened in this particular case

I create a PR ( #13670) that addressed this issue on the calypso side. @designsimply can you test it and see if it work for you as expected?

I checked http://calypso.localhost:3000/posts/watchingstormsrollby.me with the update/use-blog_id-in-api-requests branch applied and the correct posts appear ("Test Post" and "Storm Watching"). LGTM

screen shot 2017-05-08 at mon may 8 4 33 42 pm
Seen at http://calypso.localhost:3000/posts/watchingstormsrollby.me using Firefox 53.0 on Mac OS X 10.12.4 logged in as user157 and unproxied.

In comparison, I see incorrect posts when testing the same url at https://wordpress.com/
screen shot 2017-05-08 at mon may 8 4 08 46 pm
Seen at https://wordpress.com//posts/watchingstormsrollby.me using Firefox 53.0 on Mac OS X 10.12.4 logged in as user157 and unproxied.

The only point of confusion I can see from here is that the watchingstormsrollby.me domain is managed at /domains/manage/madefortesting347.wordpress.com and not /domains/manage/watchingstormsrollby.me (which results in a "Domains are not available for this site." error). Does this point of confusion belong with this issue or should a new issue be created after 13670 is shipped?

Reporting another possible case for emmaeatsandexplores.com.

And several more cases to report of Jetpack stats no longer displaying in the dashboard. Also, popular posts appear to have vanished from some affected sites.

@VR51 this issue is very specifically about Jetpack sites which were previously using a mapped domain at WordPress.com and had migrated to Jetpack setups in the past. For Jetpack stats not displaying in general, I think #14253 was probably the more relevant issue and has already been fixed. If the other case you mentioned where popular posts appear to have vanished is still happening, can you please report that at https://en.forums.wordpress.com/ and tag it with "modlook" and include a specific example if possible? Thank you!

Another case in 3219594-t with godtiglasset.com, similar to @kristarella's example where the domain is reg'ed with WP.com but they've moved to a JP site.

Another case in 3223599-t for chasingskinnyblog.com - same factors (domain registered at wpcom and moved to a JP site). Logged in as the user to verify.

Edited to add: it's not just the stats, the entire interface shows data for the wpcom site regardless which site is chosen under wordpress.com/sites

3232720-t

I have seen 4 more instances of this. Sorry, I don't have the ticket numbers right now, let me know if you need me to find them. 3 were for wpcom sites that used to be Jetpack sites, one for a Jetpack site that used to be wpcom. All customers came to us saying they were unable to create a post because when they tried to choose their site it would just go back to the site chooser.

I tested it and recorded the results here:
https://cloudup.com/cdmISFRHzTp

I was able to access the Jetpack site, but not the wpcom site that had the same domain mapped.

@kristarella ticket numbers would be great if you can get them!

@csonnek I fixed chasingskinnyblog.com manually by adding the has_matching_jetpack_domain sticker via the blog report card (under the "Primary Domain Fix" section). It's no longer a good test case for this bug because of that, but it should be working now.

@aheckler, for 3219594-t, I attempted to fix godtiglasset.com by toggling the "has matching jetpack domain" setting on the blog report card.

@benchilcote, I checked emmaeatsandexplores.com just now and it appears to be working normally.

@tyxla Looks like the fix was merged? I am still seeing this happen in 3262620-t.

Replied to chasingskinnyblog.com to let her know it's been fixed.

It was merged, then reverted because it was breaking a test. We are doing another try to merge it tomorrow. @aheckler @csonnek

15048 and #14685 have just landed as separate approaches to fix the issue and reduce the chance for it to happen, so I'm closing this one. Feel free to reopen if any cases of it pop up again. Special kudos to @enejb, @lezama and @aduth for all of the hard work with both of these!

@aheckler @csonnek @kristarella @benchilcote @VR51 it would be great if you can give the sites from your tickets another try - thanks in advance!

All tickets and forums threads have now been replied to if needed.

Was this page helpful?
0 / 5 - 0 ratings