Wp-calypso: Site Editor: activation on Dotcom

[vindl]

So far we have been using blog stickers in order to determine whether FSE should be active on a given site. If the sticker was present we would force enable the FSE experiment in core and expose the links to it in wp-admin and Calypso.

However, after the latest changes in core this won't work as expected anymore. The experiment flag has been removed, and FSE will be activated when supporting theme is detected. That also means that site stickers won't work as expected anymore and we probably don't need them.

I think that the following steps here should be to:

• remove the FSE stickers logic and rely only on core mechanism for activation;
• expose new activation via existing or new API endpoint;
• use that data instead of stickers to determine whether we should tailor Calypso flows for FSE experience.

[ockham]

I think that the following steps here should be to:

• remove the FSE stickers logic and rely only on core mechanism for activation;

:+1:

• expose new activation via existing or new API endpoint;

To clarify, you mean an endpoint to query whether the current theme is FSE-enabled or not? Seems like that's not exposed yet, as detection is currently based on the presence of a file. But maybe there should be a theme_supports flag (that would then be automatically exposed by the themes endpoint)? cc/ @Automattic/io

Otherwise that information is currently only available through the __unstableEnableFullSiteEditingBlocks setting (i.e. in the settings global var) (and via gutenberg_is_fse_theme() on the PHP side).

• use that data instead of stickers to determine whether we should tailor Calypso flows for FSE experience.

Just to be sure, I think the current flows are mostly (Gut)onboarding related, which I think is largely unaffected by the change -- if the relevant flow is used (https://wordpress.com/new?flags=gutenboarding/site-editor), only FSE-enabled themes are shown for selection, so it's guaranteed that the user will end up with one of them, which will consequently enable FSE.

I assume you're referring to future flows that integrate the Site Editor more tightly with Calypso?

[vindl]

To clarify, you mean an endpoint to query whether the current theme is FSE-enabled or not? Seems like that's not exposed yet, as detection is currently based on the presence of a file. But maybe there should be a theme_supports flag (that would then be automatically exposed by the themes endpoint)?

Yes. theme_supports flag would make things easier for us so I wouldn't mind that either. :)

I assume you're referring to future flows that integrate the Site Editor more tightly with Calypso?

Yes, I was referring to things past Gutenboarding. If FSE is active we shouldn't show the Customizer and Site Editor item should be visible in the sidebar. This is the immediate need but we'll certainly have more in the future like opening pages in site editor by default or similar.

[Addison-Stavlo]

maybe there should be a theme_supports flag

Would this just be something we add in the after_setup_theme action, similar to:

https://github.com/Automattic/themes/blob/3992b5c9988d17ec64a3849ca225bbc315a505e4/seedlet-blocks/functions.php#L22

We would just need to agree on this approach and add this for (and make it a standard expectation for) every block based theme?

---

Also backing up a step to:

Seems like that's not exposed yet, as detection is currently based on the presence of a file.

Are we not able to do a similar file check from the dotcom side? Or would that just be overly complicated to support simple/atomic/jetpack, etc. where as the theme_supports would be more standard across all the integrations?

[vindl]

Would this just be something we add in the after_setup_theme action, similar to:

Yes, and I'd probably also add this to:
https://github.com/Automattic/themes/blob/3992b5c9988d17ec64a3849ca225bbc315a505e4/seedlet-blocks/style.css#L15

Are we not able to do a similar file check from the dotcom side? Or would that just be overly complicated to support simple/atomic/jetpack, etc. where as the theme_supports would be more standard across all the integrations?

I believe that @ockham meant that it's not exposed via API. It shouldn't be overly complicated - Atomic and Jetpack are practically the same as our localhost testing setup in that regard, so the only places were we are likely to run into some edge cases is Dotcom.

[ockham]

I believe that @ockham meant that it's not exposed via API.

Yep, that's what I meant :+1:

[Addison-Stavlo]

Yes, and I'd probably also add this to:
https://github.com/Automattic/themes/blob/3992b5c9988d17ec64a3849ca225bbc315a505e4/seedlet-blocks/style.css#L15

I wondered about that as well. A bit of a side note - Although slightly confused in the example of editor-style(s). It looks like its noted editor-styles when added in the setup_theme function, but just editor-style (not plural) in the tags. I think I noticed that consistent difference in a few themes, I wonder why that is 🤷‍♀️ .

[vindl]

I wondered about that as well. A bit of a side note - Although slightly confused in the example of editor-style(s). It looks like its noted editor-styles when added in the setup_theme function, but just editor-style (not plural) in the tags. I think I noticed that consistent difference in a few themes, I wonder why that is 🤷‍♀️ .

Maybe @kjellr might know more about this?

[kjellr]

Maybe @kjellr might know more about this?

I do! The WP.org theme repository has a standard set of specific theme tags, and their official tag is editor-style. I believe it's because it's actually named after the add_editor_style() function, not add_theme_support( 'editor-styles' ).

[Addison-Stavlo]

Thanks for clarifying! So is add_theme_support( 'editor-styles' ) unrelated to that tag then?

[kjellr]

That's right. A theme can technically use add_editor_style() without add_theme_support( 'editor-styles' ). That's how TinyMCE styles worked pre-Gutenberg. So my understanding is that the tag is for any theme that provides editor styles, for Gutenberg or TinyMCE.