Tag Archives: Guidelines

Chip Bennett 1:25 pm on November 12, 2013
Tags: Guidelines   

Theme Unit Tests: Recommended

Based on the recent discussion prompted by @lancewillett, the following change has been made to the Guidelines, effective immediately: the Theme Unit Tests have been reduced in criticality from Required to Recommended.

We believe that this change will help eliminate a source of subjectivity/inconsistency in Theme reviews, while ensuring that review effort focuses on the truly required criteria. And in all honesty, almost everything that is truly required in the Theme Unit Tests will be found during the code review. In the future, this change may allow us to re-focus the Theme Unit Tests on recommended/best-practice design/aesthetics, without introducing further subjectivity into the review process.

Please note that this change does not impact any of the rest of the Guidelines; only the Theme Unit Tests specifically. And during reviews, Themes should still be checked against the Theme Unit Tests, any conformance issues should be noted as Recommended as part of the review, and Themes will still be required to document any extraordinary design limitations.

As a reminder: when conducting a review, please ensure that Required criteria are clearly stated, separately from recommendations or other comments, to ensure that those required criteria are clearly communicated to the developer. (A bullet list of required items usually helps.)  Reviewers are welcome (and encouraged) to leave other recommendations or constructive feedback for developers, but we need to ensure that developers know exactly what is needed in order for Theme approval.

As always, thank you, all, for your continued contributions!

#guidelines

Lance Willett 4:37 pm on November 10, 2013
Tags: , Guidelines,   

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

Chip Bennett 11:28 pm on November 4, 2013
Tags: Guidelines   

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

Chip Bennett 3:40 pm on November 1, 2013
Tags: , 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

Chip Bennett 2:48 pm on February 26, 2013
Tags: Guidelines, Theme Name   

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 Theme, WordPress 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. HTML5, CSS3, etc.) in their name.
  • Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, 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 Eleven, Twenty Eleven WP, The 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. HTML5, CSS3, etc.) in their name.
  • Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, 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