Gutenberg 9.6 Introduces Drag-and-Drop Blocks and Global Inheritance for the Query Block

For some people, Christmas arrived a couple of days early. Gutenberg 9.6 launched with its first iteration of drag-and-drop blocks from the inserter. There are some other enhancements like vertical buttons, heaps of bug fixes, new APIs, and other improvements. But, let’s be real. The ability to drag blocks from the inserter into the content canvas is the highlight of this release.

Another key feature is that the Query block, which is only available when Full Site Editing is enabled, now inherits from the global query arguments. As has been usual as of late, much of the work in the Gutenberg plugin has focused on improving the site editor.

Drag Blocks Into the Content Canvas

Dragging a Gallery block into the content canvas in the WordPress block editor.
Dragging a block from the inserter and dropping it between paragraphs.

Perhaps the Gutenberg development team has seen your comments and your other comments. If there is one common thread among the comments on our Gutenberg-related posts, it is that a segment of the WordPress user base wants more drag-and-drop capabilities.

The new feature only works with blocks right now. Users cannot yet drag and drop patterns from the inserter.

After several tests since Gutenberg 9.6 Release Candidate 1 landed last week, I have had no issues with it. For the most part, the experience felt smooth and easy to use.

I have never seen the allure of drag-and-drop features in a content editor. If I am not typing in Markdown, I am in the WordPress editor and using keyboard shortcuts. Throughout my career, I have either been writing code or writing words daily. Picking up my fingers from the keyboard only serves to waste time.

Sometimes I forget that the block editor already has some drag-and-drop capabilities available, which allow end-users to move blocks from one position to another in the canvas. I tend to work with the top toolbar enabled, so I rarely see the feature.

Nevertheless, I do see how dragging and dropping blocks could be useful to some users. I use them in other types of editors, such as Gimp or Photoshop, at times. The one thing I like about those is the toolset is always available in the sidebar. This is not the case with the block inserter. While it will stay open for users to drag multiple elements into their content, it disappears once users begin working elsewhere. That could become irritating if the user is in more of a visual-design workflow instead of a content-editing mode.

Dragging blocks from the inserter would make more sense for my workflow in the upcoming site editor rather than the post editor. The feature works great in that context too.

Query Block Supports Inheriting the Global Query Arguments

New option for the Query block in the editor for inheriting from the URL.
Inheriting the Query block’s options from the URL.

The low-key star of this release is an update to the Query block, which is only available when using a block-based theme. The update is one of the most important breakthroughs for Full Site Editing, a pivotal moment in the history of the Gutenberg project.

In previous iterations, the Query block required that themes via their block templates or end-users via the site editor define which posts to display. While that is a necessary function of the block, the missing piece was the global query support.

In the simplest terms, whatever URL a visitor lands upon tells WordPress which posts to load. The data for loading these posts is all stored in a global set of query arguments. Themes can then loop through these posts to display them.

In Gutenberg 9.6, the Query block can now inherit these query arguments. This means that things like the blog posts page, category archives, search results, and more will display the correct posts when someone visits one of those specific URLs.

On the surface, this change merely adds a single option to the interface. However, under the hood, it is a achievement that clears a gaping path for developing block-based themes.

15

15 responses to “Gutenberg 9.6 Introduces Drag-and-Drop Blocks and Global Inheritance for the Query Block”

  1. Merry Christmas, Justin!

    I really don’t understand this Query block even though it’s been mentioned in several Tavern posts. My eyes seem to gloss over when reading about it – ha!

    Is it important that regular WordPress users understand this block, or is it really a block for developers?

    • As for whether it’s important for regular users, it really depends. You wouldn’t want to go into the site editor and remove the Query block from the category template, for example. Your posts would not show on category archives on the front end in that case. That low-level of understanding is probably necessary for users who are tinkering in the site editor.

      For deeper customization, it will be a powerful tool. You might want to create a custom front page that lists specific posts. Maybe even do a magazine/news front page with multiple sections of posts from different categories.

    • While archive pages are now automatically generated and most always just display a list of posts, their content cannot be edited like for regular pages. The query block could fill that gap. For some custom built sites we’ve unregistered “has archive” support for posts, which removes the automatically generated archive templates. This enabled site owners to introduce “category” pages using one or more (in our case custom built) query blocks. They could then layout the page in more ways than just displaying a list of posts, eg. by adding other blocks in between multiple query blocks. Quite nice.

  2. Thank you, Otto! Thank you, Justin!

    I am currently using Automattic’s newspack theme, which is accompanied by a newspack blocks plugin. The newspack blocks plugin includes a Homepage Posts block that essentially does exactly what you referred to Justin. It enables one to choose a specific category and display the previously placed posts within that category. My tibesar.com homepage has several of these Homepage Posts blocks, which is really super cool.

    So, it sounds like the Query Block is basically the same as this Homepage Posts block. This will be great since it enables all WordPress content developers to display an entire category of posts on Pages or Posts or the Homepage.

    Again, thank you for your further explanations!

  3. Some confusion here looking at the latest developments with Gutenberg 9.6.1 and a test install with the TwentyTwetyOne theme. I don’t see the templates feature and all the thing’s in Joen’s demo the other day? Perhaps I need to load the Photo Blocks theme?

    I do see Bulk Post and Bulk Page Under the + New menu which creates old style Classic editor pages? What’s all that about?

    While I do enjoy working with the block editor itself I see a lot of mystery meat around how it is all supposed to work in context to the rest of WordPress.

    For example, at the moment we are in some sort of limbo between editors where I have to write up instructions for both editors for clients who are shop managers and have to manage WooCommerce products using the older editor.

    I would prefer if the WooCommerce interface was updated to reflect the new editor and, by the way, have a way to disable the blocks and just have the product data meta box and other user defined custom fields. This is more appropriate where a Template is used on the front end. In the end some use cases call for an interface that is suitable for data entry, which the block editor certainly isn’t designed for. The front end template, yes, does merit creation by block editor.

    There doesn’t seem to be a peep from either WooCommerce, Automatic, or Matt himself what the roadmap is for WooCommerce. It’s a reason why I reset my review of Gutenberg to one star. The block editor is great, everything around it has a question mark over it.

    • I would prefer if the WooCommerce interface was updated to reflect the new editor

      This. Not only WooCommerce, but all plugins that make a heavy use of custom post types and meta fields are still using the old editor. Why? Because there’s still no suitable way to place meta fields in the new editor. Sorry, but the PluginDocumentSettingPanel and PluginSidebar components are too narrow and too hidden to fit something like the WooCommerce product panels.

      I find it puzzling that after two years of Gutenberg, there’s still no talk on their GitHub about this issue. There’s an elephant in the room and nobody seems to care. It’s all about the FSE, now. I wonder what will happen to all the plugins that rely on the old editor when the classic editor plugin gets deprecated at the end of 2021.

      • There’s all that as well Bastian. The whole custom post types with custom fields use case for data entry is overlooked. I have made my own rudimentary plugin that makes the block editor disappear. It wouldn’t be the most sophisticated thing on earth but it does the job by some css that occasionally needs alterations to keep up with block editor changes.

        Agree, a lot of fuss around FSE while many other things unresolved. Kind of the elephant in the room.

  4. After figuring out how to install the Photo Block theme and trying out the FSE features can’t say that I am inspired. Considering that On the Go Systems have already cracked much of this with Toolset Blocks, I am wondering why FSE is so confusing?

    I guess they have a bit more work to do but it does confirm one thing. The way the block editor is implemented, where third party developers can proffer a myriad of blocks for every occasion, and, if any of the plugins that deliver these is disabled, we are left in no mans land and fragmentation, the one thing that page builder have been accused of.

    I said it before. What should have been the goal was a strong set of common blocks for content and layout and then an API for third parties to hook into to add bells an whistles either for styling, UI for settings or both. Then all page builders could conform to this and contribute best design practice to the project. Leave one builder for another and at least much of your work would remain intact.

    What I see so far doesn’t convince me that any of this is going to make WordPress any easier for a lot people with starter to medium skill set.

  5. Been looking into FSE themes lately, and I have so say 9.6 is a bit of a mixed bag for me.
    It’s great to see patterns now available in the site editor, but the way that separate block stylesheets are now loaded seems to be a step backwards IMHO.
    Previously a FSE theme had the “style.css” stylesheet containing styles/layouts for all the various blocks to do a lot of the heavy lifting, now in 9.6, FSE themes have only the “common.css” stylesheet instead.
    I understand it has been done like this to reduce wasted resources so that only the required styles are loaded if a post contains a particular block(s). The issue is that now a FSE theme needs to have it’s own separate stylesheets for each and every block, resulting in FSE themes now appearing to be broken.
    The way a theme’s library of styles are rendered is also weird, with all the stylesheets rendered inline in the header, and then additionally the required block specific styles right after the opening body tag.

  6. Hi guys, I think the ultimate goal should be having a full drag and drop editor and not a 3-4-multi-click tiny-sidebar-subsubsubsub-menu click fest. I would really love to see one day everything to be one thing and not a combo of front and backend. It was always a dream of me to have everything editable and drag/drop-able from the frontend so the WYSIWYG experience never breaks down.

    The whole problem is, how many years it would take for that to materialise? From what I see some other competitors are already stepping ahead with much better solution and the recent Cloudflare announcement about Pages built from JAMStack would be a huge thing.

    Making JAMStack simple with crazy performance on a headless/serverless solutoins would completely revolutionize the performance part and later if all that delivers a simple drag’n’drop experience on top, it would ultimately kill WordPress.

    From what I see right now Gutenberg is pointing at the right direction, but the speed of the implementation is too slow. Yes, 39% market share is huge, no doubt about it. But just like the Windows market share is huge, soon Apple would take over just because their M CPU solutions are revolutionary. Mark my word.

    Same with WordPress, 39% market share is not showing a long term projections, since JAMStack would solve something 90% of the clients experience – problems with speed. Throw 3-4 plugins and clutter the database with “stuff” and you have a slow loading page. I have clients that ultimately refuse to install even one more plugin.

    In 2021 Core Web Vitals are becoming a ranking factor for Google. That means the performance part would be a key. Where is Gutenberg in all this? JAM Stack would be a great solution for that problem.

    Sorry guys but it’s really Gutenberg that is lagging now in terms of WordPress domination, it should pick a winning strategy, so far what it accomplishes is devs seizing their plugins or stopped updating them, few started their block systems and others continue to live under the rock.

    The Gutenberg experience is sub-par so far despite the great idea and this results in a lat of negative reviews everywhere.

    For me, for Gutenberg to really hold WP as the dominant CMS, it should aim at one of these in the short term:

    1) Performance;
    2) Drag and drop instead of multi-click approach.

    I use WP from 2008. I’ve build probably hundreds of sites using it for clients, friends and myself. Some of them were 6 figure earners.

    I know what I am talking!

  7. “I have never seen the allure of drag-and-drop features in a content editor. If I am not typing in Markdown, I am in the WordPress editor and using keyboard shortcuts. Throughout my career, I have either been writing code or writing words daily. Picking up my fingers from the keyboard only serves to waste time.”

    This seems to be the mentality of most people working on Gutenberg as well. It would certainly explain many of their UX design decisions and priorities.

    For most of the rest of humanity, not being able to drag a block where you want it from the inserter is almost as stupid a UX omission as omitting copy and paste from a keyboard interface.

    Don’t get me wrong — I’ve been using vi/Vim almost daily since 1985 and I love me some keyboard interfaces. But I’m given to understand that many devices already had mice in 1985, and since then I believe touchpads, or touch screens have also become universal! On many commonly-used devices these days the “keyboard” is just another part of the touch screen.

    I used to work with a graphics guy who swore Adobe Illustrator was a waste of time because “anybody” could learn how to hand-code complex splines and vectors vectors directly into PostScript files, just like he did. He was wrong too.

Newsletter

Subscribe Via Email

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