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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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, hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., 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 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 Plugin Directory or can be cost-based plugin from a third-party 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?

#frameworks, #guidelines, #namespacing