How to persist user data across theme switches?

[oandregal]

What

In working on a few features such as:

• Manage typography font sets (PR): to allow users to save their own typography preferences, including the ability to upload fonts and select which fonts are available for the users of the site.
• Add user styles variations at the global level (PR): to allow users to create and save their own style variations.
• Consider whether the user palette should persist across theme switches.
• Consider whether we allow users to make their styles persistent across themes (unlike today, where user styles are theme dependent and cleared upon theme switch).

There's been a common thread among them all: how the user data they represent should persist across a theme switch.

Why

By considering these use cases together, we can suggest a solution that address all of these issues at once, and paves the way for future customizations.

How

The current theme.json algorithm considers the following origins of data:

• default, data coming from WordPress
• blocks, data coming from the blocks themselves
• theme, data coming from the active theme
• custom, data coming from the user for the active theme

The suggestion would be to create a new origin of data (name to be determined, but I'll run with site here), to be loaded later than custom, thereby its priority would be higher than any other layer. Both custom and site come from the user, though custom is theme dependent and site is theme independent.

The site data would be stored as a wp_global_styles CPT like custom is.

Questions

• Should the user data that is theme independent be used when the theme does not have a theme.json?
• How do we know where the user wants to store the styles: custom aka theme dependent (cleared upon theme switch) or site aka theme independent (wouldn't be cleared upon theme switch)?
• How do we tell apart the post that holds custom data and the post that holds site data?

[mtias]

I don't consider this being or requiring a new layer definition. This fits precisely in the "user" layer, from my perspective, it's just not coupled to a specific theme namespace.

[oandregal]

I don't consider this being or requiring a new layer definition. This fits precisely in the "user" layer, from my perspective, it's just not coupled to a specific theme namespace.

Right, that's true. Not sure about what name to use other than layer.

The important thing for me is that presets for the theme dependent data (custom) and presets for the theme independent data (site) are both available in the client independently. The rationale for this is that we may want to tell them apart in certain situations, such as, for example, listing the fonts uploaded by the user and listing the fonts provided by the theme separately.

[youknowriad]

Shouldn't we be consistent here, meaning if we removing the coupling for global styles, we should also remove it for the templates and template parts.

[oandregal]

Should the user data that is theme independent be used when the theme does not have a theme.json?

I've got a question, let me know your thoughts.

My first instinct is that no, this data shouldn't be used if the theme does not have a theme.json. In this scenario, the user wouldn't have access to the global styles UI to change the "site" styles, hence, it makes more sense that the "site" data is not used either.

[oandregal]

How do we know where the user wants to store the styles: custom aka theme dependent (cleared upon theme switch) or site aka theme independent (wouldn't be cleared upon theme switch)?

More braindump. For the first bits we want to implement (font manager or making the color palette theme independent) the UI flows will tell us where to store the data:

• Font manager: has a dedicated flow and the font list is stored in site.
• Making the color palette persistent across theme: would have their own flow as well. The data is stored in custom by default unless the user "makes it" theme independent, in which case is moved to site.

It seems the concept of theme-dependent or theme-independent styles needs to be managed at the UI level, for the user to declare their intent. At the infrastructure level, as long as we have two posts/data sources we can tell apart (custom vs site) we should be fine to implement whatever is required.

[oandregal]

How do we tell apart the post that holds custom data and the post that holds site data?

The existing post that holds custom data has post_type=wp_global_styles, post_name=wp-global-styles-${theme_stylesheet}, and declares its relationship to the theme via a term ($stylesheet) of the wp_theme taxonomy.

The new post to hold site data should still use the post_type=wp_global_styles but should not have any relationship with a theme. We could implement this in various ways:

1. No term for the wp_theme attached to the post. How do we query this post?
   1.1 We could set wp-global-styles-site as the post_name so we can easily query it.
   1.2 Alternatively, we could retrieve the post that has no term attached. This becomes insufficient if/when we have more posts with no term attached (for example, user style variations).
2. Still attach a term for the wp_theme taxonomy, but make it something like site-no-theme, which would be an unusual theme name/stylesheet. There's always a probability of clashing with a valid theme name.

I like the simplicity of 1.1.

Thinking of how to reuse a similar mechanism to templates & template_parts:

• They have the corresponding CPT: wp_template or wp_template_part.
• The post_name of the object is unrelated to the theme: header for a template part & home for a template, for example.
• They declare the relationship to the theme via attaching the corresponding term/taxonomy to the post.

Any of the approaches could be reused for templates/template parts.

[oandregal]

@matiasbenedetto started working on this at #50102

[oandregal]

There's a change of direction after this conversation #50102 (comment) Riad suggested exploring a different path. I'm going to close this for now to signal this is no longer "to be implemented". The conversation is documented anyway, we can always reopen.