Title: Frameworks – Make WordPress Themes

---

#  Tag Archives: Frameworks

 [  ](https://profiles.wordpress.org/chipbennett/) [Chip Bennett](https://profiles.wordpress.org/chipbennett/)
7:56 pm _on_ March 14, 2012     
Tags: Frameworks, [Guidelines ( 34 )](https://make.wordpress.org/themes/tags/guidelines/),
Namespacing   

# 󠀁[Theme Frameworks and Namespacing Guidelines](https://make.wordpress.org/themes/2012/03/14/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):

 * [Carrington Core](http://carringtontheme.com/category/development/)
 * [Hybrid Core](http://themehybrid.com/hybrid-core)
 * [UpThemes Framework](https://github.com/LiftUX/UpThemes-Framework)
 * [Options Framework](https://github.com/devinsays/options-framework-theme)

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](https://codex.wordpress.org/Theme_Frameworks)
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](https://codex.wordpress.org/Theme_Review#Theme_Namespacing):

> 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 WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
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](https://make.wordpress.org/themes/tags/frameworks/), [#guidelines](https://make.wordpress.org/themes/tags/guidelines/),
[#namespacing](https://make.wordpress.org/themes/tags/namespacing/)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fthemes%2F2012%2F03%2F14%2Ftheme-frameworks-and-namespacing-guidelines%2F%23respond&locale=en_US)