9 Comments

  1. Bastian
    · Reply

    “The themes do not style blocks, and the editor does not match the front. We as theme authors have not adapted fast enough to the block editor, and now there is another big change coming in six months.”

    How we are supposed to adapt our themes fast enough to the block editor if, for example, there is no summary of all the CSS classes that need to be styled for each block anywhere yet? This is something that many have asked for in the GitHub repo without success.

    Report

    • Andre
      · Reply

      I cannot count how many times I’ve asked for reference documentation for classes and containers to apply to my theme’s block editor stylesheet. Trying to figure out the overloaded nested divs in the editor is a nightmare. Then there are many elements that no matter what you do to change the style, the core styles still cancel you out.

      Trying to get the theme front-end styles to match in the editor is an ongoing issue.

      There is also the problem of so many changes that happens with the “plugin” version of Gutenberg, that one has to design/develop a theme for several versions…and I’ve listed this before many times:

      Classic Editor
      Core Block Editor
      Gutenberg plugin

      Yes, three different environments to manage. Now, with what is coming, it just adds to the messy complications of adapting themes (new and old). How many more versions of the GB plugin will there be? Personally, the plugin needs to end and keep all GB development to the core.

      I still say to this day…and have since the beginning of GB…Matt (Automattic) should have built a completely separate WordPress that is built around Gutenberg and then leave the original WP intact as the Classic WP. Yes, it means two WordPress versions, but due to the complexity and completely different concepts, they should have been separate.

      Report

      • Alex M
        · Reply

        Your point about documentation is valid but as a developer it is not difficult to use the Inspector to learn the underlying markup and use your discernment to see what the best selectors to use are, just as you would when styling any other 3rd party applications.

        The good news is in WordPress 5.4 the markup and CSS of the editor got a lot simpler, so you should have an easier time learning what needs to be done. If it’s any consolation, I was able to rewrite the Editor Styles of my own theme for WordPress 5.4 in about three hours and now my user’s enjoy a just about perfect live preview writing experience.

        I was frustrated like you when I learned I needed to do a styles rewrite, but that was the kind of thing I expected to happen when I chose to support GB with editor styles and custom blocks. I am hoping not to have to do this again for a long time, and considering I first wrote my styles back in WP5.0 and didn’t need to touch them until recently, I am optimistic about the longevity of this rewrite. That I will give GB team the benefit of the doubt for as the editor has overall been a net positive for my customers.

        I have my own gripes about the editor and think I will have even more as it gets more invasive but as a longform post editor it has been nice to use.

        Lastly, and I don’t mean to pick on you, but I think that you having trouble with the “multiple environments” of GB/classic editor (assuming you are referring to meta boxes) is more of a reflection on you than the editor being bad.

        If we took that same logic and applied it to responsive design we would still see most sites don’t support tablet and mobile views because “they shouldn’t have to,” so why wouldn’t we develop our theme and plugin features to work in any environment as well?

        Report

        • Andre
          · Reply

          My “gripe” is more about documentation or lack of as it relates to theme development for the back-end editor. Also, using the inspector to view markup does not always work well without doing some hacks. Regarding multiple versions, I don’t make multiple themes for each, I integrate it all into one theme to cover the classic, block, and plugin versions. I even give the user the option to disable the GB stuff to lighten the load. As a side note, I even make the themes compatible for ClassicPress. Basically, many environments rolled into one theme.

          Report

    • Justin Tadlock
      · Reply

      I don’t think Carolina meant that necessarily in a negative context toward theme authors (being one herself). I think she’s saying that’s simply the situation we’re in. She’s going to try to do her part and bring folks up to speed, so come along on the journey. We have all been asking for more documentation. Here’s someone willing to put in the work to make that happen.

      Report

  2. Antony Smith
    · Reply

    So 6 months out there are still gaping holes, an undecided feature set, almost no documentation and the block editor itself is still in huge flux with fundamental UX and UI issues. Full site editing is shaping up to make the v5 release look smooth….

    Report

  3. Gary Taylor
    · Reply

    I’m really glad someone is trying to make sense of this. I just wish it was one of the people responsible for it!

    Look forward to see how this resource develops, it was a helpful read.

    Report

  4. Andrew Winyard
    · Reply

    Firstly I’d like to say that I’m super excited for the full-site editing capability. Despite all the stick it gets, Gutenberg needed to happen and is a great tool – one that we are all embracing and developing new blocks, plugins and themes for.

    Having said that, my experience with developing for the block editor for clients across several different versions of Gutenberg has been frustrating at times due to the lack of a frozen feature set and poor developer documentation. We just about get our heads around one way of doing things only to find it torn out in the next version with poor updates to the Gutenberg handbook.

    Features are great, but only with the documentation to back them up. One of the great aspects of the PHP side of WordPress is the stable core allowing you to develop knowing that your plugins and themes are unlikely to break with every other version release. This approach sadly hasn’t made it into the Gutenberg side of things. If full site editing also represents a minefield for many developers, they are unlikely to adopt it and develop themes for it.

    Maybe slowing down a little and allowing the documentation & community to catch up whilst ensuring things don’t drastically change so much version to version is more important right now.

    I think it’s fantastic that Carolina is trying to fill that gap with a much needed course. Kudos to you Carolina!

    Report

    • Antony Smith
      · Reply

      Ditto, I’m reluctant to invest time into learning and developing anything ‘seriously’ until they reach some island of stability however I have no idea when that’ll be or if it’s even planned. Lack of documentation says to me lack of spec [since my spec’s usually forms the basis of the docs] and lack of spec means lack of clear direction and goals. This unfortunately really shows.

      My beefs are not directed toward Gutenberg, it’s general concept or FSE for that matter. My problem is with the management, communication, direction etc well basically everything else. A total props to Carolina but this isn’t a gap she should have to fill, it’s the team ramming this through.

      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: