FSE - Using the classic editor causes WSOD

[glendaviesnz]

The patch D31361-code appears to cause an issue for users that have chosen to stick with classic editor

Steps to reproduce

Placeholder steps - TODO: flesh out replication steps

1. On a non-fse site with pages with block content login in with a user and chose option to stick with classic editor
2. Switch site to FSE
3. Try to edit an exiting page
4. Editor tries to make calls to /wp/v2/types?context=edit&_locale=user and wp-json/wp/v2/ endpoints and crashes with unexpected 404s and unexpected json errors

[gwwar]

@glendaviesnz is this specific to a certain site? I wasn't able to reproduce

[gwwar]

Ah "switching a site to FSE" is the key line, @noahtallen would you like to try and reproduce?

We probably don't need to fix this immediately for our upcoming sprint, but I think we'll need this soon after

[noahtallen]

I'll investigate

[gwwar]

For context, we'll need an idea of severity / how easy it is to reproduce.

[noahtallen]

I was a bit confused about how to reproduce this, so I followed these steps which I hope are about what @glendaviesnz tried :D

Default your account to the classic editor:

1. Create a new user
2. Create a site
3. Make sure the site's theme is NOT one of the defined template themes. (right now, the new template themes are not in our check for them, so they'll work.)
4. Go to edit the page, and in the settings dropdown in the top right, there should be an option to switch to classic. (Like Kerry noted in Gutenberg: Opt-out missing on help icon #35817, there is no option to do this in the help menu.) Update the page now that it's classic.
5. Create a new page and verify that it uses the classic editor.

Enable FSE:

1. Add the blog sticker.
2. Switch the site's theme to Modern Business

Reproduce the issue:

Then, I tried to repo the reported issue.

1. Open one of the pages that already existed. It prompted my to switch to gutenberg, which I did.
2. Opened a few of the other pages created when activating FSE, like "About"

So far I have not been able to reproduce the error. Next up, I'm going to try again but with the latest master build synced to the sandbox, and I'll sandbox the site after creating it.

[noahtallen]

TLDR:

I was ultimately unable to reproduce the reported error, but I did uncover some other issues around this flow.

Site details:

• Site had FSE disabled and the classic editor enabled
• Site, api, and widgets are sandboxed
• FSE, bridge server stuffs are build as of current master and synced to sandbox
• Sandbox is up to date with SVN

In this state, the following issues happen:

1. When switching to modern business and activating FSE, the classic editor opens when you edit the pages of the site. I enabled the block editor via the sidebar at this point. I expected the block editor to be enabled when switching to FSE.
2. I get a fatal error when trying to create a new page. This is the error. Expected no fatal when creating a page.
3. Converting classic content to blocks does not work. The buttons don't do anything. Expected conversion to work smoothly.
4. Editing existing pages and templates seems to work fine.

Step-by-step:

1. Cleaned up svn and ran svn up. It should have still had D31361-code from my work yesterday, though.
2. Next, I synced the master build of both FSE and the Gutenberg iframe bridge to my sandbox.
3. I sandboxed the API, widgets, and the new site which were not sandboxed before (maybe why it didn't happen).
4. I re-activated modern business and saw the sidebar changed, so FSE is now enabled again.
5. I loaded a page, and it is using the classic editor. We do not want this to happen.
6. I used the sidebar to switch to the block editor.
7. It loaded the block editor just fine. Obviously, the existing classic content did not like this, so it showed the invalid content thing for that classic content, but the header/footer look fine.
8. I tried to convert the classic content to blocks, but this does not work at all. Clicking either of these buttons does nothing. There is no response and the popup stays open:

7. At this point I'm not seeing any errors. 8. I try to create a new page, and the editor will not load whatsoever:

The particular error links here: https://reactjs.org/docs/error-decoder.html/?invariant=130&args[]=undefined&args[]=

Editor tries to make calls to /wp/v2/types?context=edit&_locale=user and wp-json/wp/v2/ endpoints and crashes with unexpected 404s and unexpected json errors

The call to types is sucessful on a new page and the wp-json call does not happen when creating a new page, at least before the point where it fails.

[glendaviesnz]

I was able to easily replicate the issue @noahtallen encountered with classic block content being broken on a local install - I have split this of into a separate issue - #35894 as this is unrelated to which editor the user might have set, at point of FSE activation, it happens if classic content exists at the point of enabling FSE. This is probably critical as well @apeatling so have added blocker flag to it, but feel free to revise.

[apeatling]

Yes, this one needs to be fixed since it's a fatal, better to clean it up now.

[apeatling]

Changed my mind on this one, I don't think we should spend our time until after the test, because we're limiting to new users that will never have opted out. Is that correct @glendaviesnz? There should be no situation where this is encountered in the initial test?

If it will impact the test in any way, let's move it back as a blocker.

[noahtallen]

Also reported in #36375

Copied from @vindl:

---

When attempting to load a page on a site that has FSE enabled with a classic editor the WSOD appears.

This is a major issue for support, since HEs opening a customer site for the first time won’t be be automatically using the Block Editor.

I think we should force Gutenberg for all users on FSE enabled sites, regardless of usual per user per site opt-in preferences that we use to determine whether Gutenberg should be loaded.

More info and discussion in this post: paYE8P-8W-p2

---

I'm going to look into this next, as this could be problematic for HEs and we've covered the other blockers :)

[noahtallen]

This is reproducible with the following steps. To do so:

1. Use a user who defaults to the classic editor (account created before Dec 3, 2018)
2. Do not create a site (new FSE sites default to Gutenberg)
3. Instead, from a new test user with an FSE site, invite the account from step 1 to become an administrator on that site.
4. That invited user will have no setting for the FSE site, so it will default to their account preference, which is Classic.
5. Attempt to edit a page on the site you were invited to from Calypso. You will see the classic editor here, no WSOD. It will try to get you into the block editor, but you can use the classic editor. (In fact, this seems to work as well as typical classic editor / block editor differences work. Nothing weird per FSE.)
6. Attempt to edit a page from wp-admin. You will see a WSOD.

[noahtallen]

Fix for this here: D33358-code.

[noahtallen]

I verified the fix in production. Looking good!