10 Comments

  1. Nick
    · Reply

    Having the ability to edit a Reusable Block in a post is interesting, BUT with over 40 contributors and over 600 core contributors how is it possible that NOBODY has figured out that if anyone who is not an Administrator or Editor, when editing a post that contains Reusable Blocks and clicks on a Reusable Block, they will crash the entire post with just that one click?

    My answer to this would be for those who are not allowed to edit a Reusable Block (only Admins and Editors can edit them), the RU Blocks to be locked in posts and pages and not editable, just like they were a few versions before.

    Also, are the accordions in the Block Inserter ever coming back, or we the peasants do not deserve to have nice things anymore?

    Report

    • Stephen Vaughan
      · Reply

      I find that this tends to be the issue with the block editor. Many things about the editor are well implemented. While for some basic content insertion, inline, the editor is usable enough, but it tends to get more cumbersome as you try to become more daring. When you start to look at FSE it really is an not an elegant experience. It all feels like a geeky project where you need to be in the know.

      Considering many page builders seem to have cracked many of the issues that the Gutenberg doesn’t want to address, I would say we are falling between two stools here.

      I found the following on LinkedIn last evening, and I quote:

      “I have been looking into this for quite a while! Since late November the most recent change in Google left many WordPress sites with a bad score on page speed insights, with little to nothing to do since the new quality standards address certain programming practices that WordPress as a platform has to its core files architecture. Testing around there are quite some plugins (paid ones) that address this issue and the Guttenberg block editor functions better than other platforms like Divi or Elementor. E-commerce sites like shopify have no issue with the new standards on UX and speed Google has launched. So for now and until Google finish this change to a full positioning factor we are stranded at sea with WordPress. The question is if WP is going to address this on the free side of its platform or capitalize with plugins, making SEO a pay per positioning?
      What do you think?”

      Sebastian Pinto makes some good points there. I disagree a little with what he says on picking out Divi and marking it down compared to the block editor. He is correct about paid for plugins. In this instance, yes, WP Rocket at $49 is probably good investment, if you are using Divi. I tested it recently and was impressed how it addressed very easily the core web vitals that Google expects now.

      I have also being testing the Kadence block based theme, which is very good by the way, and, while on initial testing it scored well, when I realised that the imported theme was very light on images, as soon as I started to add some to match what was on my own Divi site, that score started to slide very quickly. Again I suspect that WP Rocket would address this.

      In any event, it isn’t as if Elegant Themes are unaware of the issues it must address and, to this end they are going to work on some of the underling issues in the foundation of the theme, even going so far, I hear, as to remove the shortcode base, if that is possible at all. Maybe the underbelly will be block based? 🤔

      Getting back to Sebastians contribution on LinkedIn, I would be focusing on getting the core block editor working well before tacking FSE. The powers to be at WordPress set up the scenario of either block editor or page builder camps, which is not helpful at all. This has been the problem with WP for the last while where conflicting approaches by plug-in vendors to dealing with, or not dealing with the block editor, has been a pain for end users.

      On your comment Nick, in terms of usability, page builders are way ahead, and despite performance issues, this is where Divi excels, like clearly defined settings groups that get presented selectively with the accordion convention you mention. With the block editor, while many of the core features are usable, there are many parts of the UI which are like looking into a field of thistles.

      Report

  2. Andrew
    · Reply

    For the grouped template parts, if the theme does not define an area (in theme.json) for a template part, it will be grouped in General (uncategorized).

    For example TT1 Blocks theme defines the template part areas like this:

    "templateParts": {
        "header": {
            "area": "header"
        },
        "footer": {
            "area": "footer"
        }
    }

    This seems to be missing from the theme developer documentation.

    Report

  3. Raul Craveiro
    · Reply

    I would love to see an option to add custom icons on the social icons block. I want to use it as links to the podcast platforms, but there are only Spotify and Google icons :(

    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: