Getting To Know the Upcoming WordPress 5.8 Template Editor

WordPress 5.8 is slated for release on July 20. In just over a month, many users will get their first taste of one of my favorite new features: template-editing mode.

The template editor is a new tool that allows end-users to create custom templates without ever leaving the post-editing screen. It exists as a stepping stone toward the eventual site editor, a feature that will hand over complete design control to those who want it.

The downside to the new feature in WordPress 5.8 is that users will not have access to their theme’s header, footer, sidebar, or other template parts. It is a blank slate in which they must put on their design caps to create the entire page.

With these limitations in place, what is the point of the template editor launching with WordPress 5.8?

Landing pages.

A blank slate is not always a bad thing. There is a reason all the best themes include page templates named Blank, Empty, Canvas, Open, or something similar. Sometimes users want control over the entirety of the page’s output. And WordPress 5.8 is bringing that capability to every WordPress user.

I have been editing templates for months now, but always in the context of a block theme. I have built both a photography portfolio and WordCamp landing page as part of the FSE Outreach Program. Despite some hiccups, it has been a worthwhile journey being involved as the feature has come to fruition. However, most of my testing was on top of the TT1 Blocks theme.

It was time to put it to a real-world test with themes that are actually in wide use.

Will It Work With My Theme?

The question many users will have on their minds will be: will this new template editor work with my theme? The answer is that it depends. Generally, yes, it will work to some degree. However, because older designs were not created with the template editor in mind, not all experiences will be the same.

I wanted to really put this theory of working with every theme to the test. So, I loaded up Twenty Fifteen, one of my favorite default themes from the past decade.

Perhaps I jumped too far back.

Screenshot of a landing page built with Twenty Fifteen.
Twenty Fifteen has a two-color background meant for sidebar and content.

The block editor did not exist back when Twenty Fifteen was built. Its use of a box-shadow technique on the page background meant the entire page had two colored columns running down it. The design team had to use some hacky methods for equal-height sidebar and content backgrounds. Ahhh…the good old days before developers had access to CSS flex-box and grid.

It is these sorts of problems that could limit some older themes. In the case of Twenty Fifteen, I could hide the background with a Group or Cover block over the top of it.

Users will likely get better results when using something more modern, at least a theme built during the block era. Even something as simple as wide-alignment support will change the WYSIWYG nature of the template editor. If a theme does not support the feature, the front end will not match the editor.

I jumped ahead a few years. Twenty Nineteen was the first default WordPress theme to support blocks. It is old but not ancient in internet years.

There are some differences between the editor and front-end views. The Cover block padding is off, the vertical spacing does not match, the search input’s font size is different, and the search button’s border radius is round on the front end. However, it is nearly a three-year-old theme now. It held up better than expected in this simple test.

Jumping ahead a couple of years, I activated Twenty Twenty-One, WordPress’s most recent default theme.

The editor is a pretty close approximation of what you see on the front end. The most noticeable differences are the inconsistent padding for the Cover block and the light gray border for the search input field in the editor view.

It was time to put the template editor to the “real” test. I activated the latest version of Eksell, one of the most well-rounded block themes in existence.

Obviously, the theme outputs a black section on the left. That is intended for the theme’s sidebar/menu flyout. However, because the user has no access to the template part that outputs that element, it may be impossible for some to create custom templates with this theme. I am sure that Anders Norén, the developer, will address this problem.

Similar, unknown issues will arise with the many thousands of themes in the wild. It does not mean a theme is necessarily bad. It just means it was not built with the template editor in mind. Users may need to throttle back their hopes a bit until they have thoroughly tested template-editing mode with their active theme.

Oh, and that ugly whitespace that shows the content background at the top of the editor? You will see that with literally every theme. I am clueless as to why the development team thought that it would make for a good default. Nearly every web design I have looked at over the years zeroes out the page’s <body> element padding.

For those theme authors who are reading, you will need to deal with this. If you have already been building for the block editor, you are likely a pro at handling such quirks.

