16 Comments

  1. David McCan

    Would it make sense to have the ability to create post type templates first? For that we would need placeholders for title, featured image, content, post meta fields, comments, tax terms, related posts, read more, and navigation blocks for singe and archive. Toolset Blocks has this now, which might provide an example. It doesn’t use HTML templates.

    There are also a couple of themes with header and footer builders, like Blocksy, that might provide an example here.

    And the latest Elementor beta added some global styling options which might also provide some ideas.

    Perhaps the Customizer would be a place where you have a page or set of pages with content like the theme unit test data where you could set global style options for buttons, tables, quotes, etc.? Or override the theme’s defaults.

    Will block-based theme’s have hooks for replacing the theme’s default header and footer? Or will the theme have block areas like we currently have widget areas?

    Report

    • Justin Tadlock

      Would it make sense to have the ability to create post type templates first? For that we would need placeholders for title, featured image, content, post meta fields, comments, tax terms, related posts, read more, and navigation blocks for singe and archive.

      I don’t think it matters if the CPT/user-created templates exist first. As far as the underlying code for that goes, it’s super simple to add a check for the theme-based templates at the same time.

      But, we definitely need many, many more placeholder-type blocks that essentially replace template tags.

      Perhaps the Customizer would be a place where you have a page or set of pages with content like the theme unit test data where you could set global style options for buttons, tables, quotes, etc.? Or override the theme’s defaults.

      From what I’m seeing in this ticket, it will be a part of the block system rather than the customizer. It would be nice to see a comparison between the two before any final decisions are made.

      Will block-based theme’s have hooks for replacing the theme’s default header and footer? Or will the theme have block areas like we currently have widget areas?

      That’s an interesting question, and I think it’s one of those that does not yet have an answer.

      Report

  2. Andreas Nurbo

    From what I understand of this recap is that Automattic has already decided the future and the non-Automatticians can just disconnect their keyboards and go home and not waste any time in more meetings. Were there any non-Automatticians in the meeting at all? Not based on the quotes except for the last one about themes not going anywhere by Ari Stathopoulos.

    Gutenberg Automattic team has decided and that’s it. No matter that the whole block based theme system is bonkers, who cares, Gutenberg storage method was bonkers from the get go and now the Core team will expand the bonkering to other places of WordPress.

    Report

    • Justin Tadlock

      The three people presenting were Automatticians. However, there were many others who participated in the meeting. The #themereview channel is a diverse group of people who don’t often hold back their thoughts. Given the first half hour was an introduction in the first meeting, it leaned more heavily toward those people doing the presenting. I suspect we’ll see a lot more variety throughout the entirety of future meetings.

      Report

  3. Gregg

    Every last bit of this is horrible. Gutenberg is still a horrible mess and a UX/UI nightmare. Every WordPress I work on, which is far too many, gets Classic Editor and Elementor.

    If Automattic were always planning this, which it seems like they were, then they should have just attempted to buy Elementor and bring it into core instead.

    Report

    • Justin Tadlock

      I wholeheartedly disagree. The block editor has been a game-changer for me. Before taking this job as a writer, I was able to switch many clients and less tech-savvy friends/family over. They finally had an editor that allowed them to do some of the more complex things they had in mind without having to rely on shortcode soup or learning to code. And, personally, I finally found an editor that is a lot nicer for actually writing within in comparison to classic.

      Nevertheless, this is not the topic at hand. The discussion is about how themes will work going forward. We do not yet have the UI in place for it.

      Just to be clear, the plans do not belong to Automattic.

      Report

  4. Tro

    While I enjoy page-building with third-party block sets (but not the useless core and Gutenberg plugin blocks), I’m just wondering why Automattic didn’t think of expanding on the customizer instead. It’s UX is infinitely better than the block editor. And themes such as Neve, Suki, Customify, and Blocksy have amazing header and footer builders.

    (Fun fact: Neve’s header/footer builder actually mimics Gutenberg.)

    Automattic had a good thing going when it was moving everything (like widgets and menus) to the customizer. Neve and Suki themes even have their page header options in the customizer so you can see your changes happening as you do them. Themes like Colibri WP and Mesmerize turned the customizer into all out page builders.

    Automattic could’ve turned the customizer into an open source page builder.

    Unlike Gutenberg, you can actually see your website as it is in the customizer, and you can see your changes instantly without opening a new tab and refreshing every five seconds like the old primitive way.

    It would be a real shame if the customizer goes.

    Gutenberg’s narrow document-like view cannot serve as a replacement for the customizer. It just can’t.

    It’s only good for writing blog posts. That’s it.

    Here’s an idea. I think the customizer should be merged with the block editor. When you add a new page (not post), you should see your whole website as it is (not the narrow document view). The left side dashboard menu should be gone (I disabled it but there’s still this document view).

    On the right side menu, when you click on the future “Global” tab, it would be the customizer. So the customizer would be on the right side instead of the left. Or maybe the whole menu would be moved to the left side.

    Only when you add a new blog post should you see this narrow document view in the block editor, because now you should be concentrating on writing your article only.

    If this narrow view is to be kept, then the entire website must be displayed in it, but with everything shrunk. Like in Oxygen. I think Webflow is like this too, but I’m not sure.

    These are my thoughts.

    Report

    • Tro

      If this narrow view is to be kept in the pages

      Report

    • Justin Tadlock

      Just noting that Gutenberg and the WordPress software are not Automattic’s projects. They are run by the community, which is made up of many individuals and businesses. Otherwise, nice discussion points. Thanks for sharing your thoughts.

      Report

    • David Morgan

      I totally agree. The Customizer is a much better experience for managing the design of your WordPress site.

      Design and content writing should be separate experiences. Instead, Gutenberg tries to combine both the design and content creation process together. That would be great if all writers were designers, and all designers were writers. However, that isn’t the case. As a result, Gutenberg has just made the writing experience more frustrating for writers, and the design experience more frustrating for designers.

      I want to like Gutenberg and blocks. In fact, I’ve already contributed multiple blocks and Gutenberg tools to the WP.org plugin directory. However, working with blocks in the Gutenberg editor on a daily basis is a frustrating experience. God forbid you have an image block, nested inside a column block, nested inside a cover block. It’s a nightmare trying to select and edit the right block…

      The WordPress team should vastly improve the Gutenberg experience before they even think about drastically changing the way themes are made.

      Report

    • Tim

      Also to add on to this, this customizer communicates via postmessage from the parent window to iframe. This keeps the separation of controls and related styles separated from the sites styles – instead of the div soup and overly specific style required to not clash with editor controls. Not to mention the defacto example WordPress set of using body class for managing complex specificity that the classic editor was capable of doing as it was loaded in an iframe. This is still the biggest issue with Gutenberg imo. They need to either utilize shadow Dom, which they won’t because of legacy browsers, or communicate with an iframe. Themes in theory should be able to simply enqueue their frontend styles into the editor without writing a massive amount of code to just get something halfway decent looking. Gutenberg does a lot of great things though, but the customizer is what people know and use for “global styles”. I have gotten to the point where I create a global styles plugin for Gutenberg and offer per page/post overriding or full site overriding. Then duplicate the same full site overriding in the customizer. If Gutenberg continues on to fill site editing, the primary focus should be the customizer. Replace it’s API with Gutenberg’s similar to how wp.editor’s functionality still mostly worked in tinymce and Gutenberg. If there was parity between posts/pages and the customizer, then things would really start to come together for users. Having two separate design systems makes it confusing for most novice users. If full site editing is the future goal, Gutenberg should move forward with it, and not try to reinvent small components in an interface where it doesn’t entirely make sense. Just think if you were to go into the customizer or any page/post link took you into it, you could easily have control to change headers/footers/templates, and update those things with block content if the Gutenberg system was already present. Why not just click on text in your full site preview, drag block in/out of your editor into different drop zones? It feels like people want this, but are putting too much thought into it. It can already be done today with minimal code, and still retain backwards compatibility. Maybe it’s just too many cooks in the kitchen, but Gutenberg was announced forever ago, and took a long time to get to where it’s at today, which arguably isn’t really anywhere that is useful for most theme developers. As a side note I really hope that theme authors can create blocks not as block plugins to include in their themes. Block styles can get most of the way there, but not being able to add additional controls to something like a simple blockquote to change backgrounds and or text styles is very limiting. Don’t get me wrong you can go far with block styles (I have made over 100 different ones at this point), but sometimes you just need to insert an extra element, or provide an extra control which makes the user experience even better.

      Report

  5. Patrick B

    The question of full site editing, header, and footer contemplating and in particular universal-style settings I can easily see us getting away from the motto of Decisions, not Choices. I know those in the meeting are carefully considering this but I have some concern about the compounding effect of some of those choices.

    From my experience with the block editor, what makes the editor compelling and potential a joy to work with is when a theme and theme author do a good job building out and styling both the default blocks and custom blocks ( I think, as we see in tools like ACF or many page builders, custom blocks will remain an important aspect of the block editor experience at least for more complex or custom themes. You don’t want to be building out complex sections out of several default blocks ). The pages become easy and enjoyable to build out when you can quickly start adding fully styled blocks reusable templates to quickly build out the structure of the page. Then on top of that, you have some simple preset style variations that allow you to quickly adjust how those blocks are laid out.

    That’s the editor experience that I am trying to find in the block editor at least. That’s what makes me excited about it.

    When it comes to building out more options and granular control, something closer to a page builder plugin like experience, plugin authors have shown that they are more than capable of filling that need.

    Report

  6. Álvaro

    I have my doubts, taking into account the presentations and the path that is being followed, that there is sufficient diversity in terms of decision-making. And that there are enough people with real-world experience of themes and their use.

    Examples of features are shown that themes have been providing for years, or even block libraries launched in the last year. Have some of the people who contributed to these themes and these block libraries been even invited? And people who use themes in their projects, on a daily basis?

    Yes, I know that meetings are public and voluntary. But it is essential to understand if the participants represent, in fact, the diversity of the WordPress user community or if, on the contrary, they are just a vocal minority that will define the future of how WordPress is used. And if that diversity is not represented, then something has to be done so that more people can influence the way forward.

    Report

  7. Robert Trevellyan

    I, for one, welcome our new block-based overlords…

    But seriously, my experience helping clients with WordPress has been that, for those with no experience, learning to work with blocks is much easier than learning to work with the ‘classic’ editor. I didn’t expect this, but people just ‘get’ blocks when they bring no baggage. Basic layout tasks, such as how to reliably flow text around an image, which I had to explain with hand-wavy ‘just trust me’ instruction, are now much more intuitive for newcomers. I typically spend about half as much time showing people how to edit their content with blocks vs what I used to spent with the ‘classic’ editor. And our designer dreads going back to sites that still use the classic editor.

    At the same time, we’re always careful to restrict clients to content-only editing unless they insist on admin access. I look forward to seeing how this will be managed in the brave new world of block-based themes. Existing solutions use role-based restrictions to maintain the separation, which seems like a reasonable approach.

    Report

    • Elaine

      Access restriction will be a very important piece of all of this. Right now, we can do things like prevent Editors from editing nav menus so they don’t break battle-tested layouts. (Of course, it would be even nicer if we had more granular permissions, so we could allow Editors to edit some menus and not others.)

      If the direction of WordPress as a whole is moving toward basically showing the front end view of each full page and allowing everyone to edit everything, it will defeat the purpose of roles and capabilities. And I think even if roles and capabilities are taken into account, so some roles can only edit certain parts, it may become a very confusing UI – for one person to be working on a page and say “Oh, to change X just click here,” and their neighbor to try to do so but nothing happens because they can’t edit that particular content.

      Report

  8. Yala

    Obviously, not every initiative that will be accepted by everyone

    Report

Comments are closed.

%d bloggers like this: