Theme Frameworks and Namespacing Guidelines 

Due to confusion – mostly caused by inconsistent nomenclature – regarding namespacing requirements for Theme frameworks, we would like to clarify the guidelines, and open the floor to discussion.

First, a word on nomenclature. For the purposes of this discussion, and the guidelines, a “Theme framework” is not a stand-alone Theme, but rather a “drop-in” code library used to facilitate Theme development. The following are examples of such Theme frameworks (note: this list is not an endorsement; rather, it constitutes a quick Google search for examples only):

Note that none of the above examples constitutes a full, stand-alone Theme. Each is a library of code, used to develop a Theme. Such code libraries are different in both nature and purpose from stand-alone Themes that use the term “framework” to refer to an intended use as a Theme to be forked for further development. (Even the Codex conflates the uses of the “Theme framework” terminology in this manner.)

So, to keep the terminology clear, when I refer to “framework”, I mean a drop-in code library, and not a stand-alone “starter” or “base” Theme. In other words, using this definition of “framework”: Hybrid Core is a Theme framework; the Genesis Theme (even though it is called “Genesis Theme Framework”) is not a Theme framework, but rather a stand-alone, base/starter Theme.

Now, on to the Guidelines, which include the following requirement:

Themes are required to use a unique slug as a prefix for anything in the public namespace, including all custom function names, classes, hooks, public/global variables, database entries (Theme options, post custom metadata, etc.)

This guideline applies to forked/derivative Themes. For example, several Twenty Ten and Twenty Eleven derivative Themes get submitted to the repository. We require these Themes to re-namespace their custom functions, hooks, global variables, textdomain, etc.

However, some confusion arises when a Theme uses a framework – i.e. a drop-in code library – to develop the Theme. Should the Theme be required to re-namespace the framework code? Our current thinking is that such a requirement would effectively defeat the purpose of using a Theme framework, and would deter, rather than facilitate, Themes using such frameworks – and, more importantly, keeping the framework updated.

Requiring Themes to re-namespace such framework library code would be analogous to requiring Themes to re-namespace bundled jQuery Plugin libraries. Also, requiring such re-namespacing serves no practical purpose, and would be counter-productive toward one of the Theme Review Team’s long-term desires to have the means/process/infrastructure for vetting/approving such Theme frameworks, in order to facilitate their broader use. If we started requiring Themes to re-namespace the framework library code today, we’d have a mess on our hands in the future, if we one day are able to have vetted/approved versions of those same frameworks.

So, bottom line, TL:DR: forked/derivative stand-alone Themes ARE required to re-namespace; Themes that use framework libraries are NOT required to re-namespace the framework library code.

What are your thoughts?