21 Comments

  1. Nick
    · Reply

    Thanks for bringing a topic that keeps me awake at nights Justin. Because of the Gutenberg’s limitations, 2 days ago I found another little trick Pattern developers are using to get around those limitations. This is more acceptable but unseasoned web designers are going to be perplexed if nobody explains to them what’s going on:

    This time, the example I will be bringing it’s not from a theme but directly from the soon to be available – core patterns directory – Example pattern: https://wordpress.org/patterns/pattern/illustration-of-bird-with-callout/ .

    Testing environment: WP 5.8 beta 2, Gut. 10.8.2

    So this is the issue: The pattern comes with a button, if you want to add a second button, one would naturally press the inserter button and create a new button. The problem is that new buttons you create in this pattern will not look the same as the one that comes with this particular pattern. All new buttons will be pill shaped, as the pattern has a rectangular shape. It took me about 15 seconds to realize what is going on, and refusing to look like an idiot anymore, I checked the button’s html code. Surely enough, they had hard coded the CSS code on how the button should look like.

    At this point I had 2 choices:

    Create a new button, switch to html mode, and add all the necessary CSS code for all the buttons to match, or the easiest method:
    Duplicate the button that came with the pattern, and then visually edit the text and link of this second button.

    If one does not realize what’s going on, or does not know CSS, will have a hard time doing anything remotely useful things with these patterns, except simple text/images, etc… substitutions.

    Finally you mentioned about the old-school purity of not mixing content and design is gone. Well, with it what’s gone are parametric (advanced) searches, and front end editing. I can create a a Real Estate block that will hold all the information regarding properties, but there is no way to ask visitors to submit their properties from the front end, and even though I can search for a house in Los Angeles, OR a house with 4 bedrooms, OR one that costs exactly $1,000,000 (no ability for numeric comparisons here), but there is NO WAY I can ask the site to find me a house in Los Angeles, WHICH has 4 bedrooms, AND costs between $1m – $1.3 million.

    For these 2 things (advanced searching & front end editing), you not only need to separate content from design, but your content must be structured, like using custom fields, so you can separate the text from numeric fields, and conduct these complex searches. Some things are simply not possible with Gutenberg, sometimes you have to do things “Old-School”.

    I think I just gave you a new post idea for next week… thanks for everything Justin.

    Report

    • Andrew
      · Reply

      “Surely enough, they had hard coded the CSS code on how the button should look like.”

      The CSS has not been hard coded, rather it is in the format that the block system recognizes and can interact with. With this you are able to change the background color, text color, and border radius with the block tools in the right-sidebar.

      I was able to add a new button right next to the current button, and style it exactly the same with minimal effort.
      One small issue is that despite the initial state of the border-radius option showing as zero, Gutenberg gives buttons a default radius of 9999px!
      To change this to zero, I had to change the radius up from 0 to 1, then back to 0 for it to take effect. Not ideal in real world usage.

      Report

    • Andrew
      · Reply

      You wouldn’t use patterns to build a searchable real estate site or one with visitor submissions. A pattern would be ideal for or a single property site where the site exists only to market that particular property.

      For a fully interactive real estate site, a dedicated plugin would be used.
      The way the block editor then comes into it’s own, would be that the templates that display the property details would be block based, allowing you to edit the layout, design etc.
      In this template you may have a price block, a number of bedrooms block, a gallery block etc. You would then be able to move these blocks around, position them where you want, style them how you want within the property template.
      The properties would be fully searchable as the info for each property is not hard coded on the page, it exists in the database with the front-end display determined by how you have edited the property template.

      Report

    • Mounir
      · Reply

      Awesome comment Nick.
      Regarding the parametric search, I think we might see the comeback of {{ mustache }} tags and some form of metaboxes.

      Regarding the white text over white background and similar issues Justin, maybe the directory should enforce the use of default classes along with those custom ones used by the theme developers.

      Report

      • Justin Tadlock
        · Reply

        Regarding the white text over white background and similar issues Justin, maybe the directory should enforce the use of default classes along with those custom ones used by the theme developers.

        The problem with that is that the default slugs do not follow a reusable naming convention. For colors, they are things like cyan-bluish-gray, luminous-vivid-orange, vivid-green-cyan, and so on. Except for white and black, which are pretty universal names, it is a bit of a mess.

        Report

        • Mounir
          · Reply

          Very creative names, lol.

          That, currently, is a developer problem and not a user one.

          Unfortunately, it could also become a user problem if, at some point in the future, it is decided to set up naming conventions and since the current stance on things (since WP 5.0) is no longer backwards compatibility, we could re-encounter this problem of broken design/display.

          Report

    • Justin Tadlock
      · Reply

      As Andrew said, the Button CSS is not hardcoded. It’s created using the standard block options. But, that does bring up an interesting UX issue that I had not thought about. If users expect the same-styled button, they cannot get it by clicking the “+” icon to add another.

      They must either recreate it themselves or duplicate the block (assuming the user knew how to duplicate). This is also the same issue without choosing custom color and border options. Simply selecting a block style like Fill vs. Outline would result in the same behavior.

      For the Real Estate block, you could technically save content as metadata. However, I would create a CPT instead. Then, create a custom Real Estate Search block for advanced searching of metadata, terms, etc. I can’t think of any good reason to try to encapsulate all of that into a single block outside of a site that showcases more than a handful of properties at a time.

      Report

      • Nick
        · Reply

        About the CSS, I could have chosen a better word I guess, I should have said hand coded and not hard coded.

        As far as the silly example that I brought up – the Real Estate site, using CPT or not or using a plugin or theme to code it, has NO bearing in what we are talking about here. The issue on hand was old-school vs new-school. And unless I’m totally wrong, Justin, by you suggesting to use metadata (which I had already suggested – because it’s the only way), you are re-enforcing my argument. By using metadata, you are separating content from design. Not only you are separating the two, but you are getting the data and structuring it by field types (at least that’s what ACF and Tooset do). And that is old-school, which makes it very much alive, and still necessary in many instances.

        Nothing is perfect though… With metadata you get really bloated databases that Gutenberg avoids by combining the content with the design, but once again, that could be another blog post idea to explore.

        Bottom line, using blocks or metadata will depend on one’s priorities and necessities, and both approaches have their advantages and disadvantages. I think it’s up the Tavern’s of the world to bring up these controversial subjects to raise awareness, resulting in better core code quality and make things better. There is a reason while WP is 41% of the Internet, we are never going to see the next Facebook, or Twitter, and any app. type site, like a globally popular Classified, or Auction site, made with WordPress. Before jumping on me again, I’m talking about sites with millions of users, and billions of records in the database(s). Of course, it is possible to go the WP route, but it will be extremely expensive, in terms of hosting and database load balancing – you better use something else.

        Report

        • Andrew
          · Reply

          Nick, you are right that using a plugin has no bearing on what you are talking about. When I mentioned using a plugin it was my clumsy way of trying to explain what was going around in my head.

          When you say that gutenberg combines the content with the design, I don’t see that as entirely true, it only partly describes Gutenberg blocks.

          It’s true there are blocks that are content and design combined such as;
          Paragraph
          Heading
          Image
          List
          etc..

          There are also blocks that are dynamic combined with design such as;
          Site Logo
          Site Title
          Post Date
          Post Author
          etc.. way too many to mention here.

          What I’m trying to say is that when writing a post, you wouldn’t manually add the name of the post author, or the post date using a paragraph block for example.
          These dynamic blocks exist so that they can be used in the template that is powering the posts. These blocks can be designed in any way you want; change the color, background, size, spacing etc. but you dont’t manually write the content of the block each time you use it in a post. This is where the templates come in, allowing you to move these dynamic blocks around, add or remove these blocks, and edit the design of these blocks just how you like.
          A separate issue, but kind of the same is that there needs to be some way of distinguishing dynamic blocks from content blocks in the block inserter, as it is currently not immediately clear which is which. I’m sure there are many discussions in github about this.

          Likewise with the real estate – it’s not a silly example – is a good example of how things initially seem confusing. I didn’t see the point of the block system to begin with, but as I worked with it more there was a point when it suddenly clicked and became clear to me the potential of Gutenberg blocks.

          With the point about the CSS in that particular block pattern, there really is no way to tell whether the CSS is hard coded (or hand coded) by looking at the html code. The resulting code will be identical whether the author used the block tools, or wrote it by hand (assuming they didn’t make a mistake when hand coding it). There may be clues that a pattern could have been hand coded such as ordering the style args differently to the order that the block tools would output, but the order doesn’t matter as it will still work just as if the pattern had been created fully with the block tools.

          Report

  2. XR
    · Reply

    Thx for the article, interesting issue. I found your anti-locked in arguments more convincing than the pros. Modularity anf customization possibilities should focus on the user perspetive, not the brand. And sometimes theme provides way to much features, I often feel that it would have been simpler to just edit few CSS lined than finding my way in customize menu and sub menus.
    We may find advantage in the new paradigm but it doesnt seems than better than the old. Just different, with some advantages, and some cons.

    Report

  3. Daniel James
    · Reply

    I’m surprised that even nowadays there isn’t a way to port styles over to some kind of universal system within WordPress to avoid this issue. I think it stems from the fact that developers/brands want you locked in (purposefully) to keep using their products.

    I can understand why, however it creates a lot of trouble for site owners to migrate to different themes and plugins over time which does hold back the community in improving their sites. I don’t think there’s an easy answer to this, but hopefully a solution can be thought of.

    Report

  4. Eric Karkovack
    · Reply

    Very good points, Justin! It’s like we took the old page builder lock-in and just moved it over to the native editor. I guess that’s better, but still something we need to think about.

    As I’ve built more client themes with Gutenberg in mind, I’ve tried to find some ways to work around it. For instance, I went from creating custom ACF Blocks and sticking them into the theme to creating a custom plugin that allows them to survive, no matter what theme is used. Any custom block CSS is also included in the plugin.

    Developers are going to have to consider these things. But it will be interesting to see how Full Site Editing impacts the theme market. Maybe you’re right and people won’t see the need to change themes as often.

    Report

  5. Andrew
    · Reply

    As is often the case Justin, the very last paragraph of your article is the one which resonates most with me.

    I see a future where themes will be just a starting point. When the user is able to edit every template/template part, and the global styles too, and also create their own templates that maybe didn’t exist in the theme, at what point does the site become unrecognizable as being “powered by” the base theme?

    Report

  6. Nathalie Lussier
    · Reply

    This has been on my mind a lot, too. You’ve explained it much better, and it’s something that we need to think about as both plugin and theme creators.

    One thing that can really stump end-users is if they don’t know how their site was built, and what will happen if they decide to change something. That tends to freak people out, and they sometimes want to just start over and give up.

    I’m not sure how we overcome that, when some of these issues are pretty nuanced and technical.

    Report

  7. Eugenia (Franci Hoffman)
    · Reply

    I’ve been a WordPress fan since 2015. I have two WP.com blogs. One is for poetry, which is simple with a black background (I love black backgrounds because it adds appeal to certain types of literary works.)

    I have another blog, where I run a weekly prompt. Once weekly prompt posts gain momentum, the blog host has to find ways to maintain and hold their participants. This is where a theme with a few extras wins the blogger’s attention.

    I’ve tried many of the WP.com Premium themes and finally found one that addresses pingbacks and actually lists them all in one area. I love this feature because I can avoid using Mr. Linky to present a wrap-up post to my participants. Yes, I feel locked into this theme and hope it continues to be updated (Opti). I miss some of the themes that were not updated because they were unique by design. Thank you for all you do WordPress.

    Report

  8. Francesco Guilliani
    · Reply

    when they end up in scenarios with white text on a white background

    Which can only happen if colors are hardcoded within content – which reveals a “broken by design” problem of the underlying editor.

    Report

    • Justin Tadlock
      · Reply

      You don’t have to hardcode colors for this issue. You just need a lack of a standardized class-naming system. It has far less to do with the editor itself than convention.

      Hardcoded colors would have actually prevented this situation because the blue background would’ve still been there. But, using them would create other design problems.

      Report

      • Alina Grabowski
        · Reply

        Hardcoded class-names are basically the same as hardcoded colors.

        The main problem is that the editor obviously stores information about layout, colors, typography etc. within the content itself.

        That will always lead to confusion if some day another “theme” should be used and tries to show that content or if content should be exported etc.

        All layout, color, typography information should be stored in some post_meta or similar – not in content itself.

        Report

        • Justin Tadlock
          · Reply

          Classes are not the same as an hardcoded, inline styles. They are similar if you use class names like .has-blue-text-color, but that is a far cry from a class like .has-primary-text-color.

          Storing the same thing as post meta or elsewhere does not address the issue either. Those still need to be printed out somewhere, and you still must tie them to the block itself either through a class or ID.

          Utility classes are always going to have their place, particularly if you are going to pass some level of design control down to the user. But, there are ways of doing them that are more forward-compatible than others.

          Report

  9. CW
    · Reply

    Imagine inserting a Paragraph block and choosing that sky blue from your theme as the block’s background. Now, imagine doing this a few hundred times only to have it disappear a couple of years down the road when you want to switch designs.

    Have the blue background just disappear isn’t ideal in this situation, but neither is keeping it. What happens when someone updates their brand color scheme and that sky blue – from a theme or from the default gutenberg color options – has been added hundreds of times? If the website lasts longer than five years, the user will probably want to update the look at some point.

    This is why mixing design in with content and then saving the settings of every block separately in the database is a mistake. We’re practically back to html font tags. React was not designed for this either, CSS and html were supposed to mix together, but the data layer was supposed to be separate.

    It’s one thing to give users an option to override defaults and take things into their own hands, it’s another to put every user in the position of having to make design choices and then get locked into those amateur choices because it’s too much work to update hundreds of blog posts.

    If I’m missing something here, let me know. I’m still astounded that the system was designed this way.

    Report

    • Justin Tadlock
      · Reply

      Have the blue background just disappear isn’t ideal in this situation, but neither is keeping it. What happens when someone updates their brand color scheme and that sky blue – from a theme or from the default gutenberg color options – has been added hundreds of times?

      The ideal situation would be that the blue would transform to your new brand color.

      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: