Thesis is a modular design and template system for WordPress. It’s what would happen if WordPress suddenly decided to replace its core template “system”1 with something more robust that would enable you to:

  • Build Themes with a visual interface instead of being forced to deal with clunky hybrid PHP + HTML files
  • Turn code in template files into living HTML objects that can be edited, moved around, and extended for additional functionality
  • Backup, restore, import, and export Theme data (templates, CSS, and associated options)

Thesis enhances your WordPress installation with this awesome functionality, but it does a hell of a lot more, too.

Note: We do not sell Thesis directly, but you’ll be happy to know that Thesis technology is included in the Focus WordPress Theme.

In the following sections, we’ll take a tour of what Thesis can do, and then we’ll examine how all this stuff fits together to become the ultimate enhancement for any WordPress website.

The Basics: Adding Options to WordPress

Adding options is one of the most fundamental things Theme and Plugin developers must do if they wish to convey dynamic functionality to users. Here’s how the basic process works:

  1. Convey a <form> with options in an interface
  2. Process the options when the <form> is submitted
  3. Save options to the database
  4. Retrieve options from the database as needed

While this process is bad enough on its own, WordPress actually makes it worse by having an inconsistent and disorganized approach to options that appear in different locations.

For example, there are 4 major locations within WordPress where a developer might want to add options:

  • admin pages — Theme and Plugin settings pages
  • post meta — options inside the WordPress post editor
  • terms — options for categories, tags, and taxonomies
  • theme customizer — specialty design options

In what can only be described as pure madness, WordPress accepts options in a wildly different format for each location.

This makes absolutely no sense. The HTML specification consists of a finite number of input elements, and you only need a few of these elements to do practically anything:

  • <input type="text" /> — basic text input
  • <textarea> — expanded text input
  • <input type="checkbox" /> — checkbox
  • <input type="radio" /> — either/or radio selector
  • <select> — dropdown selector

In other words, there are very clear patterns in play here. No matter where you’d like to convey options, you are going to be working with these basic input types.

Instead of leveraging these natural patterns and accepting a single, intelligible syntax for options, WordPress accepts a different syntax depending on where you’d like to convey your options.

This is perhaps the greatest shortcoming of the WordPress platform. And by extension, the solution to this problem is also one of the most important aspects of Thesis.

The Thesis Options API

The best way to think about the Thesis Options API is to consider it a translator for WordPress.

As explained above, WordPress requires you to speak at least 4 different languages to convey options wherever you want. This is grossly inefficient and fails to leverage patterns that could make this process easier.

To rectify this, the Thesis Options API establishes a single syntax for options elements called the Thesis Options API Array Format. Here’s how it works:

  • You provide an array of options in Thesis Options API Array Format
  • The Thesis Options API translates these options into the idiosyncratic languages WordPress can understand

1 The current WordPress theme “system” was released in 2005 and isn’t really a system at all—it’s a file naming convention run by a big if-else structure. It provides essentially zero functional leverage for the things Theme creators need to do.