Cancel

Justin Tadlock

The Road Ahead: What’s in Store for WordPress for the Rest of 2020?

Full-site editing, automatic theme and plugin updates, global styles, and more await. With the release of WordPress 5.4 and an open call for version 5.5 tickets, it is time to peer into the future and catch a glimpse of what is to come. It is shaping up to be an exciting year thus far.

Josepha Haden, executive director of WordPress, provided a progress update on the 2020 goals in early March. As always, the timeline to hit certain goals can change based on roadblocks the development team hits and other factors. On the whole, the tentative roadmap looks feasible.

Currently, WordPress 5.5 is set to ship on August 11, 2020. Version 5.6 is scheduled to follow on December 8, 2020. Some major changes are forthcoming. Let us take a moment to look ahead and see where the WordPress ship is sailing.

Automatic Updates for Everything

Screenshot of the plugin management screen with a new automatic updates column.
Automatic updates column on the plugin management screen.

We have enjoyed automatic updates for minor versions of core WordPress since version 3.7. However, until recently, it has felt like progress on auto-updating everything had stalled. From mobile phones to smart TVs, the average end-user is accustomed to their software simply staying updated. In 2020, it is time WordPress continues pushing forward, particularly when staying updated is one component of maintaining a secure website.

There are two separate changes centered on automatic updates in the pipeline. The first, which is set to ship in WordPress 5.5, is automatic updates for plugins and themes. The feature plugin has been in development for several months and should be stable enough to launch with the next version of WordPress.

Plugin and theme developers will need to adopt a development strategy that aligns more with the WordPress philosophy of maintaining backward compatibility, at least to the point where an automatic update does not break a user’s site. This change is a welcome one because it will lead to a more secure web. However, it will be interesting to see how this plays out in the months to come. I am certain there will be a road bump or two that the developer community will need to overcome.

Automatic updates of core WordPress is slated to officially land in version 5.6. It should be an opt-in feature when it rolls out. The feature plugin should also be ready by the time WordPress 5.5 lands.

Block Directory Integration

Screenshot of the block directory page on WordPress.org.
WordPress.org’s block directory page.

The block directory first landed in Gutenberg 6.5 as an experimental feature. For those of us running the plugin, it is almost easy to forget that it is not already a part of WordPress.

The block directory is a listing of a special type of plugin that adds only a single block. In WordPress 5.5, users should be able to search and install blocks from this directory via the post editing screen. If you need a block that is not installed, you can install and begin using it without going through the normal routine with installing a plugin.

Full-Site Editing

Live Demo Q&A from The Gutenberg Times.

I am excited about the prospect of full-site editing landing in WordPress. I am concerned that a target date within 2020 may be rushing a feature that may not be ready. I want this to be a successful transition of how themes work and how users interact with their sites. I am optimistic about this future, but I am not convinced it will be good enough by the time WordPress 5.6 ships.

Aside from the introduction of the block editor itself, this will be one of the largest changes to how WordPress works in its history. Arguably, it is a more wide-reaching change because it touches both the backend user interface and how the theme templating system functions. It needs time to age before it’s dropped into the laps of end-users and developers alike.

I will be the first to jump for joy if I am wrong.

Currently, the plan is to complete the full-site editing feature in the Gutenberg plugin by the time WordPress 5.5 launches. It should still be behind the experimental flag in the plugin at that point. Then, ship the finished product in version 5.6.

Block Areas (Widgets)

Screenshot of the experimental block areas screen in the Gutenberg plugin.
Using blocks on the experimental block areas screen.

One of the features that has not gotten near enough attention is the conversion of traditional sidebars into block areas. This is a much-needed change in the mission to turn everything into a block.

Currently, it is planned to ship in WordPress 5.6, alongside full-site editing. I would rather see block areas as a stepping stone toward full-site editing. It would be less painful for theme authors to have at least a major release to ease into the next step.

The development of this feature could have been much smoother if WordPress would have simply deprecated sidebars and widgets. The Gutenberg team has had to pigeonhole a block-based system into the old widgets system. It is a little messy. Instead of the current approach, they should have created a separate system and allowed theme developers to begin opting into it. Because theme authors are the ones who will be handling support requests from end-users, they should have been given the power to handle that transition gracefully.

Overall, there should be no issue making sure block areas are feature-complete by 5.6. Much of the work is finished at this point, and we should be getting a more accurate picture of this feature in the coming months.

Global Styles

Screenshot of potential global styles toolkit for the Gutenberg WordPress plugin.
Example mockup from the primary global styles ticket.

A new global styles feature is set to ship for WordPress 5.6 later this year. The feature is currently undergoing heavy development. We should begin to see early iterations of it in upcoming versions of the Gutenberg plugin over the next several months.

Global styles will allow theme authors to create several default values, likely via a JSON file. In turn, users will be able to overwrite those styles through an interface in the admin.

My biggest concern about this feature is that it could go overboard with options that end-users should not have to concern themselves with. For example, most users should have no need to adjust the line-height for their text. Instead, line-height values should automatically be calculated based on a font’s x-height and size. The question is going to be where the global styles feature will draw the line. At a certain point, it is better to learn CSS. We certainly cannot expose every possibility via an option.

Other Notable Features

Lazy loading of images, which was originally planned for WordPress 5.4, will be shipping alongside a built-in XML sitemaps feature in version 5.5. Both features have been under active development for months and are stable at this point.

The navigation block was complete enough to ship in the previous WordPress release. The block is intended to primarily be used with full-site editing, so the block was not included. However, it is supposed to be available in WordPress 5.5.

As always, we should see a new default theme to propel us into the next year. My guess is that the core leads will want to ship a theme that is built completely on top of the upcoming full-site editing feature. If development goes as currently scheduled, Twenty Twenty-One could be a 100% block-based theme.

Category: ,
20

