Draft Theme Directory Guidelines

Projects Directory
1

Draft of the Theme Guidelines based off the plugin ones. I’m not a theme expert so welcome any feedback from theme developers and others.

The ClassicPress Theme Directory is intended to be a safe one-stop source for all ClassicPress compatible themes for all types of user, from the non-technical end-user to the developer.

The following rules are intended to provide transparency around the theme submission process for developers who submit their themes to the directory; further the rules aim to provide consistency and a level playing field for all developers.

If you have suggestions on improving the rules, or questions about them, please contact the theme moderators at [email protected].

  • All developers, users with commit access and all who officially support a theme are expected to follow the ClassicPress Theme Directory Rules.

  • All developers will ensure their contact information is accurate and up-to-date.
  • Developers must take a security first approach to their themes and ensure their themes are as secure as possible.
  • It is strongly recommended that additional functionality such as sliders, shortcodes, custom post types and so on, be available in recommended or bundled plugins rather than in the theme itself as themes should handle appearance rather than functionality.
  • Themes may not contact external servers without explicit and authorized opt-in consent from the user. Documentation on how user data is collected and used must be included in the theme’s readme along with a clearly stated privacy policy.
    • Integration with update servers which allow themes to update to new versions (such as Update Manager) is not included in this rule, but update services must not collect identifiable.
  • Free/Freemium/Premium themes are all welcome in the ClassicPress Theme Directory, but must be clearly identified as such in the description. Software-as-a-Service must be categorized as a Premium theme.
    • Free - completely free, un-crippled, and not soliciting in any way.
    • Freemium - some functionality free, but some requiring payment to the theme developer.
    • Premium - paid, with no functionality available otherwise.
  • All Free Themes must be compatible with the GNU General Public License; using the same license as ClassicPress (GPLv2 or later) is strongly recommended, but any GPL-compatible license is acceptable.
  • Where a theme includes GPL-licensed code, the theme must fully adhere to the GPL license.
  • Developers are solely responsible for the content and actions of their theme and must not do anything illegal, dishonest, or morally offensive, including exploiting loopholes in the Theme Directory rules. Furthermore, developers must respect trademarks, copyrights and project names; including such terms in the theme name may be acceptable depending on use, but never at the start of the name.
  • Only completed themes are acceptable for submission to the Theme Directory; incomplete or misleading submissions are not permitted.
  • All files within the theme must adhere to the rules and the developer will, prior to submitting their theme to the Directory, confirm the licensing of all included files (including all code, images, etc.) and that the terms of use of any services or APIs called by the theme are met. If this cannot be done, the theme should not be submitted.
  • Each time code is updated in the repository, the version number must be incremented; the use of Semantic Versioning 2.0.0 is strongly recommended. Frequent updates are not acceptable and will be seen as an attempt to game the search results; only release ready code should be committed.
  • ClassicPress ships packaged with libraries such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, etc.; themes must not include their own versions of any standard libraries.
  • Developers will act in good faith and will not restore code they were previously asked to remove or write code to circumvent the rules.
  • The developer will maintain their own GitHub repository for each theme which will include a stable version of the theme (as defined by the creation of a release).
    • It is recommended best practice, but not required, that a release zip is included in a release (added in the Attach binaries by dropping them here or selecting them section).
  • It is recommended for new themes that the theme folder/slug contain a vendor prefix. For example, a theme called THEME should have a folder of vendor-theme where vendor is the developer's unique prefix.
  • Code must be human readable. Obfuscating or encyrypting code by use of systems or techniques such as p,a,c,k,e,r's obfuscate feature, uglify’s mangle, ionCube's encryption or unclear naming conventions such as $abc123, is not permitted in the directory.
  • Publicly facing pages and files, such as Readme files, must not be used to spam users or game search results.
  • Only critical or highly important notifications should be displayed outside of a themes settings pages and must be dismissible; adverts are **not** permitted outside of the Theme settings pages.
  • Themes must not include credits or links on the public facing site without explicit opt-in permission from the user. Free themes may not require permission for the theme to function.
  • ClassicPress will maintain the Theme Directory to the best of our ability, but reserve the following rights:
    • To update the rules at any time.
    • To suspend or remove a theme from the directory for breach, in word or spirit, of the Theme Directory rules.
    • To allow new, active, developers to take over an orphaned theme (see adoption rules for further details).

