Gutenberg 16.3 Adds New Tools for Patterns

Gutenberg 16.3 was released today as a maintenance release but includes several new tools that make pattern management smoother and easier for users. Most notably, custom user patterns now have a dropdown menu for renaming, duplicating and deleting them. Patterns and template parts that come with themes will only have the “duplicate” option available since they cannot be deleted or renamed.

video credit: Gutenberg 16.3 release post

Gutenberg 16.3 adds a sticky header bar on the Patterns page. It also brings the “focus mode” to patterns, which is already available for template parts in the Site Editor but not available when editing patterns. Users may not notice but it provides more a consistent editing interface.

Those who have been keenly following the evolution of the Patterns page will notice that the “Theme patterns” heading has been removed and the pattern categories rearranged. Theme and plugin patterns now appear above template parts.

image credit: Gutenberg PR #52570

The icon for synced patterns isn’t self evident and some users may need more context. A new tooltip identifies synced patterns as those for which edits will apply anywhere the pattern is used.

Gutenberg 16.3 includes more than two dozen pattern interface-related fixes, among other editor bug fixes. If you are using and managing patterns frequently, having the Gutenberg plugin installed will enable a better experience with this interface until these updates make their way into core WordPress. Check out the release post for a full list of all the changes and fixes in 16.3.

11

11 responses to “Gutenberg 16.3 Adds New Tools for Patterns”

  1. I’d like someone on the spec team to ask client editors (EG: CMS editors for medium sized companies ) the following question:

    ‘What do you understand by the word “Patterns” in the context of website content, layout and design?’

    Because my clients don’t understand it the way the Gutenberg team do. I think that’s because it’s an software industry term, not a client facing term. Patterns means something else to staff member of a non tech firm who have assigned their most junior intern to be a content editor

    • As a developer, I’d have called patterns ‘templates’, even though that word is already heavily used in WordPress and the industry generally. The one that gets me is reusable blocks. That name implies to me the functionality that patterns provides, maybe linked blocks would have been a better name for that?

  2. I must confess to having a bit of trouble adapting to block theme customization that doesn’t simply involve changing style rules in a CSS stylesheet.

    For example, I’m not at all sure what to do to tweak the site header and nav bar. Would I make the necessary changes in the JSON file or CSS stylesheet? After all, the navigation block is limited in regard to handling padding and margins.

    I usually tweak the CSS and PHP to get the desired look and functionality in a theme. That way, I know that I’ve locked in my changes.

    I read through all the documentation on FullSiteEditing.com, but I’m not yet confident about being able to use FSE efficiently.

    I’d appreciate any advice people can give me.

    Thanks.

    • Hi, Glenn. My hope is that most of these questions are answered by the Theme Handbook, once it has been overhauled. That project is underway (I’m always on the lookout for others to help there).

      I’ll try my best to answer your questions here, but feel free to ping me on WordPress Slack anytime if you want to chat directly or even hop on a call. We can talk specific scenarios.

      I must confess to having a bit of trouble adapting to block theme customization that doesn’t simply involve changing style rules in a CSS stylesheet.

      The goal is for themes to primarily use theme.json to alter design elements like colors, fonts, dimensions, etc. This puts WordPress, the theme, and users all on the same page. Refer to the theme.json docs for the specific options available.

      The reality is that theme.json doesn’t handle every scenario, and you sometimes need to hop back into CSS. There’s nothing wrong with doing that, either.

      For example, I’m not at all sure what to do to tweak the site header and nav bar. Would I make the necessary changes in the JSON file or CSS stylesheet? After all, the navigation block is limited in regard to handling padding and margins.

      As a theme author, I’m right there with you. The Navigation block is extremely limited when styling via theme.json. I almost exclusively customize it with CSS if I need anything more than color or font changes.

      Overall, how much JSON vs. CSS you use is often situational, depending on how complex the design is. There is not always a right or wrong solution to every problem, which can make it tough to feel confident in what you’re doing. The most important thing is to build something and share your experience, pain points, etc. back upstream.

      • Well, my pain is, that I feel left out in the cold considering the theme.json approach in general. It begins with what is being described here: what to change where and above all: why? As long as I‘m lacking a real good explanation behind the logic behind the system I‘m sticking with classic themes, as they provide me a tried and trusted way to design them and do not confront non-tech-savvy editors with option after option to mess up the site.

        Once this overhaul of the concept is somewhat finished and not prone to what seems like neverending overhauls I might consider having a second look. Because whenever I try to grasp the sense of the whole approach I‘m getting more confused about the concept behind it all, besides keeping a lot of people occupied with it.

        The other point that bugs me about theme.json is that to me it provides a lot of bloat, endless lines of seemingly redundant definition after definition adding an extra layer to the never ending evolvement of CSS and not a tool in sight to make editing it more comfortable for designers. The whole concept seems to me as being dominated from a mere coder’s perspective, the in-crowd and the paupers that lack the ability to focus on nothing but coding. The approach seems to be targeted on bigger agencies with designated specialists for every field.

        I really hope the handbook mentioned might sometime clear up my irritations and the disappointment coming from it.

  3. It all looks alien to consumers. It looks more like a build from Devs for Devs and semi-devs. This is anti-consumer UX. It uses dictionary terms and other stuff from developer communities, not regular consumer-oriented clients. People with small businesses would prefer a closed-source but clear consumer-oriented product like the alternatives, rather than battling with this dev-oriented CMS.

    • For me, as a dev, the problem is that this approach is just confusing and not for devs at all. Devs like me will stick to PHP for building custom templates and really (I mean really) do not need a thing as complicated as the one proposed here with the so-called “patterns”.

      • How would you build a collaborative UI, where translators, editors, designers, and managers can all come into one place to manage and build a website, simultaneously?

        Moving into Phase 3, it’s going to be a shared tool and more about the community at large, not only developers.

        It’s a difficult challenge and I have alot of optimism, and encouragement for the effort that’s going into WordPress. I want to see this work and I want to see developers start to image how other people could interact in different ways with their work.

        When do we become proud of WordPress not only for what it has enabled us to create, but what a developer can enabled others to do with what we’ve created?

        • Hi Paul,
          thank you for sharing your thoughts.
          You are talking about a “shared tool”, but if you work in this industry with real clients that are not so tech-savvy, you already know that the development of a project is almost never simoultaneous with devs, editors, designers working together at the same time on the same page.
          Maybe I’m biased by my kind of clients, but I know they only want to insert some content on their websites and they will never ever want to know anything about design or code: they only want a thing that works and stays consistent across pages.

          I think the main point is: who is WordPress targeting right not?
          At this time, I feel the target are not the developers: devs were/are very comfortable with PHP/js/CSS for doing almost anything on a robust CMS as WP was.
          End users maybe? I really don’t know: I think something like Squarespace or Wix are way more friendly and straightforward for someone who only wants a “simple” website to begin with.
          Content editors? I’m not sure, but the editors I’m working with call me for any code based modification and they don’t even want to know what a json is.

          The truth is that I’m very confused about this all, I try to keep up with what’s new because this is my job and I love it and I do think that there are some good ideas in the whole Gutenberg revolution, but I’m not understanding the real aim of the project and who really will benefit.
          (Sorry for my English, it is not my first language).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

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: