0
WordPress theme development has, over the years, become a much more involved industry than it was during years past. Themes have gotten more intelligent, more feature rich and, to sum up, far more robust in their offering. It is not uncommon today for a theme to, for example, include an advanced theme options screen for tailoring a theme without code, or a selection of custom-developed widgets to showcase content is a specific manner or of a specific type.
As with scaling in any context, expanding one’s offering is vital to maintaining the status quo and “keeping up” with industry competitors. At WooThemes, this expansion is generally handled within the WooFramework (the engine that powers all of our 120+ themes) by creating and adding features such as a shortcode generator (along with a wide collection of popular shortcodes), a collection of popular social widgets, SEO settings via WooSEO and a system to create custom sidebars via the Sidebar Manager. This expansion is also, at times, handled using our popular “Theme Options” screen, where settings specific to your WooTheme of choice are controlled.
As one can imagine, adding theme option after theme option could easily get out of hand, creating a long list of settings you’d need to run through to customise your theme. This brings us to the question we posed during a development discussion at WooHQ last year- “are theme options always the answer?”.
The approach
This question has caused us to take a slightly different approach to our theme options and how we approach them. Rather than going through and adding options as we see fit, we’ve taken a stance on adding options as sparingly as possible. This allows us to analyze the theme in full and decide which settings require specific theme options and which settings are, for want of a better word, redundant. Certain settings may not apply in all contexts or to all users of the theme, while others (such as, for example, the ability to activate or deactivate a specific section of the theme’s functionality) is something that applies in all cases.
Along with this approach, we’ve taken a slightly different angle in terms of how the functionality itself is developed. By creating small components and bundling related functionality into either a single file (for small components) or a class (and object) for larger components, we are able to focus on each component individually, ensuring that the specific component in question is approached from the most accurate context.
A practical example
Lets take our Wikeasi theme as a practical example of how we’ve applied these principles.
The Wikeasi default homepage layout
Wikeasi is a WordPress theme based around the creation of a wiki system, built on WordPress. Wiki’s themselves tend to lean towards specific functions such as a table of contents, revision management and display and being able to create bibliography or source references. Wikeasi handles all three of these functions, as well as many more.
In our approach to Wikeasi, we left the theme options to the very end, right after all the functionality was developed, tested and firmly in place. With revision or reference management, for example, it’s quite easy to get carried away and add theme options for every possibility. Is this the answer to an attractive and ultimately, more usable, product? We don’t believe so, no. Fewer theme options allowed us to focus in and ask, “what would I, as a user of this theme, want to change and setup?”. The majority of theme options in Wikeasi (organised into component-specific sections) allow for the activation/deactivation of the specific component and possibly a short notice explaining a feature of that specific component. This means it’s possible to get in and out of the theme options screen quickly, having easily setup and customised your theme without being overwhelmed with theme options.
Enabling The Table of Contents
Other functionalities, such as the customisation of a component’s output, for example, are handled using carefully placed WordPress filters. Using filters, it’s possible to customise the theme to your needs with a short snippet of code, rather than a complex theme option that, perhaps, 8 out of 10 users won’t benefit from.
Has this approach worked?
Yes, it has.
This approach can also be seen within WooCommerce and other popular WordPress plugins. For example, why create a whole interface to add tabs to the “Product Details” box in the WooCommerce admin, when a simple WordPress action hook will produce the same result with a leaner code base?
How do we know this? The numbers speak for themselves.
Wikeasi is, according to PressTrends, powering some 528 websites currently. The number of support queries Wikeasi has received in our forums is roughly 11% of that. We can, therefore, ascertain that this approach works. Scale back on unnecessary theme options in favour of a code-based solution.
Lets not forget the fact that Wikeasi is a feature-rich theme.
Hold on, are we losing functionality?
Quite the contrary. This approach affords greater functionality and flexibility, without the limitation of a theme option. For example, what if we wanted to turn the filter bar in Wikeasi off on a specific section where it was displayed previously (for example, on search results)? With the theme options approach, this would need to be a selection of theme options to enable/disable the filter bar in various cases… this is boxing you in as the user. By changing our approach ever so slightly, we’ve just opened up a whole spectrum of new possibilities.
The “golden age” of theme options is over
To sum up, our approach to theme development is evolving and changing as the industry develops. Minimising theme options used in themes, coupled with careful consideration of a component’s application in the theme and a selective placement of WordPress filters, allows for a richer theme setup experience for our users while still adding a level of flexibility that is possible to hone in on, should you wish to do so.
WordPress itself is about making publishing easy for the end user. Why not echo that ideal within your theme or plugin? Make the initial setup process easy. If the user wishes to delve deeper, add the functionality to allow them to do so.
“Just add a theme option” is a phrase that is steadily becoming somewhat of a “curse word” at WooHQ. Why stick to using theme options when we could do so much more by slightly changing our approach to the code itself?
WordPress actions and filters have been a long-running standard within WordPress itself. Why not hone in on that and take full advantage of the functionality possibilities it offers?
Keep an eye out for this one, folks. The days of “just add a theme option” are slowly moving behind the WordPress community.
A teljes bejegyzés elolvasása
