The WordPress.org theme review team (TRT) has been in the WP news a lot lately, right?
Despite various tall tales, urban legends, personal attacks, and flavorful language being bandied about, we’re all a group of regular ol’, standard-built humans trying to make sure WordPress users have really awesome stuff. Some of us have different model numbers and come with our own set of flaws, but that’s OK. We all have the same goal in mind.
Unfortunately, there’s been a lot of misinformation and even some disinformation going around. I’m not going to beat dead horses. However, I do want to attempt to explain what’s happening with the current “content creation” situation. Maybe I can clear up some things before comment sections on certain blog posts start claiming we formed a secret organization to assassinate JFK.
What is content creation?
This is something I’ve written about before, such as in my Why custom post types belong in plugins post. In that post, I go on to list a few items that we don’t allow in themes hosted on the WordPress.org theme repository.
Here’s a list of things not allowed:
- Custom post types.
- Custom taxonomies.
- Non-presentational post metadata.
- Database tables.
- Custom comment types.
These are what we call the clear-cut cases. In fact, the automated checker won’t even allow themes to be submitted if it has some of those. These are not the things that we’re discussing. What we’re actually discussing are some gray areas, which I’ll get to in a moment.
Why are you “cracking down” on this now?
We’re actually not cracking down on anything. This is not a witch hunt or anything of that nature. We’re neither hunting down popular themes with upsell versions nor plotting world domination. None of us have the time for that sort of thing anyway.
When we spot issues, we attempt to correct those issues and work with theme authors to bring their themes into compliance. We deal with these things on a case-by-case basis because each issue is unique and needs a specific path forward.
When we have confusion, we attempt to discuss and clarify items so that there’s no confusion, or at least less confusion. The guidelines are a bit of a living document, one that must be refreshed from time to time with the blood of developers and reviewers.
That’s what this whole content creation discussion is about. The content creation guideline isn’t being consistently applied by reviewers. Therefore, in the next team meeting we are going to deal with this inconsistency.
The gray areas
Where the team of 100+ humans have been inconsistent is in dealing with gray areas. This inconsistency isn’t fair to theme authors because different reviewers are applying a particular guideline in wildly different ways. It makes sense that we bring some clarity to the situation.
To help understand the discussion a bit more, I’ll leave you with some examples of the types of things we’ll be clarifying. This won’t be an exhaustive list of examples. It’s merely a list to help explain what all this stuff is about.
Example #1: Footer text
Imagine a theme had an editable
<textarea> in the theme options to allow you to alter what’s shown in the footer. Is it content? Can it be better handled by something like a text widget?
Personally, I believe this one is pretty easy to figure out. It’s a theme-specific setting that theme users won’t care about when they switch to a different theme in the future. I consider this part of basic theme setup and would say it does not fall under content creation.
Example #2: Portfolio projects
Now, imagine a theme that allows you to create portfolio projects via theme options (or widgets). Remember, we don’t allow a portfolio project post type and consider such a thing plugin territory (one of those clear-cut cases). This isn’t technically a post type. Otherwise, it would’ve never made it past the automatic scan prior to submission. It’s a theme option, but it does the job of a post type.
wp_options table really isn’t meant for this sort of long-form content. Also, in this case, users may want their portfolio projects around when they switch to a different theme. This seems to be a case of a custom post type disguised as a theme option.
Example #3: Profile widget
A profile widget might allow a user to upload an image and write a paragraph or two about themselves. There is a far better method of coding this to auto-pull in a user’s biographical info and avatar, saving them from having to copy/paste info many will have already provided.
However, because the “content” is generally so small, I really don’t care much whether themes are adding widgets like this. I just think there are better ways of coding it that are more portable across themes.
Example #4: Front page content sections
Imagine a theme that allowed you to configure your entire front page. Imagine if you could configure each section with newly-written content or maybe just certain sections.
When does a theme jump over into WordPress core and plugin domain? Where’s the line? Are a few text box sections OK? Is having to write an entire front page’s content via theme options the best way forward? What effect does this have on users?
This is at the heart of the discussion (i.e., not a current decision).