Wp-calypso: Legacy Dotcom FSE: Atomic sites don't use FSE editor

Created on 5 May 2020  路  8Comments  路  Source: Automattic/wp-calypso

While testing a recent dotcom FSE change on Atomic sites, I went through the following flow:

  1. Go through horizon.wordpress.com/start/test-fse
  2. Verify that the dotcom FSE editor loads when editing a page
  3. Purchase a business plan with wpcom credits
  4. Install a plugin (I installed Yoast SEO) to start the transfer
  5. After the transfer, the dotcom FSE editor no longer loads.

I went through all of my old dotcom FSE test sites that I had previously transferred to Atomic, and none of them had FSE active any more either. In the blog RC, it said that FSE was not active because the theme was unsupported (even though the active theme was Maywood).

I would have thought we'd hear something from support about this 馃

Perhaps the issue is that the format of the theme name changed or something? Or maybe the FSE support sticker was removed from the theme?

[Goal] Full Site Editing [Pri] Low [Type] Bug

All 8 comments

I tried to debug this but I'm missing so much context. I don't really know what "dotcom FSE" means exactly. When I try to edit a page, I do see this:
image

Which makes me think that FSE is enabled and working. But I can also tell that you probably mean something else that I don't correctly understand.

To be able to continue debugging, I tried using the blog RC output FSE is not active for this site (using an unsupported theme) as a symptom of the bug. And I think the bug is this line.

The blog RC will say supported theme for any negative output, but the issue can be in either of these functions is_site_eligible_for_full_site_editing(), is_theme_supported() did_insert_template_parts();

Which makes me think that FSE is enabled and working

This does mean that the "FSE plugin" is enabled and working, but that is separate from "dotcom-fse". This documentation might be helpful for understanding what "dotcom-fse" means: PCYsg-rfB-p2. TLDR is that dotcom FSE is a legacy feature contained in the FSE plugin.

The code for dotcom FSE only runs if the function you linked to returns true. In short:

  1. The theme is supported (see my linked documentation for a list of supported themes)
  2. The site is eligible. For simple sites, a site is only eligible if it has the full-site-editing sticker. On Atomic sites, a site is only eligible if it has the a8c-fse-is-eligible blog option. (A blog option is used on Atomic since it does not support stickers locally. The sticker is transferred to an option during automated transfer.)
  3. The template parts have been created as CPTs for the theme. This happens when the theme is activated on the site during creation.

The weird thing is that all of these conditions are true before the atomic transfer (e.g. right after going through the dotcom FSE signup flow: https://horizon.wordpress.com/start/test-fse/fse-themes), but not afterwards.

This makes me think that some data is not being transferred correctly, like the sticker ->> option conversion (which was kinda flakey to begin with(

I checked this out on an ephemeral site, and all three were false to start with :p

You can ssh into ephemeral sites and edit in-situ, and then tail -f /tmp/php-errors to dump out values for debugging just like a sandbox.

I got caught out because I tried Maywood first. The Varia theme description includes full-site-editing in the tags(here),
so I thought any child theme would be fine, but it turns out that only only 3 themes actually set the full-site-editing flag:

 ~/a8c/themes (master) $ ag "add_theme_support.*full-site-editing"
exford/functions.php
104:        add_theme_support( 'full-site-editing' );

maywood/functions.php
104:        add_theme_support( 'full-site-editing');

shawburn/functions.php
104:        add_theme_support( 'full-site-editing' );

But I see now that the FAQ explains why so few support it.

Getting the theme right got is_theme_supported() and did_insert_template_parts() returning true, but wpcomsh is returning false for the a8c-fse-is-eligible option and disabling FSE as a result (in gh-wpcomsh, full-site-editing.php#L13).

If I force that on (I stuck a return false in wpcomsh_maybe_disable_fse()) then I get the edit hover as expected:

Add_New_Page_鈥筥My_WordPress_Site_鈥擾WordPress

That really just supports your sticker -> option theory, but I hope it's at least somewhat helpful.

If I get time I'll circle back around to investigate the transfer process, but I'm running out of week pretty fast.

Yep, no worries! Thanks for the investigation. I wonder if going through the steps in the original post (i.e. normal business transferred site) will result in no option existing on the remote site. I might try to check that today

I checked the DB of a transferred site (namely https://testingfseatomic21212122.wpcomstaging.com/) and the flag was there.

@vindl determined the cause of this here: https://github.com/Automattic/wp-calypso/issues/45287#issue-689023877

TLDR is that there is an option created when template part data is initialized which must be present to show FSE. This option is not transferred to atomic.

Our options are:

  1. transfer that option to atomic
  2. come up with another way to check for that data on atomic without needing to mess with atomic transfer code

I'd be in favor of option 1 for consistency. Also it's not guaranteed that alternative options would be performant enough for front end rendering, where this check is also called.

Given the very low volume of these sites, I think we should balance the time investment for fixes (I'm considering also just CLI interventions on case by case basis). In that sense the option transfer seems like a good way to do it. It should be a 1 line addition to whitelist the option.

Was this page helpful?
0 / 5 - 0 ratings