Standalone Gutenberg installation doesn't redirect/load the site editor

[tomasztunik]

Description

We are seeing regression in E2E tests for Full Site Editing in WooCommerce Gutenberg Products Block against latest Gutenberg version installed as a standalone plugin.

With Gutenberg 12.7.x when accessing the template editor via site-editor.php we'd correctly load the site-editor using locally installed Gutenberg and the themes.php access via query params would work along it. Now instead we get The editor is unable to find a block template for the homepage. error and editor doesn’t load.

• PR that have introduced the error: Site Editor: Resolve homepage template on server-side #38817 (confirmed merge before this one works ok (b6c79fe)
• Related issue on our side E2E tests failing with the last version of Gutenberg woocommerce/woocommerce-blocks#6071
• example failed CI
• failing test file

We have a navigation helper in place that was ready to handle site-editor and themes editor paths if type of Gutenberg installation context was provided but so far it all worked without the need to redirect to theme.php so it wasn't really used and we relied on the 'core' flag.

Another issue is that once we change the default editorContext in that helper from core to gutenberg it would cause some of the tests to fail (the one accessing ?postType=wp_template path) because of a timeout waiting for SELECTORS.visualEditor to be present but the editor but if no postId is present it would fail as the iframe wouldn't be present.

gutenberg/packages/e2e-test-utils/src/site-editor.js

Lines 249 to 261 in 8a204c8

	export async function visitSiteEditor( query, skipWelcomeGuide = true ) {
	query = addQueryArgs( '', {
	page: 'gutenberg-edit-site',
	...query,
	} ).slice( 1 );
	await visitAdminPage( 'themes.php', query );
	await page.waitForSelector( SELECTORS.visualEditor );
	if ( skipWelcomeGuide ) {
	await disableSiteEditorWelcomeGuide();
	}
	}

cc @Mamaduka

Step-by-step reproduction instructions

1. Install recent Gutenberg (7265b2b , 12.8, 12.8.1, trunk) as a plugin
2. Activate block theme
3. Try to access wp-admin/site-editor.php?postType=wp_template
4. Editor will fail to load

You will see:

5. Install Gutenberg 12.7.2 (e5daf51) or pre-change (b6c79fe)
6. Try to access wp-admin/site-editor.php?postType=wp_template
7. Editor loads normally (confirmed it's not core version)

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 5.9.2, Gutenberg ✅12.7.2 ❌ 12.8 ❌ 12.8.1 ❌ trunk

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

Thanks for creating the issue, @tomasztunik.

Does Site Editor load correctly if you access it via wp-admin/themes.php?page=gutenberg-edit-site?

[tomasztunik]

Yes it does, themes.php works ok. Though as mentioned some tests fail because of the SELECTORS.visualEditor not always resolving when using the visitSiteEditor helper. This uncovered bug on our side and we shouldn't be using the visitSiteEditor util there as it waits for iframe to be present and when we access the main tab with list of templates it is not present so will fail or maybe we should have different SELECTORS there depending if we have postId present so that we wait for iframe or for a list if we don't have it provided.

You might see 8 tests failing from that suite if you tried it but this is "expected".

Question we have is. Should site-editor.php still work as it did? Is there going to be distinction between how you access Core site editor and standalone gutenberg editor? (themes.php). And If so - what would be recommended way to detect if we are using core or installed version of editor without visiting themes via navigation?

[Mamaduka]

Is there going to be distinction between how you access Core site editor and standalone gutenberg editor?

When using the Gutenberg plugin correct Site Editor path is the themes.php custom page. This is because the plugin has to support an older version of WP (5.8) where site-editor.php doesn't exist, and it was the only way to make it compatible.

After WP 6.0 is released, we'll stop using the custom page, and there will be a single path for Site Editor.

Should site-editor.php still work as it did?

Yes, most of the time, but it's hard to avoid breakage when we have to make significant changes like this.

It looks like visitSiteEditor util only works for visiting editor and not template list page. So I would recommend using visitAdminPage directly for those cases.

[tomasztunik]

Thanks for the insights @Mamaduka!

So as we target current versions with our CI we should skip using themes.php and after 6.0 lands the tests should start working properly again - did I get this right?

For non site-editor.php navigation we were already using visitAdminPage so this was working as intended and this is why we did not see these navigation errors earlier - will loop the team in on this.

I think if this is known temporary state we can maybe close this and keep it for reference if anybody stumbles upon this as well.

[Mamaduka]

If you want to test with the Gutenberg plugin active, I recommend using the themes.php custom page to get the latest Site Editor working.

WP 6.0 is a few months away, but visitSiteEditor will be updated to use the correct path when it lands.

[tomasztunik]

Would you recommend the best way to detect on E2E side if plugin is active or if we are using core?

[Mamaduka]

I don't think we have got util for that. Usually, we active/deactivate plugins as needed before the specific test runs.

I've not very familiar with WooCommerce Blocks, but does it require or depend on features shipped in the Gutenberg plugin?

[tomasztunik]

Version included in Woo core is using only what is in core but for installed version we try to consume what edge provides as we want to push with FSE as much as we can. We do feature detection when enabling features to see what version of Gutenberg is available if we pick something from latest. That's where the tests against Gutenberg latest on top of core come from.

We'll figure a way to do the detection and will post update once we have it green again.

[Mamaduka]

Thanks. Let's keep this issue open for now.

[tomasztunik]

We've prepared a fix for now so we are stable woocommerce/woocommerce-blocks#6080. We will access site-editor.php or themes.php based on ENV var telling if Gutenberg is coming from core or if it's installed.

[gziolo]

@Mamaduka, does it mean that this file exists only to bring the site editor to WordPress 5.8:
https://github.com/WordPress/gutenberg/blob/trunk/lib/full-site-editing/edit-site-page.php?

[Mamaduka]

@gziolo, that's correct. We'll remove that file after we drop support for 5.8.

[Mamaduka]

@tomasztunik, can we close this issue?