Upsells, Barriers, and the End/Beginning of the Quality $free Themes Era

The WordPress.org theme directory is becoming little more than a crippleware distributor. I suppose it was inevitable given its reach, which can be worth $1,000s/month for theme authors.

Justin Tadlock via Twitter

As I think back on that tweet from 2019, I realize how unfair it was to refer to the themes coming into the directory as “crippleware.” At the time, I was a part of the Themes Team (formerly the Theme Review Team). However, there were real cases of crippleware submitted to the directory when I wrote that.

To define crippleware: some themes blocked core WordPress features and made them available via the “pro” versions. It was one of the more blatant abuses of the free themes directory I had seen for a profit.

However, the term does not represent the majority of themes submitted. Most of what we see today are “lite” themes. Some of them are well-designed themes that provide value to end-users at no cost. Others are stripped-down versions of what you would typically see from a starter theme. While they are fully functional — the Themes Team’s rules have been strict on this requirement — the real value of the theme is in the upsell.

This is not the start of an anti-commercial theme rant. When WordPress developers and agencies are successful, it benefits the whole ecosystem. But, how do we balance that with providing value — which is subjective, I know — to the free theme directory? How do we transition the theme directory to something flowing with more artistic or even experimental ideas?

Guidelines and Stumbling Blocks

Matt Mullenweg, WordPress co-founder and project lead, posted the following on the Post Status Slack two weeks ago:

The .org theme directory is particularly bad when you compare it to any half-decent commercial theme marketing page, or the designs available on other site building services or Themeforest directories. The .org theme directory rules and update mechanism have driven out creative contributions, it’s largely crowded out by upsell motived contributions.

There is a lot to unpack in his statement. I agree with most of it. The Themes Team agrees with at least some of it. However, its members lack direct control over the system outside of the guidelines.

“I actually agree with this in a sense,” said Themes Team rep William Patton. “Creativity has not prospered in the directory, and I think a large part of it is the barrier of entry. ‘Don’t do bad things’ is the overarching guideline for the theme directory, but that can be viewed very subjectively. If it were the only guideline we would see a lot of things that might not be best suited here. If we want to encourage creativity then more freedom to express it would likely be a good way to start bringing it back. However, it can be hard to know where the line should be placed.”

The team sometimes gets pulled in two different directions. When the project lead asks for things to be more open, many members rally around that idea. On the other hand, the call for stricter accessibility requirements, for example, are popular with others in the community. It is a choice between two ends of the spectrum that are tough to pull together as the gatekeepers to the official directory.

“Why couldn’t it be more like the plugin directory?” asked Mullenweg. “That has all the same potential issues and has been working pretty well. I’d like it to work just like the plugin directory, with direct access for authors, and most reviews being post-review vs. pre-review.”

The Themes Team is not against the idea. More than anything, they just need the help to make any significant change.

“Having the themes directory work like the plugins directory would be great!” said Themes Team rep Ari Stathopoulos. “And, in fact, it’s something we’ve all been asking for years, but there are many technical challenges because they are built fundamentally differently. Plugin authors have access to their plugin’s SVN while themes don’t. Theme reviews are public while plugin reviews are private and closed. There would need to be lots of changes in systems and meta. Not to mention that, as far as I know, plugins don’t do post-reviews, they do pre-reviews the first time a plugin is uploaded and post-reviews for updates (which is exactly what happens in themes too).”

The team has created tickets, asked for help, and have generally awaited a champion to push innovative ideas — or any ideas — forward. Seven-year-old ticket to support the standard readme files available to plugins? No takers as of yet. Allowing block-based themes to be uploaded? Maybe we can make that happen sometime soon.

The guidelines are likely less crippling than the outdated Trac review system, uploading ZIP files for updates (which Mullenweg mentioned), the limitation of a style.css header for the theme description, and the lackluster theme previewer.

WordPress.org theme review Trac system.
Theme review system on Trac.

For the most part, nearly every guideline has been put in place in hindsight. The team finds consistent abuse or issues and course-corrects.

“I don’t think that Matt’s idea of a creative theme is a theme that is not secure or not compatible with GPL,” said team repo Carolina Nymark. “Creativity is not limited by being asked to sanitize options. It is not limited by making sure that your theme can be translated. If the reviewers saw creative, beautiful themes that lacked in some other aspect like basic accessibility, then the team could help explain to the theme author what kind of changes are necessary. But that is not the kind of themes that are being submitted.”

Financial Incentive

In the mid-2000s, the average theme developer could get away with building an entire theme on a lazy weekend afternoon. WordPress was far less complicated. Theme development was not a race to the bottom, bundling every feature imaginable.

Today, we live in the era of the multi-purpose theme. To soar to the top of the popular list, most themes need to handle everything from being the online face of a pizza restaurant to masonry grids for artist portfolios. They also either need good luck, name recognition, or good marketing. That is the reality for the average theme developers trying to make a name for themselves.

It makes for boring themes in a free theme directory. If the theme author has any financial motivation behind creating a WordPress theme, they need to bundle the nicer features into a paid package.

As Eric Karkovack wrote in his piece for Speckyboy, Are High-Quality Free WordPress Themes a Thing of the Past?, “Money changed the equation.”

There is not much incentive to push a free theme out to the directory just for fun. Most themers are spending a month or more of their time in today’s ecosystem to build a theme. The days of the weekend-afternoon project seem all but gone.

Even releasing a theme to give back can often be a letdown. There is little chance of any name recognition as the developer’s creation is swamped by the hordes of lite themes in control of the directory. There is no way for unknown players to get any exposure through the directory except in the brief moments their theme lands in the latest themes list. It is that one make-or-break moment that could potentially help best the algorithm and slip into the nearly unattainable popular list.

In comparison to Themeforest, the WordPress.org directory is lacking. Themeforest is inviting to users because it provides the backend tools for theme authors to market their themes. They can load up custom demos, provide screenshots, use a modern categorization system, and provide all sorts of extra data to end-users. They’re in the business of selling a product to users.

Screenshot of the Themeforest WordPress themes page.
WordPress themes on ThemeForest

While WordPress.org may be free, it should still be selling the promise of a beautiful website to its users. I have always said it, the themes available on WordPress.org are the face of WordPress.

Users deserve better. Theme authors deserve better tools to make it happen.

Even with better tools and a better-designed directory in place, there is no guarantee of an uptick of creative contributions or a better overall balance that keeps pure upsells in check.

“I think that due to the reach a theme or plugin that becomes popular quickly commands, monetization is a necessity to be able to properly ‘support’ such an endeavor,” said Joost de Valk, CEO of Yoast, in response to Mullenweg’s statement on Post Stats. “I think the community also ‘demands’ a certain stability and a certain level of support that is simply unfeasible to expect from any non paid contributor. Because WordPress.org has no way of doing that monetization ‘on platform,’ this is what you end up with.”

He also argued that something akin to an app store would make things like the “balkanization from non-G-based site builders” less attractive to theme authors. Such a store has little or no chance of becoming a reality.

“I think we first need to agree on what the theme directory should be,” he said. “We need a ‘mission statement,’ of sorts. And I think we probably need less control than we currently have, be much more like the plugin directory. But if we have a vision of what it should be, then we could work towards that.”

There is an opportunity to turn things around. Full Site Editing will leave ample room for releasing creative, fully-featured themes with upsells. There is plenty of reason to be excited about pattern design and template packs, better value-adds for theme authors who want to upsell. The problem is going to be getting authors to abandon traditional themes and explore new terrain.

Changes Are Coming, Maybe, Hopefully

Popular themes list on WordPress.org.
Popular listing on the WordPress theme directory.

For some, this is a song and dance they already know the lyrics and steps to. It is a years-long conversation that has netted little in return.

However, the WordPress.org theme directory may be forced to change one way or another. Block-based themes are not arriving in some distant future; they are knocking at the door. Full Site Editing is slated to land in WordPress 5.8 this June.

With this change, the WordPress.org theme directory needs to be prepared. Even with a move today, it will be a mad scramble to get systems ready in a handful of months. If waiting for the last minute, it is just asking for chaos. Block-based themes should already be allowed to be uploaded, for example.

As we saw earlier this week, Automattic launched its Blank Canvas theme. It is designed to work on single-page websites. It does not support commenting out of the box, which is a requirement for inclusion into the official directory.

Block-based themes will forever change the system. In the past, traditional themes needed to cover all their bases, integrating with every front-end feature of WordPress. In the future, that is not necessarily the case. Because everything will be built from blocks and users will have direct access to customize those blocks, a theme has no need to cover everything. The user can add and remove features at their leisure. The review guidelines need to be molded for this future.

Full Site Editing almost seems purpose-built for outside-the-box theme designers. Whether it is a simple, one-page wedding invitation or an author’s book landing page, there are more possibilities upcoming than there ever were in the past. And, these things will be far easier to build on the theme-design side of things. It will remove a lot of burden from developers and from the Themes Team during reviews.

“Regarding the FSE themes: to be honest all my hopes are there,” said Stathopoulos. “They are very different, and it’s a fresh start for the repository. New theme paradigm, a different set of rules (with of course some overlap for basic things), and a new way of doing things and thinking about themes. However, if they are presented in the same way in the same repo we have now, then nothing will change. the theme repo needs to change, and there’s no way around that. But that’s a decision that will have to be made from the WordPress leadership and implemented by meta.”

As always, I remain optimistic about the future of WordPress themes, hoping for the ushering in of a new era. I get the sense that the Themes Team shares some of that enthusiasm, at least cautiously so. More than anything, they need the community, particularly theme authors, to chip in and shape that vision of what the WordPress theme directory should be.

Perhaps today, the stars are nearing alignment. Mullenweg plans to chat with the team and gather feedback in the coming weeks.

Is it okay to use plugins that are not current with latest version of WordPress?

People often ask me whether it is safe to run plugins that are not tested with the latest version of WordPress. And it's a good question, because software in general is something that you want to keep current and updated with all the latest. For WordPress plugins however, there are many plugins that simply don't need to be updated with each new version of WordPress.

The answer? It depends..

A safe answer for the general case would be that, unless there are known security or other outstanding issues, it may be fine but really depends on the plugin. For example, the original Subscribe to Comments plugin once went like 10 years without an update and kept working great. So even though it was many versions behind ("not tested"), the plugin had many happy users with no issues for years.

Ultimately you will need to do a little research to determine whether or not a particular plugin is safe for your site.

Why? Because many plugins are simple and use only well-established core WordPress functionality. For example, my plugin Disable WordPress Responsive Images contains fewer than 10 lines of code and uses two core hooks and some basic PHP logic. The code itself has not changed in over two years, and is safe to run on any version of WordPress 5.0 or better.

The difference is that some plugins (such as my own) are tested and updated with each WordPress update. So the changelog is kept current with everything even though none of the code may change from one version to the next.

That is why having a current readme.txt/changelog is so critical to plugin success. It eliminates the guesswork and saves the user time. Otherwise the infamous "hasn't been tested" warning is displayed on the plugin homepage at WordPress.org:

This plugin hasn't been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

You've seen that right? It is displayed for any plugin which has a readme.txt file that has not been updated for at least three major versions of WordPress.

The warning is helpful but does not tell the user whether or not the plugin is safe to use. There "may" be issues or there may not be issues. The plugin may be abandoned or may not be abandoned. It's just a "heads up" letting you know, essentially, that the plugin developer has not checked in with the plugin for at least three major versions of WordPress. Which is around a year or so.

The warning message essentially says, hey the developer of this plugin has not checked in for a while.