If we look at a custom theme I have been building, you can see no alignment issues between the editor and front end.

The difference for my theme is that I am building when the template editor is already a part of the Gutenberg plugin. The others were all created earlier. It is not fair to compare them. However, users should know that older themes might not work well. They may need to wait for updates or try out a fresh design before taking advantage of template editing.

I also chose Twenty Nineteen, Twenty Twenty-One, and Eksell because they were designed by professionals in our industry and were released in the last few years. They each hold up well but have a few issues that would be trivial to fix.

All of this is to say that results may vary — wildly.

The Ideal Way To Use the Template Editor

My fear with the template editor is that users will begin mixing their content directly into the editor. It is an issue I brought up during round #7 of the FSE Outreach Program. Ultimately, it is a question about the boundary between content and template.

Traditionally, theme authors would build custom templates for their end-users to apply to their pages. Unless those users knew how to make direct code changes, they only selected the template and edited their own content via the editor. It was always clear where content editing ended and template editing began.

The new mode muddies the waters a bit. Because users have direct access to change the template from within the post/page editor itself, I have no doubt that many will create the entire page’s content from within the template editor.

Even I made the mistake of putting what would typically be content in my example templates above. This was purely for illustration.

There is nothing wrong with this if it the user’s intention. However, templates are generally meant for controlling the layout of the page. Things like the header, footer, and content wrapping element belong within it, while the content itself is stored separately. Templates are also meant to be reused. If you apply the same template to multiple pages, any changes made to that template will update every page.

My recommended starting point is to simply add the Post Content block to the template. You can do so from the block inserter or by pasting in this code snippet:

<!-- wp:post-content {"layout":{"inherit":true}} /-->

If you just want a blank/empty template, which is what the editor is good at right now, this is all you need. You can move back to the page editor and unleash your creativity.

Here is the start of a novelist landing page I built from this blank template:

Landing page for a novelist with featured hero section and latest books section.

The content of the page was added via the post editor rather than in template-editing mode. This will allow me to create multiple pages using the same open canvas.

If you want to add other layout elements, you can tack them on too. Try mixing and matching the Site Title, Site Tagline, and Navigation blocks as a header. Drop in a Columns block with other blocks to create a “widget area” in the footer.

The power of the template editor is coming with block themes. Eventually, designers will be able to pre-build these templates, and users will customize them. They will also have access to a more robust suite of blocks, such as loading up template parts. However, we have to wait until at least WordPress 5.9 later this year before they become available, and that is not set in stone yet.

Until then, we have a sort-of-OK-but-kind-of-amazing landing page creator.

29

