Guidelines Shouldn’t Fail a Theme

Chip’s great post on Points of Emphasis and a recent discussion about a specific Theme Unit Test guideline (failing themes with long titles that overflow) point to a need to change our attitudes to the theme review guidelines.

If you step away from that specific TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket and look at the bigger picture you’ll see a change is needed to make all WP theme reviews less dogmatic and more pragmatic; not only WP.org directory but also for WP.com, ThemeForest, MOJO, any other marketplace that accepts some submissions and rejects others.

The items in the Theme Unit Test are guidelines not hard and fast rules. Highly recommended and encouraged and we should feature and love and promote the themes that nail them all. Shout from the mountaintops if a themer manages to achieve the full list! Themes that don’t nail them all can sink to the bottom of the list organically because people might end up not liking them as much.

Guidelines shouldn’t cause a theme to fail or be prevented from being in the directory. That should be limited to blockers like licensing, security, and spam/malware. What Chip said.

By letting theme designers choose to implement guidelines in full—or not—you give the power to end users to vote for the best ones by activating them. Instead of keeping out hundreds or thousands of potentially amazing themes that fail the too-strict rules we have now. The themes—and the people behind them—that we lose out on might never come back; and there’s evidence this has happened many times already.

Changing a strict philosophy of enforcing guidelines as rules to encouraging more experimentation and variety will go a long way to remove negative friction from reviews and make the themes in the collection better in the long run.

In summary: let’s enforce the “Points of Emphasis” (security, license, no spam) and leave the rest as recommended guidelines. We absolutely love if you follow them all, but none are blockers to your theme being included in the directory.

#community, #guidelines, #reviews

WP-Admin Theme Promotion

It has recently come to our attention that many Themes are using some…aggressive promotion techniques from within the WP-Admin:

  • Embedding videos and external IFrameiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. content
  • Redirecting to a Theme Info page on activation
  • Promoting the Theme (or an upsell commercial version of the Theme) via Admin Notices
  • Etc.

This sort of promotion is not appropriate. Adding a Theme info page is fine. Adding a Theme info page that promotes other of the developer’s Themes is fine. But redirecting to either of those pages on Theme activation is not. Adding an admin notice generated by the TGM PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Activation library, to notify users of companion Plugins that can enhance the Theme experience, is fine. Adding an admin notice to promote a commercial version of the Theme, or other Themes, is not.

Embedded or external content of any kind is strictly prohibited, due to potential security vulnerability and user bandwidth issues. Linking to those resources at ThemeURI from a Theme info or settings page is fine.

Please discuss in the comments, as it has just been pointed out to us that these issues impact a number of highly visible Themes. We need to ensure that we correct these ASAP, and ensure that we are handling them consistently when reviewing Themes.

#guidelines

Theme Review Points of Emphasis

Here are some of the things I’ve been looking for specifically when performing the final audit of approved Themes waiting to be made live. These are the most-frequent issues when reopening a ticket for an approved Theme. Please consider these as “points of emphasis”, to help improve the consistency of our reviews.

Prerequisites – these should be verified before even looking at Theme code

  • ThemeURI/AuthorURI: the first thing I do is check ThemeURI/AuthorURI for appropriateness.
  • If ThemeURI is a commercial Theme shop, or if the Theme is Up-Sell, I verify the commercial-Theme license, to ensure that it is 100% GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples./compatible
  • Credit Link: I then verify that the Theme has only one credit link, in the footer, that the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org is either ThemeURI or AuthorURI, and that link text and attributes are not SEO-seeded
  • Licensing: next, I check everything bundled with the Theme, verify that copyright/license attribution has been included, and that all licenses are GPL-compatible – fonts, images, jquery scripts, iconsets, everything. If it’s bundled with the Theme, it either needs to be copyrighted as part of the Theme, or include copyright attribution and be distributed under a GPL-compatible license

Code Quality

  • header.php: verify that HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. <title> tag includes only the call to wp_title(). Any additional content, if required, must be added via wp_title filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
  • header.php: verify that no scripts or stylesheets are hard-coded in the document head (except for the main stylesheet, and IE-conditional stylesheets)
  • header.php (usually): verify that calls to wp_nav_menu() include the ‘theme_location’ parameter, and do NOT include the ‘menu’ parameter
  • functions.php: verify that all function calls are placed inside of callbacks, hooked into explicit actions. No functions should execute directly from functions.php.
  • functions.php: verify that the Theme doesn’t call PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party-territory remove_action() calls, such as removing the WordPress version generator from wp_head
  • functions.php: verify that Theme does not add function_exists() conditional wrappers for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions introduced more than two prior major WordPress versions (currently: for any core function introduced prior to WordPress 3.5)
  • Template files and custom page templates: verify that Theme uses new WP_Query for secondary loops, and pre_get_posts to modify the main query, rather than query_posts()
  • Theme Options: verify that Theme options are being stored as a single array, are being sanitized on input, and escaped on output
  • Theme Options: verify that Theme options do not include “Plugin territory” options such as analytics/tracking code

Addressing these issues would cover about 99% of tickets currently being reopened after approval.

#discussion-topic, #guidelines

Clarifying Guidelines for Theme Name

The current guidelines for Theme Name are as follows:

  • Themes are not to use WordPress in their name. For example My WordPress ThemeWordPress AwesomeSauce, andAwesomeSauce for WordPress would not be accepted. After all, this is the WordPress Theme repository.
    • Themes are not to use the term Theme in their name, such as: AwesomeSauce Theme. Same reason as above … it’s a Themerepository.
    • Themes may use the WP acronym in the Theme name, such as WP AwesomeSauce.
  • Themes are not to use version-specific, markup-related terms (e.g. HTML5CSS3, etc.) in their name.
  • Themes are not to use related terms (e.g. BlogWeb LogTemplateSkin, etc.) in their name.
  • Themes are not to use Theme author/developer credit text in their name. For example AwesomeSauce by John Q. Developer(makes for a much better credit link); or, SEO/SPAM-seeded text, such as: AwesomeSauce by Awesome Free WP Themes (this is just not going to pass).
  • Themes are not to use related Theme names (e.g. WP Twenty ElevenTwenty Eleven WPThe Twenty Eleven, etc.) in their name.

In light of recent discussions, I think this would be a good time to clarify these guidelines. Please discuss below if you have any comments, questions, or feedback related to the Theme Name guidelines.

WordPress

The requirement not to use the term WordPress in a Theme Name should be obvious; all Themes hosted in the directory are WordPress Themes.

Generic Terms

The following Guidelines relate to the use of generic terms:

  • Themes are not to use version-specific, markup-related terms (e.g. HTML5CSS3, etc.) in their name.
  • Themes are not to use related terms (e.g. BlogWeb LogTemplateSkin, etc.) in their name.

These are the guidelines that I think are the least articulate, and need clarification.

The intent is to avoid generic terms related to design elements, features/functionality, or intended use of the Theme. Whether that’s markup (HTML5, CSS3), design (responsiveness), features/functionality (photo galleries, jQuery masonry), or intended use (“Tumblogging”, real estate, business), terms related to these aspects are better left to the Theme description and, where applicable, filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. tag keywords.

The purpose of a Theme name is to ascribe an identity to the Theme through the uniqueness of that name.  It is perfectly fine to invoke design elements or intended use of the Theme through the Theme Name, but it should be done using a creative/unique term, rather than a generic term. The intent of the related Guidelines here is to emphasize this point, and to help avoid naming conflicts and disagreements that arise from the use of generic terms.

Developer name

As with the WordPress term, I think this one is self-explanatory.

Reserved CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Theme Names

The WordPress Core team has chosen a naming convention to use for the annually updated Theme distributed with core. Thus, it makes sense to ensure that this naming convention is reserved for core.

#guidelines, #theme-name

Theme Branding/White-Labeling Guidelines

Recently some questions have come up on the mail-list that I think warrant extended discussion here. Those questions essentially revolve around Theme branding vs. “white labeling”: should footer credit links be required to be user-configurable (i.e. disabled) via Theme option? Should Themes include “branded” default logos or demonstration content, such as slider content, Twitter feeds, etc.?

Rather than making decisions (or creating new Guidelines) on the fly, let’s discuss those questions, and the issue of branding vs. “white labeling” as a whole, here. What I would envision coming out of this discussion would be a clarification of the Guidelines, to indicate more clearly what we’re currently requiring/enforcing, under a “Theme Branding” heading (or similar) that would envelop the existing “Credit Links” requirements.

For example: logos. Some Themes add a “logo” Theme option, but set the default as a text-as-image Theme Name “logo”. This is obvious branding, and obviously an instance where the user would rather have the Theme default to displaying the user’s configured Site Title, rather than a Theme-branded text-as-image “logo”. But a different developer may want to display a generic/arbitrary logo by default, to demonstrate the Theme’s custom logo feature. So: we should discuss where/how we want to draw the line of appropriateness.

In a discussion such as this one, my default position is: with all else equal, which decision is in the best interest of the end user? But it is equally important to consider the needs and interests of developers, as well. Guidelines should not be onerous or unreasonable for developers. I would contend that, when initially activating a Theme – whether on a new site or a site with established content – an end user will not want then to have to go through the Theme to “disable” the demo/branding content. So, I think it is reasonable to require that all default/demo imagery be generic/non-branded/”white-labeled”.

To take a counter example: footer credit links. Should developers be required to make footer credit links user-configurable (i.e. able to be disabled) via Theme option? I don’t think so. We put enough requirements around the form/display of footer credit links to ensure that they are appropriate, that I think requiring them to be user-configurable via Theme option crosses the line into being too onerous. (Consider all the Themes that have no Theme options; should we force developers of those Themes to incorporate all the overhead of Theme options, just for footer credit links?) What might be more reasonable, however, would to to recommend that footer credit links be user-configurable, via Theme option, custom filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., template-part file, etc.

Feel free to discuss from both high and low levels: from principle to guideline. But, please try to avoid the, “but Theme X does this” type of arguments. That we are discussing the need to clarify the Guidelines implies that existing Guidelines have been interpreted differently, resulting in different review comments for different Themes. Our aim here is to find consensus regarding the correct approach to handling these issues, regardless of how these issues have been handled consistently or inconsistently in the past.

#guidelines, #theme-branding