The warning message is NOT saying that there is any particular problem with the plugin, or that you should not use it. It is only telling you that the developer may be lazy or busy or whatever, and has not taken the time to check in and update the plugin or at least bump the version number in the readme.txt.

Subscribe to Comments WP Plugin"This plugin hasn't been tested" warning message for the Subscribe to Comments plugin

So the plugin may or may not work perfectly on the latest version of WordPress, even if its homepage displays the "not been tested" warning. This is why there is no one-size-fits-all answer to the question, "Is it okay to use plugins that are not current with latest version of WordPress?" Because it depends on the plugin.

As WordPress.org forum moderator Jan Dembowski clearly explains:

Because it's unnecessary to update the majority of plugins. The time of the last update does not mean anything to users nor does it mean that that plugin does not work or has any issues with the code.

Jan goes on to say that "it is nice when authors update the 'Tested up to' field to let users know that it works with newer versions but aside from that, this suggestion would generate a lot of work, punish authors and most importantly deprive users of plugins for a bad idea."

Determining if a plugin is safe to use

If you're a plugin developer, the easiest way to verify plugin functionality is to test it locally and examine the code.

For everyone else, and maybe developers too, you're gonna need to do some research. Here are some things that may help determine whether or not a plugin that is not current with latest WordPress is safe to use:

  • Look at the plugin's changelog (under the "Development" tab)
  • Post a question on the plugin's support forum
  • Read thru some posts in the plugin support forum
  • Contact the developer directly and ask if the plugin is safe to use
  • Search around online for other opinions and information
  • Examine the plugin source code, or hire a developer to do it
  • Test the plugin on a default installation of WordPress
  • Check the site error/debug logs for any signs of errors, warning, etc.

With a bit of effort, you can put the pieces together and get a clear picture of whether or not some "not current" plugin is safe to use.

If there is any doubt after a bit of research, do not use the plugin. Find another.

Also worth mentioning, if you notice any issue with the plugin, you can help the WP community by posting about the problem in the plugin's support forum at WordPress.org. Clearly explain the issue and any relevant information. Even if the plugin developer does not respond, maybe someone else in the community will. And if nothing else, your post may help others save some time with research and testing.

About the readme.txt file

The WordPress Plugin Directory uses the readme.txt file to determine whether or not to display the ominous "not been tested" warning on the plugin homepage. Each plugin includes a readme.txt file that includes information that looks like this:

Plugin Name: Disable Responsive Images Complete
Plugin URI: https://perishablepress.com/disable-wordpress-responsive-images/
Description: Completely disables WP responsive images
Tags: responsive, images, responsive images, disable, srcset
Author: Jeff Starr
Contributors: specialk
Requires at least: 4.4
Tested up to: 5.4
Stable tag: 1.8
Version: 1.8
Requires PHP: 5.6.20
License: GPL v2 or later

Notice the "Stable tag", "Tested up to", and "Version"? That all translates into the helpful information that is displayed on the plugin homepage. For example, the above readme header is converted to the following sidebar information on the plugin homepage at the WordPress Plugin Directory:

Disable Responsive Images Complete

The information displayed in the sidebar is super useful when determining whether or not the plugin is safe and healthy. If anything looks out of place or otherwise lacking, feel free to pass on the plugin and find something else.

For plugin developers

From one plugin dev to another, take a few moments for each major WordPress release and test/update your plugins. If the plugin does not require any changes, then at least bump the minimum-required and stable tags. It only takes a moment and definitely helps people in the community decide whether or not your plugin is safe to use on their site.


A Brief Guide for Configuring Nagios

Nagios is an open-source network monitoring software that was released under the GPL license. With more than 1 million users worldwide, it has an active community that provides free support and hundreds of add-ons developed by this community.

In this tutorial, we will be installing and setting up Nagios on an Alibaba Cloud Elastic Compute Service (ECS) with Ubuntu 16.04 installed.