First Look at Twenty Twenty-One, WordPress’s Upcoming Default Theme

Fashion is ephemeral. Art is eternal. Indeed what is a fashion really? A fashion is merely a form of ugliness so absolutely unbearable that we have to alter it every six months!

Thus wrote Oscar Wilde on Victorian-era fashion in an article titled “The Philosophy of Dress” for the New-York Tribune in 1885.

In many ways, WordPress theming is the same as the ever-changing landscape of fashion. Rounded corners are in one day and out the next. Box shadows are in one year after being frowned up just months earlier. Perhaps web design is so intolerable that we must change it every six months. Or, at least freshen it up every year in the case of WordPress.

If art is eternal, there are only two default, Twenty* themes that I can truly recall from past years: Twenty Ten and Twenty Fourteen — yes, Twenty Twenty is memorable, but it is also still the current default. Twenty Ten was a classic that paid homage to WordPress’s past. Twenty Fourteen was such a leap away from tradition that it is hard to forget. Everything else has seemed to fade to varying degrees.

With WordPress 5.6 and the end of the year looming, it is time to look forward to the latest trend. As Mel Choyce-Dwan noted in the announcement of Twenty Twenty-One, the next default theme, “Pastels and muted colors are pretty in right now.”

She is not wrong. The colors are a refreshing change of pace. Now that we are into the second day of autumn, I am getting the good kind of vibes from some of the more earthy-tones from a couple of the color palettes expected to ship with the theme.

Color palette options for the Twenty Twenty-One WordPress theme.
Potential color palette options for Twenty Twenty-One.

Whether Twenty Twenty-One will be a fashionable theme for the year or art that we can remember a decade from now, only history will be able to judge. For now, let’s enjoy the creation and take a look at what we should expect from the next default WordPress theme.

The Current Twenty Twenty-One

The new default theme is a fork of Automattic’s Seedlet, a project in which I lauded as the next step in the evolution of theming. It is a theme that is focused on WordPress’s future of being completely comprised of blocks. It gives us an ideal insight into where theme development is heading. It makes sense as the foundation for the new default. Few other themes would make for a good starting point right now. With WordPress theme development in flux, Seedlet is simply ahead of the pack in terms of foundational elements.

Homepage view of the Seedlet WordPress theme.
Seedlet WordPress theme screenshot.

“This provides us with a thorough system of nested CSS variables to make child theming easier, and to help integrate with the global styles functionality that’s under development for full-site editing,” wrote Choyce-Dwan of using Seedlet as a starting point.

There are no plans to spin up a Google Web Font for this theme. The design team is going native and sticking with the default system font stack. Choyce-Dwan listed several reasons for the choice, such as keeping a neutral font that allows broad use, speed, and customizability via a child theme.

Despite the neutral font, the default pastel green is a fairly opinionated design decision. It will not be used broadly across industries. However, the team plans to create multiple color palettes that will give it more range. Presumably, these palettes can also be overwritten.

Single post view of the Twenty Twenty-One WordPress theme.
Pastel green color scheme on single post view.

Other than the colors, the design is relatively simple. Choyce-Dwan said that the theme’s block patterns support is where it will be truly unique.

I was initially unhappy with the patterns that were going to ship with WordPress 5.5. However, an 11th-hour update improved the situation so that they did not feel entirely experimental. The foundational Seedlet theme for Twenty Twenty-One has some unique patterns that begin to scratch the surface of what’s possible with this WordPress feature. My hope is that the new default theme steps it up a notch.

Currently, the theme does not register any custom patterns. However, it has a placeholder file and a note that they are a work in progress. Choyce-Dwan shared some patterns the team has already designed in the announcement.

Three block patterns provided by the Twenty Twenty-One WordPress theme.
Currently-designed block patterns.

“We’ll be relying on our talented community designers for more ideas,” she wrote. The team has also created a GitHub template for anyone to contribute pattern design ideas.

Currently, the theme does not support the upcoming full-site editing feature of WordPress. After the Beta 1 release of WordPress 5.6, the team plans to begin exploring the addition of this support. WordPress is expected to ship a public beta of full-site editing in its next major release, but it is unclear whether it will be far enough along to be a headline feature for the Twenty Twenty-One theme.

The team and volunteers have less than a month before the October 20th deadline for committing the new theme to trunk, the core WordPress development branch. At that stage, the theme should be nearly complete and ready for production. Of course, there will be several rounds of patches, bug fixes, and updates before WordPress 5.6 lands in December. Right now is the best time for anyone who wants to get involved with Twenty Twenty-One to do so.

Useful links with more information:


4 responses to “First Look at Twenty Twenty-One, WordPress’s Upcoming Default Theme”

  1. Back in 1997, a small company that I worked with had developed a first-generation CMS, when it was still fashionable to design every website from scratch, using some sort of handcrafted ‘backoffice’ which allowed end-users to add a bit of content here and there. This particular company had done this so often that they were getting tired of always reinventing the wheel, and so decided to develop a full-blown CMS instead. Version 1.0 was even open source (we had no GitHub back then!).

    Beyond being blindingly fast (these were the days when code was code, not endless declarations of abstract classes spread over a thousand library & framework files…), and including things that are considered absolutely indispensable today (such as an effective caching system that would work with Apache rewrite rules in order to avoid over 99% of all backend queries to the PHP + MySQL engine; or complex analytics built-in into the system, before Google even existed, much less Google Analytics; or full support for restricted areas and dealing with frontend user registration separately from backend users), one awesome feature it had that I always loved was the concept of layouts that were essentially different ‘blocks’, called ‘objects’. An object had its own mini-layout and there was a very simplified programming language that allowed end-users to instruct the CMS to display certain kinds of content; there was no limitation on the amount of ‘commands’ that could be added to a single object. Although simple enough (they would basically work as user-friendly SQL-like queries, but much, much simpler), this solution was immensely powerful and allowed you to design pretty much any type of website, because you were not limited to the concept of ‘one theme/template with slots for widgets’. Each ‘object’, while similar in concept to widgets, could be placed wherever needed, and effectively worked as a ‘mini-website’ embedded inside the overall look and feel of the page.
    When the first open-source CMSes (including WordPress) started to become not only available, but popular, I was impressed by their wonderful backoffices — but frustrated by its abilities to configure different kinds of websites. Joomla came closer than WordPress in this regard, but to accomplish similar results, you’d have to start a mega-project under Drupal and basically write everything from scratch.
    Over the years, this company went on to develop a version 2.0 and even a 3.0. These were not backwards compatible in the least, and were never released as open source. Although the backoffice was incredibly minimalist (even for developers) and these subsequent versions reflected more modern programming styles, they still built on the original concept, where ‘objects’ slowly became ‘building blocks’ of code that could be reused on different websites (not unlike what we’d call ‘plugins’ in WordPress — with the difference that they were stored in a completely different way). Last but not least, as it became clear over the years that the biggest bottleneck was the MySQL database, version 3.0 introduced the concept of a database-less, flat file CMS, before such a concept even had a name (although it was by far not the first CMS doing so).

    That’s past history. This is 2020. The company behind that CMS has essentially shut down — before the pandemic, at the height of the economy — for the simple reason that most of the team (including the owner) was ‘bought’ (not the company, though) to work for one of their former clients, full-time, earning tons of money.

    While I will always miss the simplicity and ingenuity of the 1.0 version — I’ve still copies of it stored somewhere; there are even a few companies out there still using it; it was a pain to get it working under PHP 5.6 and it barely works on 7.+, but it requires major code changes to keep up with current technology, way too much for me to waste more time with it. Possibly the first site I’ve migrated to WordPress was my own blog, back in 2005 or so — even by then, WordPress was way easier to maintain than a 8-year-old CMS which was officially unsupported. I missed a lot of its features, though, but of course WordPress was simply unbeatable in terms of ease of use, overall configuration, tons of plugins (even back in 2005), and frequent updates. It lagged behind in raw speed and performance by a wide margin, but sometimes performance is not everything. I moved on with times, and these days, except for the occasional Grav blog, I pretty much host everything on WordPress.

    Obviously, I still looked at other CMSs advantages that seemed ‘impossible’ in WordPress — such as the Gutenberg block editor. Strange at first, but a must these days. I’m plagued with old-generation WordPress websites which use shortcodes or their own ‘templating engine’ plugged into WordPress to, uh, ‘overcome its shortcomings’ by introducing Joomla-like features (ugh!) in a clunky way. And the next theme I’d buy would introduce a completely different way of doing the same things. And many things still seemed to be impossible; one of the first plugins I used, for instance, was to get a shortcode to publish a series of links to articles based on a specific query (i.e. just show the titles + excerpts of one category) — it seemed amazing that such functionality wasn’t part of the ‘core’ WP, and that it was so hard to implement. I used to tweak themes all the time because so many had the wrong approach to certain features I needed or wanted, or completely lacked support for other features. These days, fortunately, both WordPress and the theme designers and programmers are becoming more sensible in their approaches — I have been restricting my tweaks to the minimum, and, over time, with new features being introduced all the time, my own tweaks often become obsolete (thankfully so!), and I can rely more and more on what is provided directly from Auttomatic or any theme/plugin developer.

    I think that there is a revolution ahead, if the ‘new’ WordPress will work in the way you describe in this article. Fortunately for all in the WP community (do we call ourselves ‘wordies’ or ‘pressies’? ;-) ), Auttomatic didn’t relent the pace of development, even after WordPress becoming the #1 CMS in the whole world, contrary to all expectations from the Big Players back in 2005 or 2010. WP is still innovating — but, more important than that, it’s bringing whatever functionality is available on other CMSs and make those integral to WP’s core. Oh, sure, plugin developers will grumble about many of the changes — especially those who have spent aeons developing complex plugins to accomplish what used to be ‘simple’ tasks that were later introduced in WP, and made good money out of that development. It’s sad, but Auttomatic has no real choice but push harder and harder, to stay on top of current developments and fashionable features that CMS users ‘require’ from a modern CMS.

    I think that one of the most dramatic changes in the past was the move away from posts/pages/attachments towards taxonomy. The second, IMHO, was Gutenberg — replacing a gazillion plugins and themes that have tried to do something similar, with more or less success. Gutenberg still has lots of tiny, annoying issues, but it’s plodding along nicely. Themes with ‘template parts’ was also a must — considering that plugins such as Gantry have been doing that for years and years. And… well, the obvious next step was what they are now calling ‘patterns’. These will trigger the next revolution (even if I have no idea of how exactly these are going to be implemented!). But we need those revolutions.

    Almost twenty years after WP 1.0 was released, it’s a comfort to know that WP is still innovating, not only ‘catching up’ with whatever has been released by ‘other’ CMSs, but pointing towards the future.

    It’s always fun to read how it all started and evolved into the platform we use today.

    I’m looking forward to a database-less, flat-file ‘option’, one that does not even require Apache/nginx + PHP to be installed but is based upon a constellation of components/microservices that follow an SOA approach. Oh, we will be there one day with WordPress, I’m sure! :-)


Subscribe Via Email

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

%d bloggers like this: