Transparency Report #19 – Our Most Popular Free Theme (Zerif Lite) Suspended From WordPress.org

Welcome to the 19th edition of our monthly transparency report (for August 2016). In this series, I cover various aspects of running a WordPress business, discuss our own strategies and plans, as well as struggles and hardships. In short, this is where you can find out what’s going on behind the curtains at Themeisle and CodeinWP. Click here to see the previous reports.

Why you should care about the WordPress.org theme directory

I care a lot about the experience users get when they visit WordPress.org’s themes section. Ultimately, the quality of that experience is the driving force behind all WordPress.

In a sense, the end user doesn’t care about the software itself. They care about how it performs, and chief of all, how their sites look.

Quite naturally, the themes available in the official directory will be the starting point for most new users coming to WordPress for the first time. Even though premium marketplaces and theme stores have made their mark on the landscape, they are still – in my belief – a secondary place to go if someone needs a theme.

Frankly, for nearly everyone, the path is:

• Need a theme > go to WordPress.org > nothing there? > go to Google > go to a marketplace

On that path, WordPress.org and the themes offered there are key.

If the themes become too hostile towards end-users – users who are not developers – they won’t even care to check alternative theme repositories … they will just leave WordPress as a platform altogether. And go to Squarespace or whatnot.

For that reason, again, what is in the WordPress.org’s theme repo is key. And it’s key to all our careers in the WordPress business. No matter if you’re building free themes, paid themes, WordPress.org-hosted ones, ThemeForest themes, or themes sold via an independent store; WordPress.org is a crucial stage on your user’s path to discovering you.

But despite its value, your relationship with WordPress.org can be a love-hate one…

I need to be honest with you … things haven’t been easy for us regarding the official theme repository.

As you may or may not know, Zerif Lite is our most popular free theme, with over 200,000 active installs, and it’s it was also a mainstay on the WordPress.org’s list of the most popular themes.

Over the years, the theme has been recognized by end-users, and has been an inspiration for other developers when building their themes.

But Zerif Lite has also been causing some inconvenience to the theme review team at WordPress.org. Long story short, the theme has been facing a possible suspension from the directory, and was given two weeks to fix all its alleged issues.

That was two weeks ago.

As of this writing, Sep 14th, Zerif Lite has indeed been suspended, and you are not able to get it through WordPress.org anymore. Going to https://wordpress.org/themes/zerif-lite/ gives you this:

Two things before I continue with the topic:

• I don’t intend to make this a public drama kind of post. This is more about how we can avoid these situations in the future, and how other developers can approach similar problems if they ever come across them.
• I won’t talk about the individual details regarding the issue, or anything like “how we are right and they are wrong.” This is not the purpose. We have our rights and wrongs on either side, and I don’t think it would be all that cool if I just poured out our grievances here in hope to get the community on our side.

So, like I mentioned at the beginning, because I care a lot about the experience users get when they visit the themes repo, I’d like to take this opportunity to talk about the problems with the whole environment itself, and discuss the possible ways of improving it.

(For those of you interested in the Zerif Lite issue, you can just hop over here – the official ticket at WordPress.org.)

On building WordPress.org themes, getting them approved, and then banned

From a developer’s perspective, building a *new* theme – with an emphasis on *new* – and then having it included in the WordPress.org repo is more or less a straightforward process. (Please bear with me.)

What I mean is that there are rules to follow, and if you do follow them well enough, you’ll get accepted. I’m not talking about the complexity or the utility of those rules. It’s just about the fact that certain rules need to be followed if you want to be included.

And that is fine.

But over time, when rules get changed – new guidelines being introduced, old guidelines removed, etc. – you might find yourself in a tricky situation.

The current WordPress.org repo landscape is divided into two parts, more or less:

• When a new theme is submitted, it gets reviewed, and if it’s in tune with the guidelines, it goes online.
• But the process isn’t as straightforward for existing themes. Any existing theme can be, at any point in time, brought to the review team’s attention as not being in tune with the newest set of guidelines.

The latter is most likely going to happen when authors of other new themes start asking, and rightfully so, “Why my theme can’t do Thing X, but this old theme over here can?”

At that point, you may be requested to update your theme so that it adheres to the most up-to-date rules, which seems reasonable. But this is also where the problems (can) start.

First, let’s set one thing straight. If any changes you’re requested to do eventually lead to a better overall product then this is all a non-issue. You’re simply getting someone from the theme review team doing the research work for you, and pointing out how exactly you can make your theme better. Great!

The real problems start when the changes forced on you aren’t necessarily good for the end-user.

Why would that ever happen?

This is a bit tricky, but I hope I can explain what I mean:

To begin with, let’s keep in mind that any theme previously accepted into the repo was 100% in tune with the rules at the moment of approval. So we’re not talking about a situation where a theme refuses to cooperate altogether.

Now, about rules themselves:

I don’t want to argue that the current theme rules are worse than they were, or the other way around. Rules are rules. Essentially, building a new product according to “Rules A” or “Rules B” is similar in nature. You just need to follow certain steps. However, the story is entirely different when moving from “Rules A” to “Rules B.”

Here’s the thing; as a theme developer, you might find yourself in a situation where your theme is perfectly user-friendly and perfectly okay with the rules at the time it was submitted. Then … new rules get introduced, and they seem reasonable too. However, right there, right there in the middle, lies the transition itself.

And that transition alone is rarely user-friendly.

What it all comes down to is that if you’re requested to remove a big chunk of your theme functionality just to be compliant with the new rules, what do you think happens to the theme’s current users when you make that move?

Yes, you are right, their sites stop working! Or maybe not stop working, but they lose the functionality that they were told they would get when they first installed the theme.

Essentially, you’ve promised them that each update will make their experience even better, yet you’re doing something exactly opposite. In an extreme scenario, you might render the theme useless.

So depending on what sort of changes you’re requested to carry out, the situation can be really difficult, it’s basically the hammer or the anvil:

• On the one hand, if you don’t make the changes, you’ll be banned from the repo.
• If you do make the changes, you stay in the repo, but you’re messing up the sites of your current users.

Which is worse?

…

Let me tell you how I see this from my own perspective.

I’m – we are – all about building products that follow the principles of “user first.” We want our stuff to be helpful, useful, and reliable. If we’re suggested a change that will make everyone’s experience better, we’re all for it!

But if the changes can lead to making our users’ lives exponentially more difficult, then we cannot take that step and feel good about it. It would be us betraying our users and customer base.

Ultimately, ending with a worse product/experience is not something that we care much about. In my view, disrupting the current user experience is just not worth it, and until we find a way to keep that user experience intact – and in a way that the review team is cool with (so far, our suggestions haven’t been received well) – we will have to stay suspended from the repo.

Sure, this will diminish our revenues a lot. Company-wide, I’m estimating probably around a 50% sales decrease post WordPress.org repo suspension.

This would certainly require quite a lot of optimization, but we are glad to be in a position where we can afford to do only what is best for our customers and us – the company – in the long run.

The solutions

The situation isn’t an easy one, and not only for us, but for other theme developers that have faced similar problems in the past, or are facing them right now.

I have a couple of propositions that could be the basis for discussion when we’re searching for viable solutions:

1. Not making the rules retroactive

I don’t believe that any one theme should be treated differently based on its reputation, popularity or whatnot. But, at the same time, I also don’t believe that any rules or laws should be retroactive.

As a rule, law is not retroactive; it affects only future activity, that is, what will take place after the law has gone into force.

Having similar rules in the directory would certainly help. And this would be quite simple:

• If your theme got accepted to the directory and was found to be in-tune with then current rules, then it’s good to stay like it is.
• Only if you want to submit an update that goes above critical bug fixes, you need to make it in-tune with the newest rules.

2. Introducing minimal requirements

The repos are working towards automation. We simply have too many themes and plugins submitted every single week, so doing human review for each addition is both too time consuming and also probably leaves a lot of room for oversight.

So one path we can take with automation is to just accept every secure and safe theme into the directory, and then have a better search algorithm (what plugin repo is doing) that would display the best match first (based on various factors).

I believe it to be both the easiest and the best thing we can do.

In a scenario like that, developers have more freedom and can experiment with various unusual solutions. See this quote:

Or this one; also Matt Mullenweg :

We have a lot of hard and strict rules designed to “protect” users, like around CPTs et al, but someone could make an informed decision to trade off future potential portability for current form or functionality. it would be a perfectly rational decision to make.

For example, Amazon takes advantage of their search mechanism to the max. It’s a free market economy there, basically. Good products get good reviews, so they come up higher in the search results. Bad products get buried. It’s the community of buyers that regulates it.

Having something like this for WordPress.org theme search would be awesome!

3. Allow on-boarding

Themes are sometimes incredibly complex pieces of software, and expecting the user to simply click the “activate” button and then be done with everything that needs their attention is just mad.

Being able to on-board new users is key to helping them configure their new theme, and also learn how to get all its benefits. This could help us to offer a great “look like the demo” experience, while focusing on what is good for the users at the same time.

4. Having a better previewer

This is maybe not 100% related to the issue at hand, but I do believe it’s crucial for the overall usability of the WordPress.org repo.

Quite simply, the current previewer is useless.

Its uselessness is all about making the preview look nothing like the theme screenshot.

This just needs to be better. Theme authors need to be able to tune up the previewer to really display an optimized demo – something that actually gives the user a good overview of what the theme has to offer.

What’s next for Zerif Lite users, post WordPress.org suspension

A couple of important things:

(a) We still love the theme and will keep it alive

Hey, Zerif has grown to be one of the top 5 most popular themes on WordPress.org for a reason. It is awesome! And we still believe in it wholeheartedly.

This means that we will still continue working on it and make it even better.

(b) You can still download Zerif Lite

Just go to our site and get Zerif Lite from there (no opt-in required).

(c) You can still get support

You can visit the main support section here. There you can find our in-depth documentation guides, FAQs, and also a way to contact us.

To get priority support, consider joining our theme club (premium).

(d) Contact us if you downloaded Zerif Lite through WordPress.org

Here’s the core of the problem: If we upload a theme to WordPress.org, we can’t have an update script added to the package. This means that if we want to deliver updates at any time in the future, we are forced to keep that theme on WordPress.org.

In our case, with the theme getting suspended due to the change of rules (without a reasonable way to fix things), more than 300,000 users have been put at risk due to using a theme that cannot be updated.

Even worse, we don’t know who those people are, so we can’t communicate with them. So basically, those aren’t “our users” anymore, even though we still appear as the developer of the theme.

For example, if a security issue is reported to us, we can’t do anything, yet we will still be blamed. This seems to be a pretty big thing.

So in the end, reach out to us if you’re a Zerif Lite user. Let’s keep your theme safe and secure.

(e) What’s next for us, business-wise

Like I mentioned earlier, I’m estimating probably around a 50% sales decrease as a result of this.

Obviously, we need to cut down on things and optimize. Here’s what we’re going to do in the near future:

Reduce costs

• Cancel software subscriptions that we don’t use that often, or frankly don’t need (sorry, Mixpanel).
• Stop doing sponsorship for the time being (less WordCamps, pods.io, etc.) … Essentially, less users means less support, which will allow some support members to work on the development side of the business, which they are perfectly capable of doing.
• Lower some AdWords bids, and focus more on efficiency rather than reach. The same goes for re-targeting ads.

Reach out to our community

• Inform as many users as we can and guide them through the process of keeping their theme up-to-date.
• Inform popular news sources in the community.
• Inform bloggers and content producers who linked to us in the past to edit/update their articles.
• Direct everyone to the theme’s page on Themeisle.com, where they can download it without an email address.

Proceed with caution

We need to wait 48 hours or so to see how the community reacts to this whole thing, and also how effective we are in reaching our current users.

We’re releasing another post on the Themeisle blog, explaining the situation to our users and instructing them what to do going forward. We’ll also email everybody and do lots of re-marketing to get people on the new version of the theme.

Long term, we will need to wait a bit and see where we are, how bad/well things are going, and work from there. Nothing we can’t do.

…

In the end, I hope that by making our points here, we can help change things for the better, and also help out other theme authors who might be facing similar problems.

I also hope that we will be able to get the theme in the repo eventually, and, more importantly, that our users won’t suffer too much in the meantime.

As always, thanks for reading and for supporting CodeinWP! Stay updated and get new reports delivered to you by subscribing here:

All edits and witty rewrites by Karol K.