20 responses to “The Road Ahead: What’s in Store for WordPress for the Rest of 2020?”

  1. Well, I am not able to reach the benefits of this argument about how we should promote ease of use by exposing less features to users in the editor.

    In the same paragraph, I read two contrasting sentences:
    “For example, most users should have no need to adjust the line-height for their text.”
    (…)
    “At a certain point, it is better to learn CSS.”

    How can the proposal of learning a code language, even if its basics, through CSS, be better as an solution for the casual users, rather than allowing them to simply choose a value in a checkbox?! By redirecting their actions to a specific field, requiring them to translate their thoughts into code, instead, at this age of even quantum technology, this argument is just an arbitrary decision for how to deal with their wishes. It is really not the only way for us to better serve the community.
    Decades in programming have already taught developers how to organize complex code, and UX designers study decades to serve us very well to simplify these scenarios – where our arbitrary opinions clashes, there are methods out there with solutions for both of us.

    Page builders come to my mind: most choose to not be complex, still have found a way to structure options. The most used page builder, at the time of this writing, Elementor, for example: its public are mostly casual users, because of its ease of use, compared to other page builders. And all of the CSS options are there through countless options. Yet its interface is simpler than ours in Gutenberg.

    There is a reason to why Microsoft word, these plugins and such have become famous. And all of them are way more filled with options than the most bold idea for Gutenberg.

    What you envision is a better solution for some of us, for sure. Those that are able -and prefer- to achieve their content and design goals faster and freely from CSS code. But not casual users.

    Casual users are not users unable to deal with options. They are People, therefore they have diferent wishes, which one day Will require the option we may choose to hide, because we thought they wouldn’t ever need. CSS are the basic options (For us in code. Why not for them in design?). People are going to avoid what they do not need at the time. And what for them or for you is unnecessary, for another casual user is as necessary as a drug. These little options are what people rely for content creation.

    Gutenberg has a complex goal – many holes in the foundation is a rule or should be an exception?. What you propose is exceptions in the Foundation.

    Imagine if tax payers needed to learn code in order to answer urgent requests instead of on their mother lamguages? It could be better for those managing the requests? Okay, but better for everyone? No… out of scope.

    “We certainly cannot expose every possibility via an option.”
    It is true that we cannot expose every possibility via an option.
    But it is false that we …Certainly… need that.

    • Well, I am not able to reach the benefits of this argument about how we should promote ease of use by exposing less features to users in the editor.

      The article is asking where we draw the line in terms of the number of global styles options, not whether exposing fewer features promotes ease of use (although, that is a worthy topic to explore, which has been written about extensively based on user testing). There will be a line. You can count on it. Someone will decide what it is. It is best we begin exploring the topic before that decision is made. I imagine that line will see some adjustment over time, but it will be there, at least initially.

      In the same paragraph, I read two contrasting sentences:
      “For example, most users should have no need to adjust the line-height for their text.”
      (…)
      “At a certain point, it is better to learn CSS.”

      Those two sentences were meant to be complimentary, but we’re missing the context of the entire paragraph by picking them out. Nevertheless, once you get to a certain point with options that the majority of users do not use, the user experience degrades. Going back to “the line” I mentioned above. Someone will make a decision along the way that says, “Here are the options we’ll offer; the rest of the stuff will be left to custom CSS.” And, there is always that user who will need to do something more than what the editor provides, regardless of where the line is. When a user gets to that point, the only option left is CSS (or another editor, as the case may be).

      I used line-height as an example because I do not think that is a good v1.0 option. Provide some font family and font size choices. See how that works out. Test a solution that automatically calculates line-height (based on work I’ve done in the past, this has done well). Test a solution that provides the choice to the user. Get feedback. Determine the best course of action that mixes user choice with good design principles.

      How can the proposal of learning a code language, even if its basics, through CSS, be better as an solution for the casual users, rather than allowing them to simply choose a value in a checkbox?!…

      The article does not argue that users should learn to code CSS over selecting options. I would be happy to clarify anything I wrote. There seems to be a misunderstanding here that forms the basis for the remainder of your reply, so I’ll just leave things here. I’d be happy to discuss. I just think we’re on different wavelengths here.

  2. Yep! So we are adding more buttons to Gutenberg, while more pressing matters such as the 8+ years outdated SimplePie library and its PHP errors wither in trac-limbo

      • I saying this from my heart… as things are right now, trying to contribute anything not related to Gutenberg is so depressing and disheartening. Why bother when there are 1000s of good tickets that have been sitting in Trac for more than a decade?

        To do so would almost be a form of new-age sadomasochism. I mean, you yourself just wrote about one.

  3. It seems every single time WordPress issues a major update I like about half of what they do and the other half makes my life harder. Of course, this is coming from someone that still uses the classic editor (old dogs, new tricks, lol).

    It just seems like they are always making changes just as I am really getting used to specific features. I don’t mind the minor adjustments here and there, but how many times does someone have to create a new plugin to help us revert back to the old way of doing something because they new way just isn’t as clean or as easy?

    • The biggest user-facing change is really going to be the full-site editing feature. I am certain there will be a long transition period where this will basically stay the same for many people. Before it becomes useful, it will need to have buy-in from theme authors. And, right now, it’s not anywhere near feature-complete enough for theme authors to really build on top of it. I’m not sure how this transitional period is going to work, but I’m guessing full-site editing is not going to be a reality for the majority of users for a while.

      Much of this is a guessing-game at this point though. We’ll see how it unfolds in the coming months.

      As for the rest of the features, they shouldn’t put much burden on user experience. They will mostly be a few extra optional features for those who want to explore them. The UI work that’s happening right now, at least in my opinion, is making things easier.

  4. The fact is that Gutenberg is complicated for customers, and I say this as a developer. I like idea of Gutenberg and this is easy for me, but some clients cannot deal with Gutenberg at all, and studying Gutenberg takes a lot of time with their content managers. Gutenberg’s user interface improves with each update, but after each update, I also need to inform my clients what and where they are after the next update, because the customers simply do not understand what happened.

    • I haven’t done any client work in the past few months (aside from setting up friends and family). But, it’s been my experience that the block editor has made things much easier for novices.

      I think it mostly comes down to individual experiences. We need to continue sharing specific pain points with the development team to help them improve the software.

      I’ve been very critical of backward-incompatible code changes, which forces theme authors to either support only the latest version or write CSS for multiple versions. To me, that has hurt updates more than anything. If a theme author isn’t on top of this, it creates a poor user experience.

      • None of our customers will use it. Only a couple people on our staff use it on a couple sites for landing pages. I personally don’t mind it, but I’m a developer and seldom post things. But the overall experience from our customers is that’s it’s confusing and all the options are hidden, they tend to prefer the old editor because they’re just adding text content and maybe a couple photos, they’re not trying to create magazine layouts. Content is king after all.

  5. I think we’ve lost sight of one of Gutenberg’s primary objectives. Per Matt M, “The overall goal is to simplify the first-time user experience of WordPress…” https://ma.tt/2018/11/a-gutenberg-faq/

    As a website designer who works with clients all day, every day, I can tell you that the Block Editor is already over-featured, confusing and frustrating for the average user. All they want is to be able to add content quickly and easily.

    Expanding the Block Editor to being a full-site editor is downright scary. We will need to restrict access to blocks based on user role — with authors and editors only able to use a subset of block types to prevent them from breaking the website.

    Perhaps it is more logical to restrict access to blocks based on post type. Pages are typically built by designers or power users who will need the full set of block types. Posts are created by less-expert authors and expected to conform to a standard template where they share the same look-and-feel. For these, there will be many blocks that should not be used. And for custom post types (for example, events, jobs, documents…), similar block-type restrictions would be desirable in the real world.

    I’m praying that that we don’t do what Mary from London is proposing. Adding an option for every CSS option (line-height in her example) will create an unwieldy user-interface, further complicating the post creation and editing process. That would transform the Block Editor into the likes of Elementor, Divi or any of the other mega-themes, which are beyond the skill set of the average user. Every option we add makes the block editor more complicated and potentially makes authors and editors less productive.

    Let’s not lose sight of the original objective to make the block editor simple to use.

    • Exactly this.

      Gutenberg seems to only think of one user admin installations, which is not a real world use case for most more serious business websites.

  6. Egad, I’ve just almost completed reformulating my theme to take advantage of block-related css calls and structures (which are consistent only in their inconsistency). Dequeued the block editor css and replaced it with just the calls I needed. And I’ll have to do it all again at the end of the year if the underlying template structure changes… so time to read up on full-site editing, I guess. Hurrah for the block library though, that’s a useful addition

  7. As a Web Designer who most especially works on blogs for clients, majority of my client haven’t even brought themselves in an agreement to Gutenberg because it seems confusing to them..

    I hope the WP team doesn’t make it more confusing

  8. I concur with comment above … “It seems every single time WordPress issues a major update I like about half of what they do and the other half makes my life harder.”

    Why make drastic changes when most are working off site and don’t have the benefit of in-office help?

  9. WP has long claimed “decisions not options” best served the 80%. I don’t always agree with that, but FSE isn’t a decision. FSE isn’t even giving needed options. It’s abdicating making any decisions and giving users a very abstract and very complex tool (very cool tool, but still crazy complicated for an end user). I’m not sure how, but menus in FSE are even worse than in the customizer.

    The users I work with are still 50/50 frustrated using Gutenberg. They do like it better than the Visual Editor, but not better than BB/E. Mostly because they can’t control the things they want to control, like font sizes at various break points, make columns, or make sense of the bazillion blocks available .

    What they really want is a true WYSIWIG content editing experience, not one with weird extra padding, or empty caption fields, nor where they can’t tell how something will look on mobile while editing on desktop, etc… that all still confuses the heck out of them daily.

    Finally, the above comment is really right, there are 1000 4+ year old tickets that ought to get more attention than FSE IMHO. I long ago gave up even bothering with trac when tickets I cared about, with patches, with testing, with clear and narrow scope, left unmerged for years.

    Maybe FSE won’t get merged for 4 years. That’s be OK with me. I get the vision, I think it could be useful to come users, but not as it’s currently built.

    On a positive note, I do agree that block based sidebars would make a nice stepping stone.

  10. Thank you for this article. I am looking forward to all the features coming in WordPress 5.5. I like the search and install blocks feature mainly, hopefully wordpress 5.5 will be released on time as the current situation is looking good around the world.

You may also like

Newsletter

Subscribe Via Email

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

%d bloggers like this: