-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Description
What problem does this address?
The current way block themes handle templates files is confusing and frustrating to work with as a site developer (who teams with a designer and builds for clients).
I'm sure it has to do with my understanding of how the block editor works with templates.
Yet, I'd like to point out that the documentation is not sufficiently addressing this topic. There seems to be a huge knowledge gap as to what core developers of Wordpress/gutenberg are assuming that we (regular wp devs) know, and what knowledge is actually described in the Block Editor handbook.
Editing templates
- I used clean TT2 as starting point to work from.
- I changed the html templates in my code editor ( e.g. the header with logo, site-title, menu - in case of TT2, I removed all the custom spacing), and uploaded the changes to the site.
- I open the site, but yet, none of the changes in the html file are represented. It seems the old template part is still loaded (huh?).
- I open the part in the site editor, and still see the old spacing code.
First frustration point:
Why are my template files, which are hard-coded in the theme NOT taking precedence over what users change, or whatever old mutations that were made before? And why are the changes we make in the editor not reflected in my theme files?
After some searching, I find that changes to templates made in the editor are saved in the database. So I went to the template overview and clicked the "remove the customizations' button. Then saved everything. This seemed to work.
When we add template mutations that were made in the back-end, why are these stored in the database, and not in a file in the theme?
I (and many others) are so used to the idea that:
- Our theme files are what controls the theme structure
- The database is used to store content of the individual site.
When these two are mixed I think all hell breaks loose in maintaining client sites, especially ones that already exist.
What is your proposed solution?
I don't know the best solution to this, I have a few pointers:
At least: There should be feedback in the interface that a template is saved in the database and not in the file itself. And this should be stated very clearly in the documentation.
Changes that are made to templates (in the theme editor) should be reflected in the theme files somehow. For instance look at how ACF does it with json files for each saved field. This system would be very manageable.
Let me have a folder in my theme where all these 'user-generated' template/part variations are stored that I can manage / change with code instead of having to do it for each theme I maintain in the editor.
This could be reflected in a list inside the template editor where we see in an overview specifically what the theme file is, and which variations are made.