I am a writer. That gives me a license — not to be overused — to steer into hyperbole once in a while. I get to be critical, sometimes overly, because I can come back the next day and shower the WordPress project with praise. Perhaps, at times, I forget to be as fair or kind as I should be. Maybe I miss the mark when pointing out faults once in a while. I am sometimes simply wrong (as one reader recently pointed out, that was the case with 90% of what I wrote). And, for those times that I do step out of bounds, I am sorry.
However, it always comes from a genuine love of our community and loyalty to the WordPress mission.
I had planned on writing about an upcoming feature change for WordPress today, but something more pressing came up. As I was working through that article, a new comment landed in my inbox for approval. It was on the borderline, that gray area where I had to determine whether it added enough value to the discussion. I felt like it needed a thoughtful reply and not the knee-jerk reaction I had initially written. It was gnawing at me because I knew few things could be further from the truth:
When Matias and Justin respond to comments and ask the commenters to supply more details about the problems they mentioned, I doubt many will do that, since many of us already know that the WordPress developers don’t listen to us. They maybe pretend to listen, but the evidence shows that they do not. As one other commenter mentioned, we are suffering the tyranny of the minority.
It is disheartening when I see comments that state that the core contributors do not listen to users. However, I do understand where some of that sentiment may come from. There have been many pet features I have been passionate about that have never gotten the green light. Tickets that seemingly die out from lack of interest. Unresolved disagreements. It can become easy to think that you are shouting into the void.
However, it is not because developers are not listening. That is not a fair statement to make.
In my line of work, I follow nearly every aspect of the WordPress project. From Trac tickets to GitHub pull requests, from business acquisitions to theme development, I tend to dabble in a bit of it all.
More often than not, I see others who care as deeply about the project as I do. I watch the core/inner developers — the folks who do the bulk of the work — gather and act upon as much feedback as possible. I see the same from people who are less in the public spotlight but just as vital to the community. Everything I see stands as overwhelming evidence that they listen. There is so much engagement on GitHub, Slack, and the Make blogs that I cannot keep up with it all.
Matías Ventura, the Gutenberg project lead, has always been approachable and seems to care deeply about the project’s success. I cannot recall ever reaching out to anyone working on WordPress who did not respond, even when I approached them outside of my role as a writer for WP Tavern.
I am amazed at how much time and energy Anne McCarthy puts into the FSE Outreach Program. Mostly, it is because I do not think I could do that job. For every complaint, criticism, or issue I have mentioned, she has dug up an existing ticket or filed a new one. She routinely does this for everyone who provides feedback on FSE.
I could list name after name after name of others who do the same, going above and beyond their typical roles.
Today, I was reminded that we all — including myself — sometimes need to step back and evaluate how we view this project and the people who are working on it.
Thousands of people contribute code, documentation, design mockups, translations, and much more. There are plugin authors who see a problem they want to solve. Developers who figure out how to do something and write a tutorial. This, still, is barely scratching the surface.
Contributing directly to the core project or being involved with the Make WordPress teams is often a thankless job. But, I am happy that so many are willing to bear the brunt of the criticism and continue working.
Not everything we want will be implemented how or when we want it. Developers must balance each new feature or change against different, often conflicting, feedback. They do not always make the “right” call, but the best thing about software is that you can iterate upon it, bettering the platform from feedback on the earlier implementation.
Sometimes, WordPress simply needs more folks contributing to create a new feature or implement a change. Developers are only human.
We are all riding this ship together. We should strive to be kind and fair, avoiding blanket statements of the people who pour their hearts and souls into the project.
If nothing else, let’s take folks at their word when they ask for more details about a problem. That could very well be the first step in actually finding a solution.
Before stepping off my soapbox, I want to simply say one thing to those who contribute in any capacity to the WordPress project: thank you.
For many years, I was a hardcore advocate of separating any non-design functionality from themes into their own plugins. I wrote extensively on the issue. Whether it was shortcodes, custom post types, user metadata, and any number of things related to a user’s content/data, I drew a deep line in the sand. This belongs in a plugin.
If you have never heard of the “theme lock-in effect,” that’s OK. For many, it is a non-issue. Places like the WordPress.org theme directory have, for the most part, drew a similar line in the sand.
The goal has always been to avoid trapping a user into perpetual use of a particular theme. It is not an ideal user experience when some crucial data is no longer available when switching designs. And, all users eventually want to change that up from time to time. Getting stuck with [shortcode-soup] tags littered throughout a site is never fun. Neither is losing admin access to dozens, hundreds, or even thousands of pages from a custom post type that suddenly disappears.
The WordPress theme development community has avoided this problem — some more so than others — by bundling crucial content-related features separately in plugins.
Those theme authors who bypassed theme lock-in via plugins have mostly done so in their own silos. For example, instead of integrating with an existing portfolio plugin, they would just create their own. The only themes that support that plugin? Theirs. Ultimately, users were still trapped.
I cannot lay the entire weight of this issue on the shoulders of theme authors. Portfolio plugins are a dime a dozen. Supporting WooCommerce for an eCommerce solution or bbPress for forums are easy choices. But, when there is no clear industry front-runner, an in-house solution is just as good as most others.
However, the block system is already complicating matters. When a theme supports features like font sizes, colors, and gradients, it essentially locks users in. Switch to another with a different configuration, and every font size, color, and gradient the user chose to use is gone.
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.
I won’t dive into the technical details of how this works under the hood. It is just the way the system was designed. Some problems could have been mitigated early on, but that ship sailed two and a half years ago with the launch of WordPress 5.0. There are also ways this might be solved in the future with technical workarounds.
Last week, a reader named Nick brought up this issue in regards to block patterns. The theme in question used custom CSS classes to achieve a specific design.
Because Gutenberg lacks all the features mentioned above, the theme uses some custom CSS classes, and these classes are coded in the theme’s style sheet. The problem with this is that now that you have used these patterns, YOU ARE LOCKED IN to this theme. Because the moment you change themes, the new theme will not have these custom classes defined, the patterns will be broken. This is THE SAME reason why shortcodes were outlawed many years ago from inside the themes — and yet when it comes to patterns, this is somehow allowed?
Note: Shortcodes were disallowed in the WordPress theme directory because the actual post content was broken on theme switch. It was unrelated to a broken design.
I already hear what some of you are thinking. This is not the same as “content” lock-in. No, it is not. Not exactly. However, because the block system intertwines content and design, it sort of is. I doubt the average user appreciates the distinction when they end up in scenarios with white text on a white background, as shown in the following screenshots:
Blue background with one theme.
Blue background gone with second theme.
That is a very real scenario. I see it almost daily as I test out different themes.
And, this is just the beginning. As WordPress’s design system grows and themers can configure more pieces, users will become more locked into their existing theme. Or, they may be locked into one developer’s or one shop’s way of doing things.
I do not necessarily see this as a Bad Thing. We have always had these little silos in the WordPress ecosystem, and they have mostly worked out.
In a sense, little has changed.
Users often stick with the same theme companies for one reason or another. And, those same themers tend to build on top of homegrown libraries or frameworks, reusing the same systems — at least the best ones do. This usually means that users can freely switch between themes made by the same people without losing anything.
The old-school purity test of not mixing content and design is gone.
This is a chance for solo developers and shops to strengthen their brand. If this is the system that WordPress is providing, build strong products on top of it. Build naming schemes that allow users to switch between your themes. Create loyal customers who will want to stick with you for years.
If users are essentially locked into one shop’s theme products, that sounds like a lucrative opportunity to build solutions and healthy user communities around individual brands.
I also envision a future where users will need to switch themes far less often. After the site editor and global styles features become available, users will have more direct control over their design. Once they have settled on a solid theme, they may never need to change it as long as it stays relatively up to date.
[The Eksell theme] does such a great job of selling a block editor-driven WordPress. It was a missed opportunity to not pair something of this quality with the block editor when WordPress 5.0 was released.
It’s responsive! I’m amazed this stands out as a highlight for me, but, as the official theme, Twenty Twenty-One breaks in pretty basic ways in multiple places for different screen widths. I think this visual approach is also probably more approachable as “good design” for the average person than Twenty Twenty-One’s attempt at a more typographical approach…
Daniel
In hindsight, it is easy to look back at past default themes and find fault. There is always something better around the corner. However, Daniel makes some good points in his comment on our recent review of the Eksell theme. The theme does sell the idea of blocks to the user far more so than many others.
It would be hard to convince me that launching a great block-ready theme with 5.0 would have been feasible, given that so much about the new block editor was changing at a lightning-quick pace. But, a year or two later? Probably.
Twenty Nineteen, which launched with WordPress 5.0 and its block editor, is the worst-rated (3.5 stars) default theme in history. Twenty Twenty was a decent block-ready outing. It also happened to be forked from Chaplin, a theme built by Eksell’s designer, Anders Norén. While I still believe that Twenty Twenty-One was a refreshing shift and a fun experiment at the time, my fondness for it has waned in the last few months.
None make a convincing case for the block editor. If we are being honest, there are not that many third-party themes in the official directory making it either.
I may have already said it thousand times, so once more will not hurt. Themes are the face of WordPress. They are often a new user’s first introduction to our beloved platform and blogging in general. And, the default themes are the first they see.
The defaults also have another role they need to play today. They need to showcase blocks to all the old-timers among us who have clung to the classic editor and page builders we have used over the years.
It is no doubt a tough job working on a default theme. We have world-class developers and designers putting in the hours to create something that needs to work on millions of websites. However, part of the toughness of the job is in the process.
Each of the last three default themes was announced in September or October of the year before a November – December release. While I am not privy to any private discussions or work that went on beforehand, the bulk of the theme-building and testing process has happened in a small window. WordPress has also forked at least the last two themes from existing projects, presumably because of the time constraints.
In 2021, the community should expect its fourth default theme, Twenty Twenty-Two, in the block era. It is time we begin thinking about what that should be instead of waiting until the 11th hour.
We are in mid-March. WordPress 5.9 is currently scheduled for December 2021, which should coincide with the Twenty Twenty-Two theme launch.
By starting the research phase now, it gives us the head-start we lacked in years past. The development team would also not need to fork an existing theme. Forks are not necessarily bad, but starting early means the team can go down the from-scratch route if preferred. It is an opportunity to rethink the approach to default themes and do more community outreach before laying down the first code.
What are the trending features this year?
Which types of themes are most popular?
What has the community been asking for that we have yet to deliver?
Will this be the first block-based default theme to showcase Full Site Editing?
There are tons of questions we should be asking, and more-seasoned designers are better suited to the task than I am.
Like Daniel said in the comments, we are not asking for Eksell to be ported to default-theme status. However, something with that design-quality level is what the community should expect. Make us believe; make us passionate; make us want to build our sites with it.
High-quality themes meant for public release are not built overnight. Except in the rarest cases, they are not created in a month. Client projects can often move faster because they are typically under controlled settings with fewer edge cases. Publicly-released themes do not have the same benefit because they need to handle everything users will throw at it and work alongside untold numbers of plugins. While all designers and developers have different processes and work at different paces, three months is easily the minimum amount of time to code and test a well-rounded theme for modern sites. Some of the best theme authors I know spend upwards to half a year fine-tuning their creations.
We need research, followed by a decision about what type of theme we are building. We need an outline of the goals it should achieve and its primary audience. Rounds of mockups before the code hits a repository. A real community effort.
Three months ago was the best time to begin planning for Twenty Twenty-Two. The second best time is today.
I really don’t understand this Query block even though it’s been mentioned in several Tavern posts. My eyes seem to gloss over when reading about it – ha!
Is it important that regular WordPress users understand this block, or is it really a block for developers?
I have given the Query block a lot of attention as of late. On occasion, I may have even called it one of the largest hurdles the Gutenberg development team has needed to jump before block-based themes become a reality. However, the “query” WordPress term is not something all users or Tavern readers are familiar with. It is a concept as old as WordPress and generally something that only developers needed to familiarize themselves with. When Full Site Editing lands in WordPress, the new block will expose the Query to far more users as part of the site editor interface.
It is a block that is currently a part of the Gutenberg plugin but not WordPress core. However, at some point in 2021, more and more end-users and developers will be working with it.
In WordPress terminology, we are really talking about two things, the Query and the Loop. The Query is defined by a set of arguments or options that determine what posts to display. The Loop is the part of the machine that “loops” through the queried posts and displays them, one after another. The Query asks for posts; the Loop cycles through them.
Traditionally, theme authors were responsible for adding the Loop code to their templates, which used the global Query that WordPress supplied. Themes could also create custom queries, such as adding a posts list widget, categorized homepage post sections, or anything. And, “posts” can be anything from normal blog posts to WooCommerce products to the latest topics from the bbPress plugin.
The Query may be one of the single most important aspects of WordPress. In essence, it is the engine behind displaying the content of every page on the site. Without it, all WordPress sites would simply be a header and a footer.
The Gutenberg plugin provides two blocks for the Query:
Query: The outer block for setting the options for which posts will show.
Query Loop: The inner block, which is automatically added when using Query.
Currently, users can select between four fairly standard variations when first adding the Query block. They are combinations of the post featured image, title, date, and excerpt.
Query block variations.
These can be further customized via the block options panel in the sidebar. Users can also find “view” options in the toolbar for selecting between List and Grid views. The List view is the traditional list of posts flowing vertically down the page. The Grid view displays posts in two to six columns.
Grid view of posts while using the Query block.
The Query block has a basic set of options for which post types to display and how to order them. It has filters for categories, tags, authors, and keywords. The block is not as robust as what is possible with code yet. It is missing some basic options like a post number limit and nearly all of the more advanced parameters. However, it is a promising starting point.
The more exciting aspects of this feature for end-users may not be the Query block at all. It is customizing the blocks that go inside, which display things like the featured image, post title, and more.
As a former theme author, I cannot count the number of times users have asked me about customizing some aspect of the posts layout. Having them dive into code to make minor changes, such as removing the post author name or displaying the category in a different place, was not an ideal experience. The site editor will put this power directly into each user’s hands.
Adding post-related blocks to the Query block in Grid view.
The comment by Marcus was on the Tavern’s post covering Gutenberg 9.6. The latest version of the plugin introduced global query inheritance for the Query block. This means that theme authors can now replicate the content layer in block-based themes. Previously, pages like archives and search results would simply display the latest posts when a theme used the Query block. Now, each of those pages can display the correct posts.
However, the Query block is so much more than that. In the hands of users, it can be a powerful tool for creating custom output on a homepage — think newspaper-style categorized sections. Users can also create post lists in a sidebar, such as the latest forum replies or products. Theme authors can offer templates or block patterns with unique designs or as starting points for end-users to modify. There is no shortage of possibilities.
These plain canvas-like themes have until now been a choice for those who prefer it (those who like to design their own thing), but this article makes it sound like these types of themes should be the only choice in the future of WP.
This is worrisome to me as a non-designer who looks for themes specifically based on things like attractive button styles.
FSE sounds bad for people like me, who aren’t artistic, can’t coordinate colors, and want themes to do the artistic stuff.
This was the response by a Tavern reader named Isabel on the recent coverage of the Q theme, an experimental project for the upcoming full-site editing (FSE) feature of WordPress. More specifically, she was worried about a thought that Ari Stathopoulos, the theme designer, had made asking that theme authors not get too opinionated with their default styles for things like buttons and so on. His view seemed to lean more toward creating open and customizable themes. However, it is not the only valid opinion on what themes should look like.
This is not much different than what we have experienced over the previous decade or more. Some theme authors build open canvasses for users to customize. Other theme authors build intricately-designed layouts with unique textures, shapes, and forms.
This is not going to change when FSE lands in core WordPress. Themes are merely the expression of the designer’s vision for what a site could look like, and not all theme authors think about design in the same ways.
The Q theme is meant as a starting point or testbed for FSE. There will be many open-canvas themes. These types of themes are already wildly popular, particularly when used in conjunction with a page builder. Astra has over a million installs. Hello Elementor has surpassed 400,000. GeneratePress has over 300,000. There is big money in this segment of the theme market. FSE will undoubtedly help to increase the competition.
However, that is not all that themers are giving us. The recently-released PhotoFocus theme by Catch Themes is on the upward trend, inching its way into the popular themes list on WordPress.org. And, there are hundreds of other options that go beyond the plain ol’ open, black-text-on-white-background themes built for customization by the end-user.
I simply do not see the current trends shifting too much. Yes, those trends already lean heavily toward open-canvas themes. FSE will allow developers to build those types of themes for core WordPress instead of page builders much more easily.
However, this is also an opportunity for those who want to experiment with more artistry to do so.
Stathopoulos did say:
It’s tempting to add extremely opinionated styles, for buttons for example, but more and more things get added every day to the editor like a border-radius setting for buttons.
But, we must put that into the context of his followup remarks:
Theme authors should avoid the trap of designing an FSE theme having in mind what the editor currently does. Instead, theme authors should strive to build something having in mind a vision of what the editor will eventually become.
He is not saying that every theme needs to be plain and boring. He is not saying that theme authors should be reluctant to put a unique spin on the Button block, for example. He is saying that theme authors need to evaluate how they approach design based on what block options are available for end-users.
Buttons are a good example of this. With the border-radius option that allows end-users to control rounded corners for buttons, he means that theme authors should not overwrite border-radius styles in their CSS. Users should have the option to control it if they want. He is also talking about using the eventual Global Styles system to set up defaults. If theme authors want rounded buttons by default, they should use the system that WordPress provides rather than writing the CSS. He wants theme authors to be aware of the current block options and styles while preparing for new options in the future.
This upcoming era of theming changes how theme authors work with the system. It does not mean they cannot branch out in terms of design.
Here’s where the block editor project makes things more interesting for those users who want things like “attractive button styles” but lack some of the artistic skills expected from the theme’s designer. The block system is set up for unlimited variations on what themes can provide to end-users.
Sticking with the Button block example, users can already see two block styles named Fill and Outline in WordPress as shown in the following screenshot.
Using the Outline block style.
Theme authors can add all sorts of style variations today, and some have already done so. Block styles offer a lot of variety, and WordPress allows users to further customize these if they wish to do so.
WordPress also offers two different block patterns that utilize the Buttons block. They are basic two and three-button layouts. However, theme authors can use the Patterns API to create any number of layout options using buttons.
Inserting the “two buttons” block pattern into the editor.
Stathopoulos’s comments on not being too opinionated should also be taken in the context of the upcoming Global Styles system, which is currently being tested in the Gutenberg plugin. This system allows theme authors to set up global, default options for everything. They can also drill down and set up default options for individual blocks. For example, a theme author can set a default background gradient, rounded corners, and any other options available for the Button block. These default options can span the width of the spectrum, from a simple and understated square button to a rounded button with a vibrant gradient background and a drop-shadow. The more block options that WordPress’s editor offers in the future, the more flexible theme authors can be with their designs.
Experimental, per-block global styles in the site editor (feature not finished).
Isabel’s concern is valid. It is tough to keep up with all the changes happening and those that are on the feature list of the future. The Gutenberg project moves fast, and when we write about features or experimental themes, it is easy to overlook some of those questions that the average user might have.
To put some users’ minds at ease, future WordPress themes will undoubtedly offer a breadth of artistic designs that are suitable for all sorts of websites. Designers and non-designers alike should look forward to the months and years ahead.
On May 4, the StudioPress development team made a small but significant user-facing change to its Atomic Blocks plugin (now rebranded to Genesis Blocks). It removed the “AB” branding from its block titles. This minor update changed block titles such as AB Accordion and AB Button to Accordion and Button, respectively. On the surface, this change probably seemed of little consequence to the developers on the project. However, for at least one user, it created a massive workload.
Unless users religiously followed the GitHub code commits, they would have missed this update. Stacked with several other code changes for a seemingly unrelated ticket, the team left a message that read, “Remove unnecessary ‘AB’ from block titles.”
The change made it into version 2.8.2 of the plugin, which launched a day later.
The problem was that there was no message in the change log that noted this. Users had no indication that the blocks from the plugin were being renamed. Typically, this would not be a big deal since the plugin team had merely dropped the “AB” prefix from the otherwise unchanged titles. However, what happens when one of those blocks’ titles matches a core block title?
That was the issue that Marcus Tibesar ran into. The AB Button block suddenly became the Button block. Thinking he was using the core WordPress Button, he made liberal use of it throughout his site. Throw in his decision to drop the plugin after StudioPress rebranded its plugin to Genesis Blocks, it became a bit of a disaster to clean up.
“I have been using the Button block for months now only to discover that I’m actually using the Atomic Blocks button block!” wrote Tibesar in a comment on the Atomic Blocks rebranding post.
Theoretically, he should have needed to update only any lingering blocks from Atomic Blocks that he had knowingly used. But, he was stuck with blocks that he had unknowingly added to his posts and pages through no fault of his own.
This particular scenario was made worse because WordPress 5.4, released on March 31, introduced a new Buttons (plural) block. The old single Button block was removed from the normal inserter. While not all block-naming issues are so convoluted, it still begs the question: how can plugin authors avoid causing these types of user-experience issues?
It is easy to throw blame toward StudioPress — and the team could perhaps use a scolding for not being clear about the change when it happened. However, this brings forth a couple of things the greater WordPress community needs to figure out. The first is whether plugin authors need to use a consistent, prefixed naming scheme for their blocks. The second is what can WordPress do to help mitigate issues.
Prefix All the Things
Buttons, buttons, and more buttons.
That is the common saying in the WordPress development world, right? Prefixing and namespacing guidelines generally apply to the actual code, which is where conflicts arise. However, there are times when prefixing public-facing text is warranted.
And those times are when plugins utilize a shared space.
The block editor is one such shared space. With more and more block plugins landing in the directory, it is time that plugin authors consider how block-naming schemes affect end-users. The issue is certainly not limited to Atomic/Genesis Blocks. This has been an ongoing trend with several block library plugins. Some do better than others, but it’s a toss-up each time a user installs such a plugin.
The easiest route is for plugin authors to simply prefix all custom blocks with their company branding (e.g., AB Button). On the other hand, not every block shares a title with one of the core blocks. For example, a block titled Product Carousel may not need to distinguish itself further from other blocks. It is unlikely that end-users are running multiple eCommerce plugins with blocks that share the same title.
“All, repeat all, should have a prefix,” said Tibesar. “The prefixes eliminate any confusion as to whether we users are selecting a core block or a third-party block. The most popular plugins appear at the top of the list, and it’s confusing from whence they came when prefixes are absent.”
At the very least, third-party blocks should have a prefix if their titles match one of the core blocks. End-users should not see two different Cover blocks in the block inserter, for example. Instead, they should see the core Cover and a second, uniquely-titled block. Prefixing is an easy way to do that. But, I could live with anything that does not cause user confusion.
Locating Instances of Block Usage
Manage Blocks screen.
In late 2019, the Gutenberg team released the first prototype of a potential block management area for the WordPress admin. The Manage Blocks screen from the prototype showcased an area that would allow users to manage every block on their site. One of the more important bits of information on this screen was an “Instances” count, which displayed the number of times a block was in use. It further linked to a screen with every post that had a particular block.
One of the reasons this feature is important is that it would allow end-users to locate posts that they may want to clean up. Using the Atomic/Genesis Button block as an example, Tibesar could track down all those old uses and make any changes he wanted.
He said he would absolutely welcome this feature in WordPress. “New users are tempted to load up on zillions of block plugins all to be forgotten later. Also, maintainers would use this tool when cleaning up broken sites. Just being able to see an overview of what blocks were used where, will allow publishers to dial back the number of block plugins installed on their sites, especially when new plugins and technologies emerge.”
Because this feature is not in core yet, he had to turn to the Find My Blocks plugin, which helped him identify 22 posts and pages where he had unknowingly used the Button block from Atomic/Genesis Blocks. In the long term, this is something that needs to be handled directly in WordPress. It is unlikely to be the last time a user needs to clean house and get rid of old blocks.
“Do you ever read the subtitles on a video so you didn’t need to unmute it?” asked William Patton, a representative from the WordPress Themes Team. “Used the ‘beep’ from a crosswalk to know when to cross the road? Found yourself reading the info panel at an airport? Those things are considered features, but in reality, they are aids for people with additional needs.”
As I talked with Patton and other reps from the Themes Team, it was clear they believed accessibility was a vital piece of the theme-building puzzle. The team has made small moves in the last year to bring more themes up to standards. However, it has been a slow-going process.
Last July, the team initiated a plan to add a new guideline every two months or so that would address a single accessibility issue. It would become every theme author’s responsibility to make sure they were meeting the new guidelines. It would be every reviewer’s responsibility to understand how to test guidelines as they were implemented. Thus far, the team has required only that themes have a working skip-to-content link and keyboard-capable navigation menus.
Not every theme author was excited about the move. Some have still shown resistance a year later.
Last week, we covered the Astra theme’s news of hitting 1 million active installs. A commenter made a point that the data shows that end-users do not care about accessibility — the Astra theme makes no mention of being accessibility-ready. The conclusion was that the Themes Team should not be implementing such guidelines based on the success of one of the directory’s most popular themes.
While there are several things we could do to pick apart the original comment and the limited view of the situation, we can instead use it as a catalyst to discuss why accessibility is something that should be at the forefront of every theme author’s mind. Patton, along with Themes Team representatives Carolina Nymark and Denis Žoljom, had a lot to say on the subject.
The overarching theme was that awareness is vital and that theme developers play a crucial role in making the web more accessible.
Awareness Is Key
Žoljom likened the awareness of accessibility to that of a cisgender person looking at the world from the perspective of a transgender person. Once he became aware of larger issues, he made sure to address gender-specific pronouns in his code comments, such as replacing instances of “he” with “they.” He hopes such small changes spark similar changes from others.
He said the situation was the same with accessibility. “It might not mean much to a person who doesn’t have any disabilities, but putting yourself in somebody else’s shoes changes one’s perspective. This is why we started to include things like skip links, keyboard nav, etc.”
The team does not hope theme authors will merely become technically proficient at addressing accessibility issues in their themes. While that would be a help from a review standpoint, it addresses only the symptoms rather than root causes of the issues. Instead, by making more developers aware, they will begin to look at development from multiple perspectives. They will ask how a screen-readers will handle their theme. They will ask whether their colors have enough contrast for low-vision users to read. They will wonder if non-mouse users can navigate their users’ sites.
The technical stuff is the easy part. Changing perspectives and becoming more empathetic toward those who are different is much more difficult. But not impossible.
“A lot of us who build for the web are lacking some basic insights into what it is like to have additional needs beyond what is our own normal,” said Patton. “There is a saying: ‘if you could see it through my eyes, you would see it differently.’ If you could see through the eyes of someone with color blindness or impaired vision, you quite literally would see things differently.”
The trouble with humans, in general, is that it can sometimes be hard to see things through someone else’s eyes. Of course, there are tools to simulate accessibility issues for developers, so that helps. However, these tools do not replicate what it is like to walk through life with a particular impairment or disability. Some of us can only partially glimpse the difficulties that others may have when navigating the web. This does not mean that we cannot address the downfalls of the software we build and become more inclusive to all people, especially if we are proactive when issues are raised.
Nymark identified a few areas where the community can improve awareness:
Make sure that all contributors are aware of the WordPress accessibility requirements so that all new features are accessible.
Highlight accessibility improvements when WordPress is updated.
Feature more diverse use cases and highlight areas where the accessibility that is built into WordPress has helped people share and access important content.
“The themes team hopes that by making theme authors aware of accessibility issues, authors will learn that even small changes to their code and design can have a great positive impact,” she said.
Is Accessibility Important to End-Users?
Certainly, accessibility is important for some users. It certainly mattered to Guillermo Robles, a blind man who sued pizza chain Domino’s in 2016 for an inaccessible website. The court case was important enough that it moved through the system all the way to the U.S. Supreme Court. Ultimately, the higher court denied Domino’s appeal of an earlier ruling. The U.S. 9th Circuit court had previously ruled that business websites fall under Title III of the American with Disabilities Act (ADA) and must meet accessibility standards.
This was a landmark case in the U.S. for accessibility advocates last October. It is also worth remembering as we near the upcoming 30th anniversary of the ADA on July 26.
Domino’s is a billion-dollar business. The company has enough money to fight such battles for years. They also have the money to hire world-class web developers to correct any accessibility issues.
However, for small business owners, hiring a single developer, much less an entire agency or team, is often a non-starter. Many small businesses are fortunate to break even. WordPress and its ecosystem of free or low-cost solutions have democratized eCommerce on a scale previously unwitnessed. It means that mom-and-pop stores can have an online presence. It means teens can begin selling their custom art and a multitude of others can make money online without the backing of wads of cash.
For these small business owners, many are unaware of accessibility concerns. They pick up a few plugins and find a theme that suitably matches their branding. The possibility of an impending accessibility-related lawsuit is the furthest thing from their mind. This is a major reason that WordPress needs to be a leader in meeting accessibility standards. Themes, which are the part of the site that visitors will interact with, are possibly the most important part of that equation.
Some would argue that small business owners should understand the laws of their jurisdiction. That is true. However, it is also partly the responsibility of the software creators, says the Theme Team representatives.
“Yes, the technology should account for additional needs,” said Patton. “Yes, the tooling should enable people to make good choices with regards to this. Yes, it should be easy to meet a minimum level of accessibility in the things we create with ease. Yes, it should be a fair assumption that the choices available to pick from are accessible.”
The web is inherently accessible out of the box. Raw HTML is read and output by web browsers in such a way that the content can be accessed by anyone. Patton says that it is the things that developers do from that point forward that makes that experience better or worse.
“Trade-offs are made that are well-intentioned but not always helpful,” he said. “Design trade-offs are the easiest to point out. Taking text and embedding it into an image means that some of its value is lost in exchange for it looking pretty. Using closely matching colors for text and background might create an interesting effect to some people but for others, it makes it impossible to read. Sometimes it’s about balancing those trade-offs with the needs of others, but it is those kinds of trade-offs that most people struggle to give up.”
Nymark described some more technical issues that the average end-user should expect to simply be a non-issue. For example, it is reasonable to assume that a theme installed from the official WordPress directory would be free from HTML, PHP, and JavaScript errors. These are items that users should not have to worry about checking before activating the theme on their site. The errors should simply not exist.
It is that level of quality control that end-users should expect in terms of accessibility, an assurance that the theme does all the things it is supposed to do. It is not about whether end-users “care” about accessibility.
“If a form on a shop checkout page is not working, this can lead to loss of income,” she said. “Users rely on the technical solution provided by plugins and themes and expect everyone to be able to use their shop. Whether or not the site owner recognizes this as an accessibility issue is irrelevant because their page just needs to work.”
Why Theme Authors Should Care
“If those who choose themes don’t consider accessibility and the theme author did not consider it, then the [visitors] of the sites built with those themes are the ones that lose out,” said Patton. “It’s not a huge leap to realize that low accessibility on your site directly equates to a reduction of potential users.”
He said that end-users would naturally assume the themes they are picking from do not have accessibility issues. However, that assumption is typically far from accurate.
“Theme authors should care about the accessibility of their creations so that the people picking their themes don’t need to use it as a deciding factor,” he said.
My go-to response is that developers should concern themselves with accessibility because it is for the collective good. Humans should care about making sure that all other humans have the same freedoms that they enjoy, which are often take for granted.
Even those who cannot view it from that perspective should be able to appreciate that it is a smart business decision. It makes little sense to leave money on the table, especially if you are a developer who is selling a theme or upselling additional features on top of a free theme. There is an entire segment of users that represents money lost.
Additionally, more and more countries are implementing laws around web accessibility. Over time, such laws will be commonplace, particularly in the business sector. Inaccessible themes will lose users as such laws are enforced. Now is a good time to get ahead of impending change.
More Guidelines Ahead
The WordPress Themes Team has been slow about adopting additional guidelines surrounding accessibility. However, more are expected to land at some point. Team reps want to work with authors and reviewers alike to make the transition as painless as possible.
“We have not added anything else because theme authors are still not releasing themes with working implementations of skip links and usable keyboard navigation,” said Patton. “When those two things become habitual, it will be time to introduce another aspect as a requirement.”
The next guideline in line is expected to be underlined links in the post content. This would be an easy win if the team can get past the current stage. Right now, the team reps are unsure when that will happen.
“The fact that this has taken so long for authors to get this right probably indicates that we need to do better at guiding them to resources to learn how to do it and why it is important,” said Patton. “Perhaps that is a better avenue to pursue than looking to implement additional asks of them.”
I wish we lived in a world in which we could discuss code each day, not allowing political opinions to seep into the discourse. We could talk about the next exciting project around the corner. We could chat about a small startup getting its first big break or new investments into WordPress companies.
However, I also wish we lived in a world where a developer did not have to create a plugin in support of black Americans who have lost their lives to those charged with protecting us.
Each of these stories may not be important to you as an individual reader. However, they are important to some of our readers. We are a community made up of vastly different opinions, and we must represent this wide array of views as they relate to WordPress.
Sometimes, we will publish stories that do not jive with your personal viewpoint. Sometimes, you will tell us to not post anything political. The answer to that is that we cannot simply separate the code from the politics. As much as many of us would like to, that is not the world we live in today.
WordPress itself is inherently political. From its license to its mission statement, WordPress takes some political stances.
The platform is founded on the bedrock of free software, an idea that is as much political as anything else. It is an idea that has shaped the foundation of the web. The concept that users have the freedom to run, copy, alter, improve, or even distribute software is a political statement. It is a political statement in direct defiance of major corporations and governments controlling software through proprietary licenses.
Politics play a part in how we shape our community. We do not have to agree on all things, and different things brought us together. However, there are some foundational elements that we all must agree on to some extent.
It is a generally accepted principle that all people are born with the inalienable right to free expression. I wager that the majority of our community would agree with this statement. Given that the software we all use is built upon that idea, I would hope so. The idea of democratizing publishing is not just about providing a tool to people who can already freely express themselves. It is also about reaching to the dark corners of the globe and being a beacon of light to those who do not share in our freedom. It is about exposing the horrors of dictators. About newsrooms publishing the wrongdoings of politicians. Citizen bloggers fighting for the oppressed.
No, do not tell me that WordPress is not political.
What you really want to say is to not post political views that you disagree with. You really want us to not share plugins or projects that make you uncomfortable.
While the code itself may not hold political views, the people who use the code do. Politics is woven into the fabric of our lives. It is woven into the licenses of the software we use, the communities we choose to join, and the web we dare to create.
When you tell us to stay away from politics here at the Tavern, the only reasonable answer to provide is that it would be impossible to do so.
We will continue writing about the next companies to receive VC funding, blocked-based WordPress themes, plugins that push the envelope, and every other project that makes WordPress fun. However, at times, we must open the floor to tough discussions. We must be a source for sharing projects in our community that have their own political slant, regardless of whether we agree.
When the day comes that The Show Must Be Paused plugin, the Women in Tech Salary Transparency Project, and a multitude of other important projects no longer need to exist — on that day — we can celebrate. We can discuss code, WordPress, and kittens without politics getting in the way.
Imagine a future where you log into your website’s admin. You head over to the editor. This particular editor has all the tools and features in place that make you more efficient at producing whatever content you put out for the world to see. You immediately start tapping keys or dragging your mouse around the screen, satisfied with what the software you’re using has to offer.
Today, that editor may be the default block editor for WordPress. Some may be running the Classic Editor plugin for a familiar writing experience. Others will be crafting beautiful layouts with the Elementor page builder.
As of this week, people are finding themselves at home with Iceberg, an interface built on top of the block editor for folks who prefer a minimalist environment and love Markdown.
Some bloggers post by email. Others use apps from their phone. And, an entire class of people works in third-party, offline editors such as Microsoft Word, Atom, and plain ol’ Notepad.
If there is one thing I have come to realize over the years it is that editing environments are as varied as the people who use them. There is no one-size-fits-all solution. The experience I am looking for is not necessarily the same experience you need.
Given the freedom to choose, most people would rearrange their desk, use a different notepad, and opt for a different writing utensil than their neighbor. Even if starting with the same tools, we eventually make tweaks to accommodate our personal tastes.
Throughout most of its history, WordPress has had a single editor that its users shared. It has changed over time — even the addition of TinyMCE was once controversial. However, the default editor has never been sufficient for every user. Personally, I abhorred the classic editing experience. It led me to write in various Markdown editors over the years for efficiency and a true distraction-free experience. It has also led to developers taking on the challenge of creating alternative experiences for large swaths of end-users.
As much as many people love the classic WordPress editor, it was a pain for many others. Otherwise, all of the tools that have cropped up over the years would have been unnecessary.
In much the same way, the block editor is often a love-it-or-hate-it experience. It is the ideal editing environment for many users. For others, it is a roadblock at best. At worst, it is worthy of a gasoline soaking and a book of matches.
The promise of WordPress is to provide an editing experience that allows people from all walks of life to publish their content on the web. The promise is to make that experience as pain-free as possible and to continue iterating toward that unattainable-but-worthwhile-goal of perfecting the publishing process.
WordPress — any publishing platform for that matter — is only as good as its editor.
It is a predicament. There is no way to make the ideal editor for all people.
What’s the next move?
An Editors Registry and API
In the comments of the Tavern’s Iceberg editor coverage, Phil Johnston proposed a solution for WordPress going forward. “With all of the amazing publishing experiences coming out, I wonder if it’s time for WP to include the concept of ‘Editors,'”, he wrote. “Like an official registry of installed Editors.”
He later created a feature request that called for an API that would make it easier for plugin authors to create new editing experiences on top of WordPress. The proposal is a high-level idea about how the editing screen could allow users to choose their preferred editor.
Potentially, users could install and use various editors, depending on what type of content they are building. A user may want something akin to a Markdown editor for blog posts but switch over to a page builder for their site’s pages. eCommerce plugins might have custom editing interfaces that are ideal for shop owners. Ultimately, the possibilities are endless. But, it all starts down at the WordPress level.
The idea is not about dropping the default WordPress editor. It is about creating a flexible framework for plugin developers to cater to more users’ needs. Additional methods of editing content would make WordPress a stronger CMS, drawing in users who would otherwise prefer a different experience, regardless of the type of site they are building.
It is possible to do this now. However, what could WordPress be doing to improve this process for developers?
Jeffrey Carandang, co-creator of Iceberg, believes that core could open the editing space to more third-party solutions. “Creating our own editor mode was challenging but a super exciting experience overall,” he said. “Gutenberg is still far from being extensible compared to other parts of WordPress, but we managed to hack on some areas that needed to work.”
Carandang identified a few hurdles his team had to overcome when building the Iceberg editor:
Limited hooks and filters outside of block development, such as the top and bottom areas of the editor and wrappers.
Little-to-no options to remove editor components, relying on CSS hacks to hide them.
The core editor’s reliance on localStorage.
In addition to the primary issues, his team had to develop against multiple versions of the block editor to ensure a seamless experience for users. Despite the issues, he still believes in a future where the block editor project can open up “potential innovations” in the space.
Today, I am composing this post in an offline Markdown editor. I will copy and paste my second or third draft into the block editor, which does a great job of converting Markdown into blocks, before final edits. On other days, I work directly in WordPress, depending on my mood. However, my preferred writing experience is as simple as it gets and often happens in Atom. It is what I am accustomed to.
I wonder if there will one day be an editor that will convert me to writing full time from within WordPress. I eagerly await the plugin developers who will make the attempt. My hope is that WordPress cultivates these ideas without standing in the way.
As Elementor, the most-used WordPress page builder, celebrated its first round of funding at $15 million, some of our readers questioned whether this was a sound investment. With movement in the Gutenberg plugin toward a full-site editing solution, which will eventually make its way into core WordPress, it is a valid concern. Will page builders remain competitive once WordPress begins taking over this role, likely sometime in 2021?
While Elementor has seemingly pulled far ahead of the competition with over 4 million installations, there is a much wider market of page-building solutions that end-users are installing. The free version of Beaver Builder has over 400,000 installs and Visual Composer has over 70,000. In the commercial space, Divi has over 600,000 customers and WP Bakery has seen 388,000 sales. These numbers don’t include the numerous other page-building plugins and custom solutions that developers build with libraries like Advanced Custom Fields and Meta Box. Some themes also offer some form of a page builder but typically not as robust as plugins.
All of this is to say that there is a huge market right now. Based on current trends, growth for page builders is accelerating rather than slowing down. My educated guess is that we are nowhere near the ceiling.
From the comments on our recent coverage of Elementor’s investment round, one of our readers named Anto had a few thoughts on the future. “I’m happy that WordPress is getting more external investment, but I find it hard to imagine how Elementor has a long-term future in WordPress with their thinking,” he said. “Sure, it has a place now, and will for at least a few more years, but as Gutenberg matures why would anyone want the added bloat? Once you abstract the window dressing, all page builders (including Gutenberg) are fairly similar. The remaining differences are a matter of workflow and taste because moving blocks/sections around isn’t unique.”
Yoni Luksenberg, CEO and co-founder of Elementor believes the future is bright. “We believe in democratizing the editor so different WordPress users and different personas will have their editor of choice,” he said in an interview. “This way, they can pick the editor that best fits their unique needs and preferences. This is the beauty of open source. There are endless ways to build a contact form: Contact Form 7, Gravity Forms, Jetpack Forms. Similarly, there are endless ways to build and design a web page. The users should have the option to choose their preferred method.”
Anto believes the choice between contact forms is not comparable to the choice between editors or builders. Because the block editor is a part of the core platform, it would provide stiffer competition for a builder plugin. “Will people have different preferences that the ecosystem will fill?” he asked. “Of course, these will be the block plugins, style/feature plugins, and additional layers of complexity that will evolve as Gutenberg matures, but they will all be built on core WordPress (Gutenberg) because doing anything else is just duplicative bloat.”
It is not clear what users will do in a year or two down the road. However, there is a significant portion of end-users who are not currently satisfied with what WordPress is offering. WordPress fell behind the market and plugin developers filled the void with solutions to meet demand. It is now playing catch-up with these page builders. Even with all the resources being thrown toward the block system and eventual full-site editing, we are miles away from a baseline working solution beyond content editing.
“At some point of time Gutenberg is going to be at least as powerful as the free version of the Elementor plugin,” said Richard Ginn in the comments. “Gutenberg to me is getting more powerful at a faster rate than Elementor is.”
One thing page builders have going for them is their current user base. It is human nature to stick with tools that are familiar and comfortable. I do not imagine most page builders will lose large user numbers as long as they are offering the solutions that users want or need. Even if WordPress offers a more robust solution within the next couple of years, user trust will be with existing plugins, and that is a hard thing to win back once it has been lost.
With its recent funding round, Elementor is planning on growing its team and speeding up feature development. Other page builders will need to keep up and continue finding ways to remain competitive. Right now, page builder usage numbers are on the rise in the early block editor era. We could see a lot more innovation in this space in the next couple of years. Elementor’s investment round validates a maturing market that is a direct competitor to core’s block system.
This level of competition is healthy for the ecosystem. The rise of page builders will undoubtedly push Gutenberg and WordPress development to new heights. There is a multi-million dollar market for third-party builders that is hard to ignore. I don’t see it going anywhere anytime soon.
This post is part of a new From the Comments series where we highlight interesting points of discussion from comments on WP Tavern articles. The hope is to give these comments, which can sometimes get lost, the attention they deserve.
WordPress.org is not an official marketplace for plugins and themes. Except for some plugins that are strictly SaaS products, all extensions to the platform are publicly available for the low cost of $0.
Despite not directly selling through WordPress.org, the plugin directory is a huge source of income for many individual developers and companies via product and service upsells. Plugins are big business. Besides a bounty of third-party marketplaces and individual shops, commercial interests often flow directly in and out of the official WordPress site. For many developers, it essentially serves as a marketplace.
In December, we dove into an early proposal of the WordPress block directory. The new directory should land within the WordPress software itself in version 5.5 and will house a new type of plugin. The idea behind the block directory is that it will allow plugin developers to create and share one-off blocks that users can install on their websites.
This is the future of WordPress.
Love it or hate it, there will come a time when end-users are primarily looking to install individual blocks to solve their problems. This is not to say that other types of plugins won’t exist or have their place. They will continue to be a major part of the platform. However, blocks will be a big deal once users can install them at the click of a button via the WordPress admin.
The question is whether blocks can also be big business.
Tavern reader Matt Gowdy believes the guidelines for the block directory could be an issue. “There’s a lot to like here,” he said. “Though I’m still troubled by the directory submission rules that are fairly stringently not allowing for any sort of promotional link or defined up-sell of any kind so as not to ‘disrupt the flow.'”
Block Plugins are blocks. They must not include advertisements, prompts, or promotional messages.
On the one hand, it makes sense, particularly for something that is not yet built and will eventually serve as a version 1.0. If every block a user installs begins advertising, it could be a recipe for disaster without some type of standard.
On the other hand, would the idea of not having an upselling route turn WordPress businesses away? While many developers would be willing to submit blocks, is this sustainable? Many of the most popular plugins are backed by businesses. The more popular any particular piece of software becomes, the more likely it is that the software will need funding to cover maintenance, feature updates, and support.
“More often than not these days, people don’t have as much free time to invest in coding just for the fun of it,” said Gowdy. “I speak mainly of myself, but I have the notion that while WordPress is still grounded pretty firmly in Open Source (not a bad thing), it’s been the open markets that have allowed it to grow as much as it has. I don’t think it’s wrong to allow people the opportunity (within reason) to make something back off their hard work should they choose. Donations are non-viable in my experience as the vast majority of humanity are way cheaper than they would like to admit.”
Currently, the upcoming directory has a limited number of blocks available. The WordPress Meta and Plugin teams should expect more. However, it is unclear whether the guideline will slow its growth.
“Without any sort of up-sell channel (rule-defined or element defined in blocks), we aren’t going to see the plethora that we are hoping for, nor in some cases the quality that could be brought in by people working professionally on a block plugin,” said Gowdy. “The time to define these up-sell and link options is right now.”
Gowdy is not alone in his concerns. Several others expressed similar opinions in the comments on the block directory announcement post.
“Where WordPress started and where it is now are two separate points in time,” said Gowdy. “I hope the Open Source community and the marketplaces can find a way to co-exist here in order to really rev up the platform for the future.”
This post is part of a new From the Comments series where we highlight interesting points of discussion from comments on WP Tavern articles. The hope is to give these comments, which can sometimes get lost, the attention they deserve.
