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 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