Failure to follow the rules, or respond in a timely manner, will result in a theme being suspended from the directory until such time as the issue has been resolved; repeated failure to follow this rule may result in all a developer’s themes being removed from the directory and the developer banned from future submissions.

If you are uncertain whether a theme might violate the rules, please contact the theme moderators at [email protected].

2

Why is this in a code format? Did you take anything from the WP theme requirements? (they are more strict because the theme is the public face of every page of the site)

3

Fixed the formatting :slight_smile:

4

I would say “in recommended or bundled plugins”. A lot of theme developers bundle themes with their own utility plugins, which are sometimes required for theme to function.

We need a page in docs with a full list and versions.

Is it limited to GitHub? I remember discussions about other Git repos, like Gitlab.

Should we mention ionCube? It’s a popular way to encrypt proprietary code. If yes, I would add “Obfuscating or encrypting code”.

1 Like
6

I’ve made some updates.

The Plugin Directory is currently limited to GitHub, but there is, I believe, an intention to widen it out to other Git repos in future.

1 Like
7

The WP theme requirements look to be much more granular about what should be in a theme; I thought a top level guidelines doc linking to more detailed theme requirements would be a better approach (I have still to write the other document).

1 Like
8

Currently yes, but we will eventually support other Git providers.

1 Like
9

I have a problem with this applying only to Free themes. The license is clear that all derivative works should be GPL compatible. That doesn’t say anything about the sale of other code that is included. It seems to conflict with

All files within the theme must adhere to the rules

This should apply to all themes.

10

I agree tie @joyously here.

Wether free or not, WP is GPL, this means any derivate code or calling code must be GPL. And that means, any paid theme must be GPL too. Not a compatible, but plain GPL.
There is no run away from this in GPL. It is like a virus. Code written with GPL, even one line thereof, affects all and everything around it, as long it is published. If you do not intended to publish you can do whatever you want of course, but Github public repo is already publishing. Thus, GPL it is. For all and everyone.

Since a WP/CP theme has to use WP/CP api where available, just like plugins do, there is no “not using GPL code”. They all use GPL, even if just calling get_the_ID() or something like that.

I strongly disagree with this and it has made me eat my fists over at WP several times:

  • ClassicPress ships packaged with libraries such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, etc.; themes must not include their own versions of any standard libraries.

The thing is, if we deliver an outdated jQuery version, we cannot expect developers to stick with that.
That is just an example. I think this should be different in CP. Use what you like, we deliver XY, but it is not a must.

Not sure if that is a big change to make but it surely would change a few things in what we I can do, versus “I have to use this outdated jQuery because rules”

We should use latest stable versions of things, where possible, and if core cannot deliver we should leave the DEV to decide what to use.

What do you think about this?

Free themes may not require permission for the theme to function.

I am not sure why a free theme shouldn’t require permission for things described in this section which is “include credits or links on the public facing site”. I think no theme should do that, without explicit opt in, paid or not

Otherwise looks amazing, I think it is helpful and describes the expectations in general very well!!

11

Yes, they should, because loading multiple versions of the same library will cause a lot of problems. Or loading a newer version making your own code work, but causing errors in other code.
I answered a lot of support questions at WP forums when the jQuery update was done. All the plugins/theme on a site should use the same version of bundled libraries, or there will be problems.
(Feel free to backport the jQuery updates, any time now.)

It obviously needs rewording, because that is not the intent of what the guideline says. The guideline is about putting code behind a paywall or needing a license key in order to function. It is not about the user opting in to features or checking user capabilities, both of which should be done at the appropriate places.

12

I know the community is different here and WP, but here is a relevant comment from WP forum moderators about dealing with a mixture of free and paid stuff.

Slack forums Making WordPress-13
Slack forums Making WordPress-13900×445 60 KB

1 Like
13

Do themes and plugins have to be GPL? Reading through this there are themes and plugins published with split licences (PHP is GPL and images, css and so on are not).

Also, can a developer not take their GPL theme and apply a different licence to a premium version (even if only for the css, js or images)? It is their project after all. The question then becomes, will we list and premium themes which are not GPL compatible?

I’ve never used a premium theme; once you have them do they just work? No keys or anything required?

1 Like
14

There was a big “fight” between the Thesis theme creator and Matt Mullenweg about this specific issue. The Thesis theme wasn’t GPL licensed theme, so Matt raised hell and (I believe) threatened to sue. It’s now split licensed, GPL for PHP and proprietary license for CSS/JS/images. You can read more about this here.

Most premium themes sell continued updates and support, not the actual theme itself. So they do require license key/login details to authorize updates/support, and any other features that may use the theme developer’s API (like page templates).

15

But the basic theme would continue to work?

16

For the most part, yes. Some themes are bit more restrictive with what you can do without activating your license. But for the most part, themes do work. Only problem is with updates. If you don’t activate the license or your license isn’t renewed, you lose access to future updates.

However, many themes will sell lifetime updates but instead limit support and require additional payments for continued support. This is true for Envato marketplace themes.

17

GPL is for software.

They can’t if they are following the license, which says that it must be GPL.

This is the main question. According to the Philosophy page at WP, the GPL is a huge part of what’s going on there. The WP repo for plugins and themes are about promoting GPL solutions. Since CP is not supplying the storage for plugins and themes, nor the level of traffic, it could be said that we can choose differently on promoting GPL. But CP is GPL and everything derivative (plugin, theme) needs to be also.
Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation
Note that that includes having the source code. That’s the part that premium versions don’t want to give. Since the whole point of a CMS is a web site, and the theme is what makes it happen, it is obvious that a theme should work without requiring any sort of permission. (At least I’m not in favor of promoting any other kind.)

18

So a theme can have a split licence with not everything under GPL?

I’m pretty sure a developer can choose how to licence their code and can change the licence if they want. That’s maybe something @timkaye can answer?

This point wasn’t picked up on for the plugin guidelines. This is something which needs wider agreement before I make any changes to the draft as it will potentially impact the plugin guidelines as well.

19

My 2 cents on GPL requirements.

All code should be GPL or GPL equivalent in themes. Themes are derivatives of CP which is GPL licensed. I also believe Plugins should also be GPL(or equivalent) licensed.

At .org the GPL or equivalent requirements are inconsistently applied. For themes, all repo themes must be GPL, and Pro versions as well, even if the pro version is obtained off site.

For plugins, all repo plugins must be GPL, but off site pro versions do not have to be.

All resources, including images should be GPL equivalently licensed and follow the four freedoms of GPL. For example images should be freely distributable without accreditation (ie CC0 or equiv).

2 Likes
20

The license is about distribution. The developer can do whatever they want. It’s not always legal, however.
We have CP. It’s a derivative of WP. We couldn’t change it from GPL if we wanted, without getting sign-off from the thousands of contributors to WP.

21

We don’t have to speculate, we have a precedent to look at. Back in 2010, Chris Pearson (Thesis theme) and Matt Mullenweg had a debate on Mixergy about themes that are not GPL licensed. If anyone is interested in watching the video you can see it here.

Pearson claimed that he can license it whatever he wants. Mullenweg claimed that the provision in GPL requires plugins and themes to be GPL licensed.

Fast forward a few years, Thesis theme is split licensed as I mentioned above. PHP is GPL because it relies on WordPress. CSS, JS, and images are proprietary.

I’m OK with either option, require all themes be GPL licensed or allow split license. But, in no way we should allow themes that are not GPL licensed to be part of the directory.

They can do whatever they want on their own website, but being part of the directory probably should require full GPL license.

And if we were to allow split licensing, proprietary code should be open source so theme reviewers can audit it.

Edit: Chris Pearson is apparently behind DIYThemes, whose Twitter account called me a moron for suggesting/mentioning ClassicPress recently :joy: He’s got a lot to say about WordPress theme system:

The current WordPress theme “system” was released in 2005 and isn’t really a system at all—it’s a file naming convention run by a big if-else structure. It provides essentially zero functional leverage for the things Theme creators need to do.