Tracking Issue: sites stuck in a "Launch Site" state

[liviopv]

Quick summary

Sometimes, the site will get stuck in a state between unlaunched and launched, where the UI might treat it as a launched site in some context, but not on others. This affects customers with tasks like changing site privacy, editing/previewing content, and more. In general, HEs are able to launch sites for the customer, or clear the state by changing the privacy settings.

This issue is meant to track similar cases to determine a pattern/reproduction steps.

Steps to reproduce

No clear repro steps

What you expected to happen

The UI should indicate consistently if a site is launched/unlaunched and the site's features should also behave correctly based on that

What actually happened

Sites seem to get into a "limbo" state, and users are unable to use features like Preview correctly

Impact

Some (< 50%)

Available workarounds?

Yes, easy to implement

Platform (Simple and/or Atomic)

Simple, Atomic

Logs or notes

No response

[liviopv]

8213241-zd-a8c

@mrfoxtalbot please review this issue and confirm it portraits the feedback you shared correctly.

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 8213241-zen
• [ ] 8327906-zen
• [ ] 8540850-zen
• [ ] 8579547-zen
• [ ] 8594481-zen

[mrfoxtalbot]

8213241-zd-a8c @mrfoxtalbot please review this issue and confirm it portraits the feedback you shared correctly.

Yes, this seems to be the same issue. I have stumbled into this 3-4 times in 5 months so it is probably happening fairly often.

Setting the site as Coming Soon and then making it Public again fixed the problem every time.

[mrfoxtalbot]

Another one in 8327906-zd-a8c

The site was not showing thumbnails in the Media Library (related to https://github.com/Automattic/wp-calypso/issues/91136). I fixed it my setting the site as private and then as public again.

[mrfoxtalbot]

One more 8540850-zd-a8c

[mrfoxtalbot]

I am bit torn between Normal and High priority here.

Yes, it is an intermittent issue and is only affecting a subset of users (we need to determine who had why) but it makes our platform unusable for those users and it is virtually impossible these users will figure out who to fix it without contacting us.

Could we please assign some dev time to replicate what's causing this? @Copons, @candy02058912, @inaikem

[lsl]

I'm not sure what the next steps here are but someone could timebox taking a look at trying to replicate the site state that leads to this.

As a first guess, one thing I'm noticing in a couple of the Blog RC of sites mentioned in the zendesk tickets is that there are multiple headstart runs, it's possible something in there is messing with launch state on the secondary runs.

[mrfoxtalbot]

I started a conversation here p7DVsv-l8T-p2

[i11za]

Not sure if this is related when a site stuck in Private after plan expiration/downgrade and can't switch to Public? Switching to Coming Soon and then to Public resolves the issue. User report here: 8579547-zd-a8c

[i11za]

I'm curious if we've considered if this is theme-related? Anecdotally, I think whenever I've seen this happen (before we started tracking, so I can't recall exact interactions), these seem to be all sites with Assembler theme.

Here's a user report, the site hasn't been launched yet, but they're unable to edit the homepage either through Pages or the Editor that might be related: 8594481-zd-a8c

[lsl]

Posted in dotcom-escalations, p1724126661488059-slack-C02FMH4G8

[dsas]

I'm curious if we've considered if this is theme-related? Anecdotally, I think whenever I've seen this happen (before we started tracking, so I can't recall exact interactions), these seem to be all sites with Assembler theme.

It doesn't seem to be Assembler related, 8213241-zd-a8c started with TT4 and then switched Jaida before reporting the issue.

Neither did 8213241-zd-a8c go through a plan cancellation/downgrade (or at least there's nothing in the audit log about that)

[mpkelly]

It doesn't seem to be Assembler related

From what I can see, only one of them used Assembler. They all seem to be block themes.

I am wondering if this relates to this issue https://github.com/Automattic/wp-calypso/issues/93265. In short, previewing posts and pages in Feelin' Good theme was broken until you launched your site. The issue didn't need to be fixed and just started working again after about a week. Could these issues be related to Gutenberg releases?

Looking in the audit logs, the domain was changed around the time of the "blog privacy" audit events in four of the five cases. They are all paid plans of some kind, too.

[vykes-mac]

@mrfoxtalbot from ticker 8213241-zd-a8c you mentioned

After some investigation, I noticed that the "launch your site" message was blinking for a moment when I tried to visit

Could you explain this a bit? Did that message flash in the editor or when visiting the site?

[lsl]

Reproducing something consistently with these steps:

• Open a post https://wordpress.com/post/ new / existing doesn't matter
• Click the components dropdown menu icon (three dots to the right of help center)
• Hover over the Manage Patterns link and confirm it points at wordpress.com
• Click the components dropdown menu icon to close it
• Click it again to open it
• Hover over the Manage patterns link and confirm it now points to wp-admin and receives a refused to connect error on click

Doesn't need to be coming soon or unlaunched. I could be looking at a completely separate issue here but since this is consistent to repro I suggest we start by figuring out what is causing this first. I'm aware this doesn't line up with reports that coming soon re-toggling fixes it. (It doesn't fix my issue at least)

[miksansegundo]

Reproducing something consistently with these steps:

I can reproduce that, the Manage Patterns link changes as you described. I'm going to debug it now.

