Block Management Features Proposed for WordPress 5.2

WordPress 5.1 has been downloaded more than 3.6 million times since its release last week and work on 5.2 is now underway. The upcoming release will be led by Matt Mullenweg with Josepha Haden acting as Release Coordinator. Gary Pendergast posted a proposed scope and schedule that would have 5.2 arriving April 23, 2019.

One of the proposed features is block management, the ability for users to hide or turn off blocks that they are not using. An avalanche of blocks is pouring into the WordPress ecosystem, especially with the push to convert core widgets to blocks. Users’ expectations will soon become firmly rooted in the concept of the block interface as widgets slowly become a relic of the past. It’s also quite common for users to install block collections that introduce a dozen or more new blocks when they really only have use for a handful of blocks.

Several standalone plugins already provide block management features, such as Gutenberg Manager and Disable Gutenberg Blocks. They all have different UI’s and approaches to letting users turn off blocks. For example, Gutenberg Manager uses a tabbed interface with checkboxes for disabling core blocks. The Disable Gutenberg Blocks plugin offers an admin screen that is similar to plugin management:

A few block collections have also implemented their own block management features, including Advanced Gutenberg Blocks and CoBlocks. Advanced Gutenberg Blocks adds a screen under its own top level menu for disabling blocks.

CoBlocks recently introduced a block management feature that is one of the more elegant implementations currently available. It adds the block management interface inline with the editor in a modal window, instead of relegating it to its own admin page. It also offers the ability to turn entire categories on/off.

After CoBlocks announced its block management feature, Nick Hamze contended that this should be replicated for WordPress core. His comments received a bit of pushback from Gutenberg technical lead Riad Benguella who sees it as a feature for more advanced users.

“The ability to disable blocks seems pretty basic,” Hamze responded. “Rich didn’t make this feature for fun. Regular users (not advanced ones or developers) asked for this. He made it to solve a problem that real users are having. You are telling me that more regular users will use the Amazon Kindle Embed Block (that is being baking into 5.1) than would like the ability to turn off blocks they don’t want to use.”

Last week when I spoke to Benguella about the possibility of block management capabilities being included in core sometime in the future, he said it wasn’t an immediate priority for the project.

“Block management is not an immediate focus in the Gutenberg roadmap and is considered plugin territory, but we keep close attention to the work done in the community and adapt in case user research and suggestions that bring value for the majority of users,” Benguella said. “My personal opinion for the moment is that, these are advanced features not required by every user of WordPress.

“That said, it’s important to enable plugin developers to implement more block management features, and one important piece of the puzzle here is the work we’re doing right now to improve the block registration and discovery both using REST APIs, PHP helpers and JavaScript APIs.”

The project’s priorities seem to have changed since that time, as block management is now a strong consideration for WordPress 5.2. Thousands of users have already installed a plugin that includes these kinds of capabilities, a good indication that there is a demand for this. As everything in the plugin ecosystem gradually moves towards blocks, it will be easy for users to get inundated by the many blocks available in the editor. Plugins are currently answering users’ needs with many different UI’s for turning blocks on/off. It’s clear that WordPress core needs to lead the way by providing a standard UI for block management.

In recent #core-editor chats Benguella said he has some concerns regarding the short time frame for the newly proposed block management feature, but is starting initial explorations of what the first iteration may look like in WordPress 5.2.

“So in addition to the currently shipped enhancements and the work done on the widget blocks, there has been a bunch of requests and feedback suggesting the need for a block management solution and block directory work,” Benguella said. “This is actually proposed for 5.2 and something we need to start thinking about and exploring the existing possibilities.”

Pendergast referenced CoBlocks’ implementation in his 5.2 scope and schedule post as an example of how plugin developers have approached block management.

“We weren’t the first by far, but I’d argue it’s clearly the best experience,” CoBlocks author Rich Tabor said. “I built it because folks have been asking for just that, and I wanted to deliver a much better experience than asking them to go to a WP admin page elsewhere. I’d love to see something like the Block Manager in core and am available to help out in any way I can.”

Other proposed features for WordPress 5.2 include the Site Health Check plugin, PHP error protection, and package signing for updates. The first beta is expected March 14, 2019, and RC 1 is slated for April 10, 2019.

21

21 responses to “Block Management Features Proposed for WordPress 5.2”

  1. The Classic Editor plugin has become the 7th most popular WordPress plugin with over 3 million sites using it.

    It’ll be interesting to see whether core developers can implement changes to Gutenberg that’ll convince those people to make the switch, or if use of the Classic Editor plugin will continue to grow.

      • > The people who are using the Classic Editor are running on
        > borrowed time.

        Or maybe wordpress is running on borrowed times. I m using gutemberg on my websites, but ALL my clients wanted the old interface and a couple already looked for /installed alternative (classicpress being one)

        i remember 10 years ago when i moved from joomla/mambo to wp.
        The people who killed joomla replied the same exact way.
        Ditto for the people who crippled Drupal.

        I ve the greatest respect for people who work for us to improve wordpress, and i m supporting them 100%, but this kind of replies suck big time and damages wp as a whole.
        and the mentality behind it should be eradicated

      • Oh Jeff, please say it isn’t so.. I have not moved into Gutenburg, each painful try was awful.
        None of my clients will even explore it.

        I am getting quite concerned that this block push is going into the dashboard. I love widgets. It is dead easy to manage. Menus too.

        I do believe if this is pushed onto the dashboard where I have no say in how I want to manage sites, I too will leave WP.

      • > The people who are using the Classic Editor are running on borrowed time.

        Indeed, this is my case. I’m using the Classic Editor until I rebuild the two remaining sites that I still have running on WordPress and transfer them to static sites.

        I love WordPress but maintenance just takes too much time.

  2. I’m commonly seeing users installing multiple block collections that each contain their own block manager. So now they have a confusing mess with block managers that may or may not work together, and may or may not have a way to be disabled.

    This won’t likely get better until core takes on management of blocks.

  3. The personal opinion of the Gutenberg lead dev on the block management thing doesn’t really matter.

    What matters is that more and more users, developers included, are wanting such management features as they get overwhelmed by blocks a lot.

    Also the whole dev pace of Gutenberg/ WP Core needs to slow down. It is way too fast at the moment.

    If you want a to adapt another release structure and schedule have a look at Mozilla with their Firefox: they do it completely right. About 10 releases a year (with exception of christmas holiday season…). Alpha beta, final release channels. A clear release calendar. And each of the releases has a clear focus: smaller steps but consistent. — Current Gutenberg / WP Core dev is the exact opposite of that, at least to me.

  4. It is kinda worrying that such elemental features like a block manager has not been implemented until GB was merged into core and ever since that time. That way they created an issue and will need to recover that somehow but this way they just run after a problem they created by not thinking forward.

    I just wonder why one can not change the post type in GB’s latest posts block, maybe even that is thought completely useless… i don’t know

  5. Agree that management features are needed ASAP.

    I’ve personally witness “average” users install block plugins that add in some cases 10-20 blocks. When in fact they were only after 1 block in particular.

    The CoBlocks interface for block management is exceptional and should be integrated into core.

  6. Another issue with blocks is that there is now a lot of bloat being generated. Users may only be looking for a single block and end up installing a plugin with 20 of them or so loading all their assets onto every page.

    I think that there needs to be a smarter and more standardized way of handling block assets. IE if there is a slider block if you would its assets are only loading if that block is being loaded.

    As for the block management, I can see the use of such a feature but I think it’s looking to fix a problem that shouldn’t really exist. Plugins should quite frankly stop bundling 20 blocks into a plugin

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.