15 Comments

  1. Ben
    · Reply

    That’s interesting. I’ve been making a grid block for Toolbelt and had the same problem, the name clashing with other blocks.

    I’ve now added a TB prefix to all Toolbelt blocks.
    https://github.com/BinaryMoon/wp-toolbelt/commit/0f2997c3d81baa7263ee55e7d5dc4c1e0d5e04a3

    It’s a bit messy to look at, but much clearer to use.

    Report

  2. Mike McAlister
    · Reply

    Hey folks,

    I just wanted to address a few points here. Firstly, I want to apologize for anyone confused by the removal of the AB prefixes from the block names. I’m genuinely bummed when anyone has a bad experience with one of our products. This wasn’t done to prioritize our blocks over core blocks or any other 3rd party blocks. Quite the opposite, in fact. We believe the WordPress editor belongs to everyone, and the trend of over-branding and having logos and product names on blocks, sidebars, and admin bars can be distracting and take away from the core editing experience.

    Removing the AB prefix from each block was part of a larger effort of updating and improving the blocks in preparation for a rename to Genesis Blocks, as covered in the original Tavern article. Furthermore, we’re actively vetting our blocks and considering deprecating blocks that provide unnecessary competition to core blocks, such as the button block. No need to reinvent the wheel!

    As one of the first block plugins on the repo, we’ve been learning and growing the block ecosystem on the bleeding edge, and that comes with all kinds of fun surprises. One of which is the lack of standards and practices. We join the call for well-defined standards that all blocks can implement to give WordPress users a consistent experience.

    Report

    • Justin Tadlock
      · Reply

      Thanks for chiming in, Mike. Creating a user experience that works for everyone is tough. We obviously have the benefit of hindsight in this particular situation, but it’s an important thing to discuss while blocks are still relatively young.

      After giving some more thought to this over the past day, I have been wondering of core WP could potentially add some sort of indicator within the UI that would help distinguish core from third-party blocks. Your team is a bit more in the thick of block dev, so it’d be great to see if y’all had any ideas for this or just creating a standard to follow. I’m cautious about prefixing always being the best idea because of the limited space.

      Report

    • Marcus
      · Reply

      << we’re actively vetting our blocks and considering deprecating blocks that provide unnecessary competition to core blocks, such as the button block. No need to reinvent the wheel! >>

      It has taken me a few weeks, but I’ve removed all the (Atomic Blocks) Button blocks from my site.

      Mike, no matter the explanation, adopting the core block name ‘Button’ and not telling your plugin users was just plain wrong. Apology accepted.

      Report

  3. Antony Smith
    · Reply

    Blocks should carry an author label, without doubt. Navigating and inserting is cumbersome enough without having the added confusion of blocks with identical names. Lacking clear identifiers it’ll be way too easy to turn the inserter into an absolute shitshow. In my own experience I try to avoid third party blocks unless absolutely necessary an example of why being a recently installed plugin which I used for a quick fix to get a specific gallery feature. It only contained 3 blocks, upon subsequent updates this has now ballooned to 38, yes thirty eight along with an obscene amount of options which slowed the editor too a crawl. I decided to bite the bullet and implemented the feature using ACF so I could again dump the third party block. Still, there are notable examples of excellent blocks such as https://wordpress.org/plugins/accordion-blocks/ simple, clear, un-opinionated styling and it does exactly what is says on the tin.

    Report

  4. Amit Biswas
    · Reply

    Absolutely! This is a responsibility rather than opportunity. Most people are innocent and they absolutely don’t know if they’re using a third-party block until we developers are distinctly stating that. Dev’s must not use this as opportunity.

    Report

  5. Titus
    · Reply

    Thanks for the heads up. I am a heavy user of Gutenberg Blocks and Atomic Blocks, on a single site. hope I don’t run into any major issues with buttons. If If do at least I won’t be baffled !

    Report

  6. Bjarne
    · Reply

    Wasn’t there a time, when 3.party Blocks, were clearly listed under a brand heading, like, all Atomic Blocks in Atomic Block section in the inserter? I miss that. Its super confusing with 3 different button blocks all named “Button”

    Being using Gutenberg a lot the last year, I really really long for some sort of block management, including:
    – core management of block access rights, let the authors use a specific set of blocks only.
    – graceful fallback once a 3rd party block plugin is disabled.
    – a list / search feature to find out where a block is used.
    – maybe even a requirement for block plugin developers to make their blocks optional defaulting to disabled.

    I cannot unleash my co-authors with Gutenberg until proper management is in place, I would spend too much time cleaning up after the mess they will make.

    Report

    • Justin Tadlock
      · Reply

      Yes, most block collection plugins I’ve seen categorize all their blocks in the inserter. They may also add them to other categories there too. But, the categorization doesn’t appear if you’re doing slash commands, such as /button. The first option there may not be the core one. In the screenshot used in the post, I believe the core Buttons block is actually at the bottom of the list.

      Report

  7. Matías
    · Reply

    Agree this is also an area where we could do a better job presenting where a block comes from in some of the inserting UIs. There are also some tickets to improve the search experience for direct matches and priorities. For some plugins that have extreme 1:1 overlapping, it might also make sense for them to unregister a core block like Buttons when providing their own.

    Report

    • Justin Tadlock
      · Reply

      I’d definitely like to see better direct matching. I often do the slash command for /image, and the core Image block in that scenario is down the list of other image-related blocks from third-party plugins. It’s super irritating. Well, really it’s one of those small annoyances that I have learned to live with.

      Report

  8. Bastian
    · Reply

    Is a new rule needed in the plugin/block repository, maybe? Just saying.

    Report

  9. Anh Tran
    · Reply

    Agree with the article.

    Maybe there should be an indicator for 3rd party blocks like an icon to let users that they’re not core blocks and use with your own risks.

    Report

  10. Palash
    · Reply

    I like everything of StudioPress. Genesis framework is the best ever for bloggers. Automic blog is a simple Gutenburg block-based plugin. I am using this simple plugin one of my WordPress blogs. However, I agree with this blog post. The plugin author should consider the rename of the blocks.

    Report

  11. Kings Amalaego
    · Reply

    This was such a superhelpful article. My take on this is that blocks ought to carry author label because most people genuinely don’t even know if they are using third-party block or not.

    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: