1. Marcus

    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?


    • Otto

      The query block is basically the posts loop. If you know themes, then you know about The Loop. It displays the posts, whatever they may be. That’s the query block, essentially.


    • Justin Tadlock

      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.


    • Barry Ceelen

      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. Marcus Tibesar

    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. Stephen Vaughan

    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.


    • Bastian

      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.


      • Stephen Vaughan

        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.


    • Otto

      Some of the experimental features are experimental. Check this code out for more: https://github.com/WordPress/theme-experiments


  4. Stephen Vaughan

    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. Andrew

    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.


    • Andrew

      I spoke too soon. It seems the separate block styles were missing from the version of the plugin in org repo.

      Now fixed in 9.6.1+


  6. Random Marketer

    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. David Innes

    “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.


Comments are closed.

%d bloggers like this: