Save theme edits from the site editor to the theme files

[draganescu]

Since the site editor can export a theme's modifications, it makes sens to have the ability to save (and hence alter) the current theme's files when edits have been made in the site editor.

However the goal is not to create the whole "file editor" thing again :) but to enable designers to visually update the theme. Therefore I suggest that this functionality be available only while theme.json has a "development_mode:true" flag. When that flag is unset the modifications can only reside in the database.

When editing a theme if said flag is true, we should have a new button next to "Save", or maybe a split button, with an optional "Update theme files". Clicking this button would enter a flow similar to the entity saving flow where all the files that will be updated are listed, and the user can choose which to not update.

[Humanify-nl]

The idea of a ‘developer mode : true’ and all the possibles this could potentially open up to enhance the developer experience… is very exciting!

[draganescu]

I am glad that sounds like a good idea. In #40385 I am exploring adding this wp-config.php constant to enable this functionality.

[javierarce]

Here's a simple flow based on a split button (which could be also useful to implement scheduling and drafting functionalities, as I proposed here)

Figma file.
Prototype

[scruffian]

After some investigation we decided that this should be kept in a plugin for now: https://github.com/Automattic/create-block-theme

[draganescu]

To add more context: some features which are important to DX but at the same time add a lot to the UX and provide little outside of specific workflows are better suited in a plugin.

In this particular example, the theme file management build as 1st class support in Gutenberg would force a few things, among which:

• add a whole system for file management via REST which does not exist
• commit to the shape of theme's folder and file structure so that file operations are forward and backward compatible
• commit to theme file content, which is the hardest to do considering how many things are still in flux (e.g. moving block CSS to JSON format is only one example).
• fix problems that appear when people edit manually markup that needs to be fed back to the machine (e.g. we'd have to unencode unicode chars so that code editing would be humanly nice, but that could easily trip the computer). What if the solution here proves to be that themes can be bundles of JSON instead of HTML?
• implement a host of other things to prevent a bad DX:
  • versioning
  • backup copies
  • blank theme creation
  • child theme creation
  • duplicate theme
  • handle edited themes that want to get updated from the directory

All of the above make from this seemingly simple change a project that speeds up some decisions, adds a lot of new surface to cover in terms of maintenance, and despite all this brings very little for the end user. Therefore it makes more sense to support these things (at least for now, until the editor and block themes become more stable and spread) in a plugin directed at theme builders of all kinds, and possibly highlight this plugin in the directory.

[Humanify-nl]

Thanks @draganescu for the feedback.

It makes a lot of sense to me, to keep this DX scope in a plug-in away from end users, while still offering theme authors the tooling to help optimize build workflow.

[carolinan]

Thank you for exploring this!

[carolinan]

@WordPress/block-themers @WordPress/outreach Is it time to revisit the decision to place this feature in a plugin only? This seems to be a blocker for many.
Can it not be a enabled when the theme WP_DEVELOPMENT_MODE flag is used?

[markhowellsmead]

Unless the developer is using a plugin, e.g. Create Block Theme, then adding functional controls to theme.json feels a bit like overkill. I feel that most users find the use of a plugin for this functionality more logical. The approach of using/respecting a constant stops theme.json from receiving technical controls: it should remain a control mechanism configuration file for design, layout, typography etc.

The constants are a better control mechanism, as these have been added to the system for developer-level technical control.

[carolinan]

Oh I am less interested in theme.json, I meant for saving changes to templates, parts, & patterns to the HTML files.

[markhowellsmead]

Ok, then I'm not sure about what is required here. This issue notes a request to add development_mode:true to theme.json. Assuming that the Create Block Theme plugin will continue to be maintained (which makes sense, as it's functionality which the majority of WordPress users will neither need nor want), I'm not sure that anything needs to change in core.