29 Comments

  1. Nick

    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

    • Justin Tadlock

      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

      • Nick

        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

      • Tobin Ternet

        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

      • Jonah

        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

        • Justin Tadlock

          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

    • will skora

      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

      • Nick

        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

        • will skora

          ” 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

    • Nick

      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

    • Stephen Vaughan

      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

      • Stephen Vaughan

        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

    • Andrew

      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

      • Nick

        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. Stephen Vaughan

    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

    • richard Ginn

      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

    • Jonathan

      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

      • Stephen Vaughan

        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. Christoph

    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

    • Justin Tadlock

      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

      • Sjoerd van Heummen

        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. Sjoerd van Heummen

    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. Steve Grant

    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

    • Bastian

      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

    • Heinrich Göbertz

      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. Ani

    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. Brandon

    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

Comments are closed.

%d bloggers like this: