Tag Archives: Guidelines

Chip Bennett 12:51 pm on February 19, 2013
Tags: Guidelines, Theme Branding   

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

Chip Bennett 3:26 pm on February 15, 2013
Tags: , , Guidelines   

Child Theme Support

I have just added a draft section to the Theme Review Guidelines, to cover requirements for Child Theme support/facilitation for hosted Themes:

 

  • Themes are required to facilitate the use of Child Themes. A “basic” Child ThemeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. (i.e. a style.css with Template headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. tag and @import() of the Template style.css), when activated, should function exactly as the Theme itself functions.
  • Themes are required to include functional and resource files in a manner that facilitates the use of Child Themes:

 

Based on discussion on the mail-list, consensus appears to be that facilitating end user use of Child Themes is beneficial, so this discussion is the first step in incorporating Child Theme support into the Guidelines.

Please discuss. Do you agree/disagree that Child Theme support should be added to the Guidelines? Are the above Guidelines sufficient? What should be added/removed/changed? What about pluggable/filterable functions?

#child-theme, #child-themes, #guidelines

Chip Bennett 12:49 am on January 17, 2013
Tags: Guidelines, Screenshot   

Clarification of Screenshot Guidelines

The current guidelines for the Theme screenshot read as follows:

  • Recommended 4:3 W:H ratio, size 600x450px (2x the previous 300x225px, to account for Retina displays).
  • Maximum size: 600x450px
  • Should be a “reasonable facsimile” of the Theme after it is initially activated with default options

I think a bit of clarification is in order, with respect to Themes designed to be used with a custom front page (i.e. front-page.php). I think that, in this case, the intent of the guidelines includes discretion to account for the design intent of the Theme. To that end, I would like to clarify that appropriate screenshots include the custom front page (front-page.php) display, even if that display requires the user to configure Settings -> Reading in order to display it.

Bear in mind that the original purpose of this guideline was to prevent undue marketing via the screenshot, either with unavailable “dummy” content displayed, or a screenshot that was a company/Theme logo, or that displayed something other than the Theme itself. A screenshot that displays the Theme’s front-page.php view is nothing like any of those mis-uses of the screenshot, and is a legitimate representation of the Theme.

What are your thoughts? Should the guidelines formally be clarified in this regard?

Edit

I forgot to mention: there is also an open Trac ticket to incorporate functionality to let Themes declare that they are designed to use a static front page, and “opt in” to that configuration as the default. If/when that ticket gets implemented, we’ll need to have this clarification anyway.

#guidelines, #screenshot

Chip Bennett 6:19 pm on January 7, 2013
Tags: 3.6, Guidelines,   

Coming in WordPress 3.6: Post Formats UI Improvements/Changes

See the make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. post here:

WordPress 3.6: the Post Formats UI feature

If anyone has any particular input into the what/how of improvements/changes to or standardization of Post Formats, please contribute there.

We’ll do our best to stay on top of any proposed changes, so that we can give as much advance notice as possible to Theme developers, for anything that would impact Theme development or the Theme Review guidelines.

#3-6, #guidelines, #post-formats

Chip Bennett 3:21 pm on December 14, 2012
Tags: , Guidelines   

query_posts()

While the clock has started ticking on the 3.5 release grace period for Guidelines updates, I would like to discuss formalizing one other _doing_it_wrong() issue that has been implicitly enforced for some time now: use of query_posts().

Would anyone be opposed if we formally added query_posts() to Theme Check as a required stopper?

To understand why query_posts() is always inherently _doing_it_wrong(), see @nacin‘s WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. presentation You Don’t Know Query, and this great WordPress StackExchange answer by @rarst.

In short, if you are creating secondary queries, you should use WP_Query(), and if you’re modifying the main query, you should 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. pre_get_posts.

Thoughts?

#discussion, #guidelines