10 Comments

  1. Dumitru Brinzan
    · Reply

    “To build some patterns, I had to become a little less of a purist and just use the available tools. That change in mindset opened some more possibilities.”

    For developers focused on performance and clean code, this is a difficult hurdle.

    It’s difficult to accept that you don’t have much control over the HTML markup of the elements that you’re trying to make unique.

    And another problem with patterns is that the user has to do everything manually. It is somehow counter-intuitive to think of a pattern for “Latest episode”, when the user will have to manually update the block after every published post.

    But it is true. The more I play with blocks and patterns, the more my mindset shifts towards them.

    Report

    • Justin Tadlock
      · Reply

      If the perfectly clean code is a blocker — and I can certainly understand that — there is still a world of possibilities. Using the Spacer block is more of a limitation when doing this without code from a user’s point of view. From a theme developer angle, the block styles system would make this far cleaner. It is one reason that I think theme-specific patterns will thrive over the block directory. But, I’m definitely on the we-need-better-spacing-controls-and-we-need-them-now train.

      It’s rough on me not being able to control the HTML output too. I’m someone who has built entire packages just to fix the horrid HTML with classic theming. The trade-off here is that there is a standard (kind of ignoring that the markup sometimes changes for some blocks). I have a lot of thoughts about what this means for theming and hope to share in more detail in the future.

      As for the manual entry of the “latest episode,” I’m imagining integrating with something like a podcasting plugin that had such a block built in. That seems like a more sensible route in a real-world scenario.

      Report

  2. Drew Tipson
    · Reply

    The block editor still remains difficult for developers who need to create carefully created custom experiences for end-user clients. Patterns are useful but not that useful for actual real world use cases when we don’t have full control over coding what’s allowed or not allowed (what things can be added, how many, what blocks must be in what position, etc.). For actual real world clients, this just means they can easily create a neat experience, but then by accident can mess it up and not know how to fix it, or have guidance on what is supposed to look like.

    Gutenberg also still exposes too little control over core blocks (leading to awful, fragile hacks to hide unsupported or inappropriate features) and many of the basic needs, like validation, that have been well solved and long fulfilled by other solutions (like the trusty ACF) are barely fleshed out or left as an exercise to the reader (potentially to break or rely on deprecated features down the road).

    I’m excited for the big features on the way, but it’s the little stuff that’s missing/hardcoded that are really restraining what’s possible to ship.

    Report

    • Bastian
      · Reply

      The block editor still remains difficult for developers who need to create carefully created custom experiences for end-user clients. Patterns are useful but not that useful for actual real world use cases when we don’t have full control over coding what’s allowed or not allowed (what things can be added, how many, what blocks must be in what position, etc.)

      From time to time, I keep reading here that right now there are many possibilities to custom-tailor the block editor for clients via templates. But, checking the official docs, I only see a small reference to a property named “templateLock” with just three settings, which is almost useless for real-world site builders and developers.

      Report

  3. Ben
    · Reply

    Gutenberg and Full Site Editing needs better docs. Without that support will take a while.

    Report

  4. Andrew
    · Reply

    I love block patterns. Love creating them. Love finding inspirational patterns whether they are actual WP patterns or not, and tweaking them.

    This issue for me – and this is purely anecdotal, no hard evidence to back this up – is that your average user does not want to insert a pattern, only to then have to swap out all the content to make it their own. Building a full site this way is much more of a slog than say importing a demo site. Sure, with a full-site demo the content still needs manually changing, but the user has clicked once to import rather than clicking once multiple times to insert multiple patterns, and with a really well thought out demo there is a congruous design.

    There is also the issue of – for want of a better word “flow”. The stop-start nature of opening up the block pattern sidebar, searching for a pattern, inserting said pattern only to find it’s not really what the user was looking for, or they don’t then know exactly what to do with it.

    All that being said, I’m really looking forward to how patterns will evolve, especially with block-based templates where the pattern content can be more dynamic.

    Report

    • Justin Tadlock
      · Reply

      There is definitely a large WordPress user segment that wants a one-click, full-import solution. I’m glad you brought this up because it is one of the few comments that touches on a real business opportunity.

      To me, or a savvy theme business owner, that looks more like an opportunity than a barrier. Instead of patterns being the whole solution, they become part of it.

      If I’m a business owner, I’m directing my dev team to start building one-click imports for a full site. Within these imports are the patterns themselves. The user doesn’t need to know they are patterns from the start. They just click a button and watch the magic happen. They get their home, about, portfolio, etc. pages easily.

      Then, User X comes along a month later and wants to “recreate that portfolio demo page” on another page. That’s when you introduce them to the pattern concept. Walk them through the process of clicking on the Portfolio pattern that you’d already built and wrapped into the demo importer. It’s sort of the best of both worlds.

      It’s not like theme authors haven’t already been doing demo imports. Many of them already have the scripts/libraries for doing this. Patterns just add another arrow in their quiver, so to speak.

      And, I’d love to see different user-experience takes (“flow”) on handling this too.

      Report

  5. Steve Grant
    · Reply

    My main concern is still “how do I deactivate the block pattern directory in a client site which doesn’t need public patterns”.

    Lets say I’m specifying a site for a client and they’ve requested they want a mostly locked down page template with a few editable or switchable elements. They wish to (Create New) Article and see a WYSIWYG layout with key elements fixed in position, editable but not removable, then to select from 3 potential sub-page page layouts (EG: Magazine / Academic Paper / Podcast ) where they can edit safely. In that area they want their editors to have access to a few blocks relevant to the context.

    So… to accomplish this first I need to lock down the page template in general and unlock the sub-page using template_lock nested templates. There is only this documentation for this feature:https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/nested-blocks-inner-blocks/ then lock the outer blocks and unlock the inner blocks with https://developer.wordpress.org/block-editor/reference-guides/block-api/block-templates/#locking

    Next I must hide all patterns which are not provided by me (deregister using remove_theme_support( ‘core-block-patterns’ );)

    Now lastly I’ll want to completely prevent public blocks from being used, and hide the upcoming UI for the public block pattern directory to prevent Jimmy The Intern from inserting a non-approved external pattern into the approved layout.

    There is no documentation for the pattern directory feature. The UI is not specified yet. The GitHub has no docs, information is scant. I’m very busy and I need a central documentation reference for this massive new feature.

    The Directory will launch In July 2021 and might appear in the client site at any point afterwards, perhaps part-way through development! So I’ll be needing to deal with it, to turn it off at the very least!
    But how? Who knows!

    Currently the best option we have seems to be “email Justin”. Now that’s very kind but is it really the best option?

    This is why people like me avoid the Block Patterns. I’m actively looking for a solution for sub-page user-selectable templating .. and yet this Block Pattern/ Directory solution looks a lot like a problem for me. It’s another asteroid heading for my planet.

    Report

  6. John McCarthy
    · Reply

    Thanks for this.

    I have to admit after trying to implement certain ideas with the block editor and either the design not being possible or, being too much of a purist. I have given up numerous times, this article is definitely pushing back to the editor again.

    Report

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.

%d bloggers like this: