FSE and project vision in the long run

[tresorama]

It's not clear to me what FSE will be in future.
I opened this issue to be able to embrace the project vision.

I'm re approaching Wordpress after 2 years of React development.
I stopped using Wordpress when Gutenberg is introduced, and now that I'm coming back i feel a mix of excitement and confusion.

I'd like to have a solid overview to decide how should i develop themes for clients.

My doubts are these:

When witching theme what should happen ??
When switching theme what should NOT happen ??

When switching theme, template parts created with the GUI are not present anymore, should i export them and create a plugin out of them to preserve it across theme change ?? Or FSE is not built with theme switching in mind ??

If Theme Switching is an essential feature, this means that in the future, all the community will use a unique FSE theme that is responsible for defining all semantic token slot, and developer, with a child theme, will only provide a theme.json to define which primitive value (color #2A2A2A ) is mapped to which semantic token (bg-primary) ??

---

I was tempted to open this in "Discussion", but it seams to be little used.
Let me know if i should moved there these questions.

[carolinan]

I am trying to understand why you want template parts to be reusable when you switch themes?
I am not asking to be rude, but to gain understanding. These questions, and learning what the developers and users need, is important for continuous development.

Content should not be in template parts or templates, but in post types, like before.
There should be no content loss when you switch themes.

In a classic theme, your header and footer or other custom parts are also not persistent when you switch themes.

[carolinan]

My recommendation for getting a solid overview is to download the block themes from the theme directory* and look at what they have in common.
(* Because other block themes are proprietary, and it can be difficult to get access to their source to learn from).

[carolinan]

Related:
Theme switching flows tracking issue #39324

[tresorama]

Thanks @carolinan for the linked resource, it helped me to understand better.

I have been testing many block themes these days.
During my testing, after changing themes, I found that I had lost template parts previously created with GUI forever.

I actually messed up myself, thinking they were lost forever , instead I had forgotten which theme was active at the time of creation and, therefore until I reactivated that theme I could not recover them.

Mentally I thought that since they are user editable via GUI , these template parts were saved in a space related to the "user" and not the "theme".
But as you explained , the operation is similar to Classic themes , where the template parts are tied to the "theme".

I infer that, a theme developer who wants to create a block theme with FSE, after creating a template parts via GUI, copy the code to a file inside "theme-root/parts/xxxx.html".
This makes sense.

I apologize for the trivial question which is the result of my oversight.

[tresorama]

As for the rest of my original question i hope you could help me with this doubt i have about the future direction of FSE.

I have read in other issues that there is an attempt to standardize the semantic tokens that "themes" will then go on to use, in the same way that happens in theme T23 (Twenty Twenty Three) and its "Styles".
Let me explain further:

• T23 , in its theme.json defines the semantic token slots:
  • color primary, secondary, tertiary ...
  • font size small, medium, large...
• "Styles", which are nothing more than other theme.json placed in "theme-root/styles" directory, can replace semantic token values , but cannot remove them. Otherwise interchange between "Styles" would fail.

Therefore, in this theme there is a contract/interface defined by T23 and respected by the "styles".
Mentally it is as if T23 is a parent theme, and the styles a child theme. Sort of.

From what I see in some issues, I understand that there is an attempt to define that contract/interface at the "Site Editor" level, and therefore the "theme" will have to respect that contract in order to be interchangeable with other "themes".
So it would be like the Core Wordpress / FSE Editor acting as a parent theme and the "themes" as child themes.

Am i wrong ?
Is this in any way an official direction of the FSE project ?
Can I read about it somewhere ?
Or is it just a particular use of the FSE created specifically for the T23 theme ?

[carolinan]

You can read topics by labels in this repository, for example, overview and tracking issues.

[tresorama]

Exactly what i was looking for, thanks @carolinan.

Related labels:

[Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
[Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
[Type] Discussion For issues that are high-level and not yet ready to implement.
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json
Framework Issues related to broader framework topics, especially as it relates to javascript