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?