Functionality for WordPress Custom Themes
When I first began working with WordPress my approach to custom themes wasn’t much different from my approach to any single site. My first WordPress custom themes weren’t much different from the HTML/CSS sites I had previously built using php includes. I used WordPress functions to display dynamic elements but rarely used plugins.
I’m not sure where I got this impression but I thought of plugins as cheating. It seemed much tidier to have all functionality neatly tucked away in the theme. I could customise the functionality based on my clients use-case. I prided myself on having as few plugins as possible.
My reasoning was as follows:
Plugins can be bloated and badly written.
They can introduce bugs and conflicts (often a result of poor namespacing).
Sometimes their very nature requires them to incorporate edge cases that don’t pertain to the site at hand.
They can require supplementary configuration with settings that are unneeded and unused.
They require updates.
Little by little I became aware of some invaluable plugins that cut my development time substantially. There were also plugins that did things that I didn’t know how to do and had no interest in learning. As more and more WordPress plugins were added the the repository the cream began to rise to the top and it was easier to choose a good plugin. Paid plugins offering support became part of the WordPress ecosystem. The concept of not reinventing the wheel became popular. It made me realise that if my clients had to wait until I knew and understood everything to have a great product then they were going to have to wait a long time.
I went from using practically no plugins to using a few select ones that did things specific things.
As I became more confident in my theme building skills I began to examine the idea of creating premium themes for a theme marketplace. I began to dissect and examine premium themes and to modify their functionality in client projects.
This was a very eye-opening experience as I discovered the following:
Themes can be bloated and badly written.
They can introduce bugs and conflicts (often a result of poor namespacing).
Sometimes their very nature requires them to incorporate edge cases that don’t pertain to the site at hand.
They can require supplementary configuration with settings that are unneeded and unused.
They require updates.
Those who have worked with WordPress for more then a few minutes will have doubtless heard of security problems resulting from plugins, particularly TimThumb and most recently Revolution slider. In the second case the bug was quickly fixed and included in an update but was bundled in many themes that either didn’t have updates available or required the end user to pay a fee for support and updates. These bugs would have been much more manageable if included as plugins. This led me to thinking about my approach to client sites and a framework I was creating for hotel sites.
What if all functionality unrelated to the design was in the form of plugins?
I began to reexamine my reasons for including functionality in a theme.
I was comfortable with the process
I considered myself a theme developer rather than a plugin developer as a result of my background in design
I didn’t have much experience in creating plugins
These three points seemed relatively easy to correct. They were all about perception and lack of experience both of which can be changed with practice.
I decided to change my ways and to not just pay lip service to the idea of confining functionality to plugins. In doing so I have discovered that building plugins isn’t as daunting as I had assumed. In the following articles I will be documenting the process of creating a custom framework with all functionality contained in custom plugins. My goal is to end up with a completely modular system that allows me to simply change the theme to allow for a complete redesign while keeping the functionality required for various client projects.