29 responses to “Getting To Know the Upcoming WordPress 5.8 Template Editor”

  1. I want to keep this as short as possible, so I’m going to skip for now many issues and bring up only the most important ones (for now)…

    Most of us develop sites in a localhost environment. When we use FSE to create or edit template pages/parts, those designs do not get written into files, but get stored in the database. When done, and the fully customized theme is to be delivered to the client/live site, we just cannot package the theme files, we also have to export and then import the Templates, the Template parts & the Global Styles from the Tools menu – not a big deal for most, but many will have issues with this, as a simple Theme installation will not work in this case.
    Patterns: They are great in theory, but because the whole Gutenberg project is not planned and built correctly, very naively if you ask me, there are some issues:

    a. Lets get to the purpose of patterns – to save you dev. time. But because Gutenberg does not have universal padding/margin, and block basis custom CSS coding facilities, all we can get out of the box are weak, pathetic and embarrassing patterns. Putting 2 buttons next to each other, and serving that as a pattern does almost nothing in terms of time saving. This is causing 2 major issues: The first one is that many third party blocks provide their own margin/padding/animation/css controls, which makes the whole experience very chaotic and not uniform. For each block library you have to learn where everything is, as oppose to a one nice Core universal UI.

    b. And then we have the Hansen theme from the theme repository. Very nicely done, which comes with some nice patterns. Because Gutenberg lacks all the features mentioned above, the theme uses some custom CSS classes, and these classes are coded in the theme’s style sheet. The problem with this is that now that you have used these patterns, YOU ARE LOCKED IN to this theme. Because the moment you change themes, the new theme will not have these custom classes defined, the patterns will be broken. This is THE SAME reason why shortcodes were outlawed many years ago from inside the themes – and yet when it comes to patterns, this is somehow allowed??? Will custom blocks be allowed in themes next?

    The site templating system does not allow third party blocks, we are limited to what they allow us to use, WHY?
    The menu page is gone, that’s semi ok, as we can do custom menus from the customizer, but the customizer screen can now only be accessed from the Themes page, with a button on the Theme preview image – WHY??? Now you can create custom menus, and tell the Navigation block to show it, but they are not connected. Once you add a new page/link in the custom menu, the new links don’t show up in the nav block. At this point you have to add the link in the nav. block manually (again), or delete the Nav block, and start a new one, to get the current links from the custom menu.

    I know that this whole thing is not done, so I can’t be very critical, but we are a month away from confusing anyone who is not following the project, and many issues could have been avoided, it the foundations of this project were built correctly. I don’t think there are any serious page builders that don’t have padding/margin/css controls, except Gutenberg of course.

    P.S. I also wonder what happened to “decisions, not options”, as almost all decisions are taken away from the themes and are given to users, which will result in many ugly site designs, and confusion. Last thought, are boxed themes even possible with FSE? I can go for 3 more weeks ranting… at least !

    My criticisms are to be used ONLY in a constructive manner…

    Report

    • Most of us develop sites in a localhost environment. When we use FSE to create or edit template pages/parts, those designs do not get written into files, but get stored in the database…

      I would not recommend that theme shops, agencies, or freelancers build themes in this way, at least not at this point. I certainly wouldn’t. It seems like a recipe for a lot of headaches.

      Last thought, are boxed themes even possible with FSE?

      Definitely. I just boxed my theme in about 30 seconds:

      Boxed theme design.


      Agreed on a lot of the weak areas. Margin/padding controls are limited to just some blocks right now. There’s a ticket for a global spacing value, but I doubt that makes into 5.8. All of those foundational issues are going to play out in patterns.

      I have more thoughts on the foundational issues creating theme lock-in. At this point, I don’t necessarily think it’s a bad thing — or, at least, I’ve given up on my hard stance against it. That ship sailed with the launch of WordPress 5.0. I’m not sure if there’s any turning back. But, it’s late. I’ll consolidate all of those thoughts into a more coherent and organized post.

      Report

      • Thanks for your thoughtful reply Justin.

        I’m really looking forward to your more coherent and organized post, no doubt that FSE will serve some very nicely, but it needs a lot of growing up.

        I love Gutenberg, nevertheless, I just wish it came with much better developer documentation, if they want more of the theme & plugin shops to adopt the project.

        The worse part is the constant naming, coding, and CSS changes that forces us to fix our code with almost every Gutenberg update, where many times nothing is being mentioned in the change logs. The undocumented code changes in the Matrix Control Component from about 2 months ago is just an example out of several dozens in the last 2-3 years. This constant changes is the main reason why the project is slow getting adopted by developers. It’s one thing to develop new things, but going back in to constantly fix things that was working before, is maddening.

        Report

      • I would not recommend that theme shops, agencies, or freelancers build themes in this way, at least not at this point. I certainly wouldn’t. It seems like a recipe for a lot of headaches.

        This is very common approach. Surely you don’t suggest people develop on the live site. If replacing an existing client site with a new one, or even developing an entirely new client site, what do you suggest?

        Report

        • We’re not talking about the development environment. We’re talking about storing templates, and there is currently no common approach to that since block-based templating is in a beta stage.

          Report

      • What about Flywheel’s Local app? These setups are very common and with this being Beta it should be considering this. I can’t imagine bigger software project like Windows saying, “We’ll figure out data storing later, this is beta.”

        Report

        • I’m just old-school and prefer working from a code editor. No one needs to let my preferences dictate their workflow. :)

          The system lets you export templates if you prefer to develop from the UI. It was an early feature of the site editor, so it’s been around for a while.

          Report

    • Great points, Nick. I’ve been concerned about the decision to store templates instead of within the file system of templates when I first learned about FSE and made an issue how the ‘syncing’ of templates should be addressed;
      https://github.com/WordPress/gutenberg/issues/22469

      It’s been under such rapid development over the past few months and, documentation is inadequate although it has improved.

      Report

      • That is a very interesting point Will, and the problem you describe on GitHub should have a two way solution. You want changes made in the static html files to “sync” with the database somehow, as I want is really the opposite. I want all the templates and template parts stored in the database to be exported, probably with a button and not automatically into html files, so we can just package the Theme in zip file (which will include all the changes, new templates, etc…), and pass it along.

        Which brings us to the next point: How do you make child themes for these block based themes? I know it’s possible, but I had no luck creating one for the Hansen theme, I even used the “child-theme-generator” plugin which works for regular themes.

        Report

        • ” I want all the templates and template parts stored in the database to be exported, probably with a button and not automatically into html files, so we can just package the Theme in zip file (which will include all the changes, new templates, etc…), and pass it along”

          You can export your templates, templates in your theme and export them to a zip :) It’s done using the ‘export’ button in the site editor

          (NOTE: it’s been several months since I last did this so it may have regressed since then ;))

          Report

    • BTW, I forgot to mention that we can disable the Templating system with:

      remove_theme_support( 'block-templates' );

      Tested it with latest Gut installed and WP 5.8 beta 2. It works, that is, for now !

      Report

      • Thanks Nick. I’ll keep that in mind if I see the need to clobber this block editor feature.

        Report

    • Hi Nick,

      I’ve been thinking about your observations for the last number of days and as for the inconsistencies you mention, these highlight some of the weakness in the block editor, once you push its abilities beyond simple content creation.

      Spacing is a good example. At the moment there is a plethora of third party block solutions, all doing the same thing but from what I can see, engineered in different ways. If any of these plugins gets disabled or abandoned, it seems that there is no logical way for another third party alternative to slot in and take up the mantle.

      This point to a major gap in the rational of how the block editor works. From the start a strict set of block types should have been established, those for discrete elements: paragraphs, headings, dividers, etc and then those for structure and layout: sections, containers, rows and columns. To these foundational elements all the styling points, like for spacing should have been added. On simple themes these finer points of styling could be hidden, controlled by the theme. Beyond this, an API or hooks. Could be used by third parties to open up all the styling possibilities, bells and whistles and even allow for page builders to add a better more sophisticated UI.

      I add the last point, because, even though currently many page builders are slow to the races in terms of performance, usability is far superior than the block editor.

      This may change by the way for one builder in particular. If successful said builder is due for a complete under-the-hood re-engineering, similar to how the block editor delineates itself with comment tags. I understand that this won’t be a full integration with the block editor and I understand why. Looking back up to my point on the block editor not sticking to a strict set of block elements, there is no point doing this.

      As it is, with all the different block options offered by third party vendors we may end up in the same Heath Robinson space that the block editor was supposed to avoid.

      Report

      • Hopefully this design error will be reversed once the Blogic becomes evident.

        Blogic: logic that has bad rational. Derived from the word Brexit and logic, based on no rational other than disruption, designed to culminate in in un-resolvable quandaries.

        Report

    • Hi Nick, as the author of the Hansen theme, part of my thought process when creating the theme was to highlight issues such as you describe. I’m glad you brought this up because my hope was and still is that greater minds will find solutions to address the issue of layouts in patterns being changed/broken when switching themes. Apart from the custom pattern classes, the theme now works pretty well with the stylesheet removed, thanks to the progress being made with Gutenberg. For my next block theme I am aiming for an empty stylesheet, with fully 100% of the CSS rendered by Gutenberg/core.

      I do have to disagree about being locked in however. Design/layout lock-in is not the same as content lock-in. With theme patterns and the custom styles that may sometimes be found in these patterns, the user’s content is not lost when switching themes which would be the case with custom blocks or shortcodes. The content is still present*, only the design/layout may have changed. *The exception is images in patterns but it is expected that the user will change the placeholder image for one of their own.

      I am reasonably certain that custom blocks will not be allowed in themes submitted to the official themes directory. Not right now anyway. If at some point in the future it was possible for custom theme blocks to be retained when switching themes, I could see this rule being reconsidered, but I’ll admit I don’t know if this is or will ever be possible.

      To your last point about the confusion of so many options. I see this as a good thing. WordPress design will become much more democratized like never before. If a user wishes to create an ugly design, that is their right to do so, even if it is in the pursuit of creating a beautiful design. It is right to let users have this option. There will be entrepreneurial designers with the flair to design a great site without necessarily needing the coding knowledge that may have previously been a barrier.

      Report

      • Andrew, LOVE your work. The Hansen theme is by far the best FSE theme I have come across, and I’m making it as my “starter theme” to create and further customize to function the exact way I want it. Also, all the extra templates you provide that I don’t see in other block themes are the icing on the cake.

        I agree with everything you said, my gripe about the options thing, is that for years, they told us religiously about “Decisions, not Options”, and also don’t mix content with design, as some years ago, they removed from the core the ability to add custom margins to the images, because image margins belong ONLY to themes. Now, without any apologies, they made a complete 180 degrees in these philosophies, and came over to my side of the argument, which I always advocated for options. They told us to use the Customizer and not theme option screens, only to deprecate it now, again, without any apologies.

        I don’t dislike what the developers are doing, I just wish they prioritize things better.

        Report

  2. It all sounds very messy and confusing. I really do wonder where WordPress is going with the block editor and full site editing when page builders (and Toolset) have already cracked this nut. It’s like some mad experiment in doing things differently and they are trying to prove something.

    Report

    • Gutenberg is trying to be like WIX and Squarspace but is late to the game here.

      Although Gutenberg is moving along and getting more powerful it is still well behind DIVI and elementor in functionality. FSE is great but a bunch of other page builders including DIVI and elementor already do that in some way as well.

      Report

    • Thank you for mentioning Toolset. I have searched it and it is the plugin I was looking for.
      Besides returning here to thank you, I ask: how do we discover excellent used plugins? Apparently, WordPress and CodeCanyon is not enough. Is there any other gem used by thousands that I do not know yet?

      Report

      • That I don’t know Jonathan. I discovered Toolset years ago by working with somebody who was already using it. In terms of blocks, Toolset does a reasonably good job at usability when it comes to previewing and styling for the three main viewports. That being said I still prefer to use Toolset mainly in it original pre-block incarnation of pure html/css/js roll your own templates and views.

        As for finding stuff for WordPress, it’s a bit of a jungle out there beyond the main plug-in repository.

        Report

  3. Shipping the Template Editor as opt-out with 5.8 is going to cause a lot of issues IMO. I guess most sites out there (that use Gutenberg so far) are not prepared, and users are eventually going to the find the Template Editor and play with it, and it’s basically going to mess up their layouts and thus sites. This is again a premature feature, shipped for the sake of getting it out there. I’m definitely going to have to deactivate it on all existing client sites, until maybe some day they will be updated to properly work with it.

    I’d love to see more Gutenberg features shipped as opt-in, so devs can use those features in their new projects when needed, but are not forced on handling all new use cases on all of their existing sites.

    I am definitely pro-Gutenberg and fully using it on all new projects, but it’s just unrealistic to keep updating all existing sites with all the new features that come out.

    Report

    • WordPress has not traditionally shipped major features as opt-in. You don’t get the usage and feedback you need by hiding it away.

      The template editor is mature and ready to ship. The problems I covered above are theme issues, and you’re always going to have those issues until themes catch up. Making it opt-in will only slow that growth. It’s been the same with nearly every front-end feature that’s come to WordPress over the years. Core ships something and theme authors add in support for it.

      Report

      • Thanks for clearing that up Justin.
        Makes indeed complete sense to collect as much feedback as possible.
        Hopefully a plug-in will follow then to hide these options from absolute beginners… from my experience with many WordPress students they have already enough to deal with all the new GB block possibilities on-page and in the widget areas.

        Report

  4. Indeed I think also for most end users template editing is overkill and confusing.
    Providing a standard way of working for webdesigners and third parties can be helpful though.
    Maybe by default hiding these more advanced options and give an option to enable/show…

    Report

  5. Two points

    Firstly on the focus on the Wix/ Squarespace market.
    I can see the excitement for small one-person businesses to be able to edit their templates in a GUI. That’s probably exciting for a one-person business and for that Wix market I see the point.

    I’m doubtful that companies with 40+ employees who have a bespoke solution with signed off layouts will want their junior staff to get creative with templates.

    So my question is : what focus will the WP core team have on supporting the corporate website market?
    I develop sites for mid sized companies, where the editor is simply a junior team member tasked with pasting a word doc into an approved design (and choosing one of 3 layouts). This is quite a large market, and I wonder if the WP core team think about that market at all? Nothing in FSE adds value for that market.
    Most of what I see for corporate sites is in de-activation hooks! That’s not too thrilling.

    Please imagine what a time-pressed office junior needs in the way of layout selection and imagine their slender knowledge and interest in design terminology and brand consistency, we need tools for those people!

    I’ve explored what’s coming. I’ve built a test FSE Theme to see if it adds value, and there was nothing there. None of my client editors are going to edit the header, or footer, or page templates … ever!

    Secondly about the pattern library.
    I’ve said previously on here that corporate site editors (often interns) get supplied with a few official layouts to select from, and now they will also get “patterns” from me. Two issues here: lay people don’t understand the term “patterns” as ” a chunk of layout” they think of that as “layout” or perhaps if they are a bit technical and paid attention they call it a “template”. So the pattern section is confusing to them. They imagine it to be full of cross-hatching grids, and tessellating backgrounds. “Design patterns” means something else to a junior staff member who has been suddenly given a job as a content editor (armed with a “How to edit the corporate site” PDF and 5 minute intro video).

    The focus on letting users create their own templates in a GUI and learn what a “pattern” means is of course fun for small businesses of 1 or 2 people – but in larger corporations the idea that the unskilled Editors might have control of this on a corporate site with signed-off branding & designs is in nobodies interest.

    I can’t find much official guidance about supporting that scale of site in all talk of FSE. Everyone is so excited about fighting in the Wix space.

    Is there to be any focus on solutions for the corporate web space?

    Report

    • Is there to be any focus on solutions for the corporate web space?

      I’m afraid not. Those of us developing and building sites for clients have been in the bottom of the scale for the WP team since Gutenberg came out more than two years ago. There’s still no adequate means to lock designs and no satisfactory way to migrate custom post types with lots of meta fields to the new editor, things that are essential for client work. Add to this the constant changes to the API and the really poor developer documentation and it’s hardly surprising that the interest in the block editor among the developer crowd is not that substantial.

      Report

    • The future focus on real world usage of WordPress besides some “single user admin three pages and/or personal blog once in a while” stays obviously unchanged from current focus.

      FSE is of no use for >90% of our clients who use WordPress as title & content fields, copy & paste, then publish & done. Some do not even know that they are using WordPress as all the rest is not available for their customized role.

      Report

  6. I don’t know what the issue is but the new release of WordPress 5.8 has compatibility issues with elementor, that is the only error I have noticed for now.

    Report

  7. Is it just me? If appears in the editor when you are writing posts the default stylesheet is not functioning?

    For example, blockquotes in the editor used to have a black line on the left to indicate it was a blockquote. That’s now gone along with line-height which makes it all boxed in… Not sure what needs to be done here…

    Report

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: