Gutenberg: How to sync edits made within a theme's HTML files to the Block Editor (Full-site editing)

[skorasaurus]

As I experiment with the theme editor more, I realize that there's still a lot of aspects of the theme editing process that haven't been already articulated yet in the theme outline. Since the editor is a remarkable change in WordPress, articulating these decisions, is important to prevent mistrust and skepticism from continuing.

We should still be able to edit theme components (templates, etc or even the global themes json file that is coming) through a separate file editor outside of Gutenberg and have those changes immediately reflected in the theme.

You're taking away a long used feature by theme developers and internal agencies that manage a site's theme by modifying files within a separate file editor (e.g. vs code, sublime, vim) and have those changes immediately visually reflected in their site.

Several use cases that this enables or facilitates:

• quicker version control of themes (I don't think this can be understated).

• Automation: By ensuring theme files are file-based and are reflected in the website; changes can be made in a separate environment and they can be quickly deployed to the production website through a variety of means: Gitlab/Github actions, travis-ci, rsync, FTP, etc; without altering the database.

I do this pretty often; for example, tweaking template php file (e.g. removing a sidebar) on my local environment and then upload template file by FTP; instead of directly editing on production and without disrupting the production website.

One simple use case of what I am asking is to be able to modify a page template that's exactly the same as an existing one, remove the footer, or add sidebar blocks to that template without having to make several clicks through the GUI.

I understand that there are separate audiences for Gutenberg:
one of those audiences are users who aren't comfortable with even basic html and would solely use gutenberg but there are also many users who are more comfortable through separate file based editors.

The flexibility of WordPress is a key reason why WordPress has managed to be relatively attractive to users across various levels of technical ability with differing preferences.

Being able to edit the layout of your website through a GUI like the customizer and widgets screen as well through a separate file editor is one great example.

(speaking personally, not as an CPL employee).

[vindl]

One simple use case of what I am asking is to be able to modify a page template that's exactly the same as an existing one, remove the footer, or add sidebar blocks to that template without having to make several clicks through the GUI.

Would this be fulfilled by having the code editing mode available in the site editor? (https://github.com/WordPress/gutenberg/issues/22528)

Currently those edits would be saved in wp_template CPTs, although we could look into saving them alongside block template html files that themes provide. I'm not sure if editing the default ones is the best way to go about it since those changes might be overridden during theme updates.

[skorasaurus]

One simple use case of what I am asking is to be able to modify a page template that's exactly the same as an existing one, remove the footer, or add sidebar blocks to that template without having to make several clicks through the GUI.

Would this be fulfilled by having the code editing mode available in the site editor? (#22528)

Currently those edits would be saved in wp_template CPTs, although we could look into saving them alongside block template html files that themes provide. I'm not sure if editing the default ones is the best way to go about it since those changes might be overridden during theme updates.

Although the code editing mode in the site editor, I'm afraid this would not be really fulfilled by code editing within the site editor.

While I occasionally use the code editor (and it's helpful!) to make small edits to blocks, a couple common use cases that the code editing mode in the site editor wouldn't be applicable:

• need to made a new template but without a sidebar for example.

With FSE as of now:
log into the website; go to the template editor, copy the block code; create a new template; then copy in and save as.

With local file-based editing:
I can open my local file editor, open the template, edit it, save as a new template with a different file name (and commit it to a git based repo), and upload (which I can do with a one line alias in my local developing machine).

How are larger agencies and enterprisey like companies working on this? I can't imagine that they are making edits of site design and template directly live on production nor for you to expect them to do so.

[carolinan]

I don't understand. I don't read any distinction between the different kinds of templates and template parts above.

Are you saying that local file based editing is not working? At all? Are changes you make not reflected in the templates?
_This has been buggy for me_ in different plugin versions but seems to work well now.

-I don't see what could prevent you from editing the .json file for global styles.

Or, did you mean that local file based editing does not work after you create/save a template/template part in the site editor (Because no local files are created)?
-The files are not created until you use the export functionality.

[skorasaurus]

At the time that I created the issue, I hadn't found any documentation whether local file based editing + syncing would be supported at all since I had read that edits made to templates within the GUI site-editor https://github.com/WordPress/gutenberg/issues/19260 had to be exported to local html files.

I was wondering whether local edits to a theme's html files would be automatically applied to the theme at all or if I had to go into the site-editor GUI to import any changes made to the html files locally.

[carolinan]

Does it mean the issue is resolved?

[vindl]

I was wondering whether local edits to a theme's html files would be automatically applied to the theme at all or if I had to go into the site-editor GUI to import any changes made to the html files locally.

I think I understand the gist of the issue better now. Yes, edits to theme's template and template part html files should be reflected both in the editor and in the fronted. There is one caveat though - if these have been modified within site editor and saved as CPTs (wp_template or wp_template_part) these will override the default theme html files so the file changes would not be visible.

So local file based editing and syncing will work as long as those CPTs are not present. It's entirely possible to change everything related to theme provided templates and template parts just by editing the files, without the need to access site editor.

[pagelab]

So local file based editing and syncing will work as long as those CPTs are not present.

This means that, in practice, a theme is just a starting point. That's an issue if the theme code needs to be updated in a way that is not possible using the UI.

For example: at the moment the UI does not allow me to add a data attribute to any tag. If, for any reason – technical or whatnot – I need to update the theme to add it, the update will not be applied if its CPT counterpart has been changed.

In order to apply it, the user will either have to delete his/her version of the template or change the structure manually, using the code editing mode, which can be cumbersome.

I'm sure that there are other cases where the ability to update the site code via a theme update would be quite useful.

The new block system is awesome in a lot of ways, but this issue is a downgrade in user experience compared to the current theming system, IMO.

Developers will lose direct control over the actual code used to render the site, and the responsibility for applying changes to the code that are not possible using the UI will be transferred to the user.

[vindl]

For example: at the moment the UI does not allow me to add a data attribute to any tag. If, for any reason – technical or whatnot – I need to update the theme to add it, the update will not be applied if its CPT counterpart has been changed.

That's right. This is a hard problem to solve in general. I don't think it would be good to completely overwrite CPT content during update, because that will change the site layout and remove any user created template customizations.

In some cases the element that you want to update might have been removed via UI customizations, so changing it would no longer be a concern. In others when it's still present in CPTs, we don't have a way to differentiate theme supplied blocks from the ones added by users afaik. So solving this would require merging the two template contents (updated on from the theme and CPT) in a seamless way, but that too can fail in general case due to merge conflicts which require manual intervention.

I'm curious if you all had some ideas of how this could be resolved?