The error refused to connect appears when we click it because https://wordpress.com/post/{ SITE } tries to open { SITE }/wp-admin/site-editor.php?postType=wp_block in the iframe.

The console shows the error Refused to display '{ SITE }.wordpress.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

The Manage Patterns link works when opened in a new tab. Maybe a quick workaround can be adding target="blank" to that link?

I found that the "Manage Patterns" URL that goes to the site editor in wp-admin is already captured here but it's not working. That code is supposed to capture the click to open it in the parent frame here but I could not debug that.

[arthur791004]

The issues seem to be how Gutenberg display the dropdown menu. When you open the dropdown at the first time, Gutenberg appends .components-popover__fallback-container to the body so it triggers the mutation observer. However, the element won't be removed after you close the dropdown. As a result, when you open the dropdown again, the link won't be changed anymore.

[arthur791004]

Here is the issue before: https://github.com/Automattic/wp-calypso/issues/59794

[mrfoxtalbot]

After some investigation, I noticed that the "launch your site" message was blinking for a moment when I tried to visit

Could you explain this a bit? Did that message flash in the editor or when visiting the site?

I am not sure I remember 100%, @vykes-mac but I suspect the message flashed in Calypso, right before the errors came up.

[lsl]

Looks like multiple issues but maybe they're related?

Here is the issue before: https://github.com/Automattic/wp-calypso/issues/59794

There was a follow up on that: https://github.com/Automattic/wp-calypso/pull/83474

And an open bug for a related issue here https://github.com/Automattic/wp-calypso/issues/83472

It's possible the underlying html behavior changed again or it just never worked for secondary clicks.

There used to be a warning shown but it seems this is no longer the case, instead you get a refused to connect error. It possible something else changed that behavior? (which might be what we're seeing in this issue)

I'm seeing the components-popover__fallback-container starts out not created, but once it is created, secondary clicks to the settings menu will change out the contents.

We're observing the initial insert and fixing the links but subsequent inserts get missed.

[lsl]

I'm sure there is a much better way to do this but https://github.com/Automattic/wp-calypso/pull/93848/ seems to do the job. EOD here, will continue monday unless someone else can pick this up.

[miksansegundo]

It's works 👍 to fix the iframe error "refused to connect". I have addressed the feedback and updated the description. https://github.com/Automattic/wp-calypso/pull/93848 It's ready for review!

I can also not reproduce the change of the Manage Patterns URL you mentioned happens when opening twice the editor options.

[lsl]

https://github.com/Automattic/wp-calypso/pull/93848 has fixed https://github.com/Automattic/wp-calypso/issues/83472 but this is unrelated to what is being reported above... back to looking for a way to repro.

[lsl]

Working theory: nonce verification failure. Need to move off this for the time being, please ping me directly if you find a new report of this.

[ivan-ottinger]

Hey folks 👋🏼🙂 As a part of the groundskeeping efforts, I would like to check whether there are any plans on continuing working on this issue in the near future.

If not, would you say it would be reasonable to move the issue to the Lego's team project board? Thank you!

[obenland]

If not, would you say it would be reasonable to move the issue to the Lego's team project board? Thank you!

@autumnfjeld Could Lego pick this up?

[autumnfjeld]

@taipeicoder is the Lego Lead, passing the question on to him. :)

[taipeicoder]

@obenland we currently don't have the bandwidth to take this. Looking at the issue history, it seems to be a side effect of multiple bugs. Happy to put it on the team's backlog for one of our GK rotations.

[mmtr]

I think we need to step back a little bit to put things in perspective, because the original reports seem to be unrelated to what's being discussed most recently.

Issue 1 (8213241-zd-a8c)

• User is unable to edit posts with the iframed editor (there is a "refused to display" error)
• Fixed by launching the site and changing it back to Coming Soon

Conclusion: Some corrupted data (a blog option? cache? redux state?) was preventing them to use the iframed editor. Changing the site privacy fixed the corrupted data.

Issue 2 (8327906-zd-a8c)

• User is unable to load images in the Media page of an Atomic site
• Fixed by changing the site privacy to Private and then back to Public

Conclusion: Images ended up with the incorrect privacy during the Atomic transfer. I believe the Atomic team recently worked on addressing several issues for private Atomic sites.

Issue 3 (8540850-zd-a8c, 8594481-zd-a8c)

• Clicking on "Edit site" or "Edit (page)" does nothing: the browser refreshes but eventually they are back in the same page they were before
• There is a helpful screen recording in the 2nd ticket
• Fixed by launching the site and changing it back to Coming Soon (note that in the 2nd ticket, the user was asked to do this, we didn't fix it)

Conclusion: The issue is no longer reproducible / has been already fixed. I switched to the user of the 2nd ticket whose site is still unlaunched and followed the exact same steps as the screen recording, but can access the site editor successfully.

Issue 4 (8579547-zd-a8c)

• User downgraded their plan on Atomic sites, so as part of the Atomic revert, the site is made private
• After dealing with the downgrade, the user makes two requests to make the site public.
• They don't say they cannot do it on their own, it seems they just wanted us to do it.

Conclusion: No issue.

---

I think the only issue we don't know yet if it's still relevant is the first one. But considering we only got one report and it's probably a different symptom of the 3rd issue (which we know it's been fixed), I think we can close this one out.

Feel free to re-open if we get new reports.