WordPress Development – Coding from Scratch vs. Using Plugins
Almost every WordPress project that you will take requires some new development. In this post we’ll compare between custom development to using existing plugins and give a real world example for your inspiration.
Do you know this feeling? You got an interesting WordPress project that’s more than a simple brochure site. The budget is limited and you’re looking for how to build it so that you end up with some profit. You could go with a theme that promises to do exactly what you need, but your experience tells you that it’s never that simple. You can put it together with a combination of several plugins, which you hope will play nice together. Or, you can build it all from scratch, where there are no surprises, but it’s a lot of work.
If you start on one path, switching to a different one will be expensive and frustrating. So, what do you choose?
Option 1 – Using a theme that does exactly what you need
Themeforest has over 11000 themes. Of them, almost 5000 are tagged as ‘multipurpose’, so the rest are niche themes. That’s over 6000 themes that are designed to do one thing specifically well. If you need something special, most chances are you’ll find it among these 6000 speciality themes.
Look at the 20 best selling themes on Themeforest. 18 are ‘all purpose’ and 2 are ‘magazine themes’. A detailed study by Hermesthemes shows that multipurpose themes power the vast majority of hotel websites. Over 80% of the WordPress hotel sites use multipurpose themes. You’d think that for such a niche application more people would use one of the many hotel themes, but that’s not the case. Why does this happen?
The greatest benefit of using a specialty theme is also its greatest drawback. Specialty themes include a set of features, which the developer created to implement a certain function. Sometimes it’s for a hotel. Sometimes it’s for a listing site and sometimes it’s for a wedding.
The problem is, almost always, you get almost everything that you need, except that tiny little bit. Turns out that implementing that tiny little bit inside a theme that’s streamlined for a specific purpose isn’t that easy. Now, instead of paying $60 and having a working site, you need to spend many hours of work, hacking code that you don’t know to do something that it wasn’t designed to do. There’s also no more support once you go down this path.
Additionally, if you’ve built a site using a speciality (niche) theme, there’s no way in the world you’re ever going to be able to switch over to a different theme. That’s a very strong lock-in. Nevermind the code, but many times your data is not even stored in the standard WordPress tables, making future migration virtually impossible.
Option 2 – Assembling what you need with a mix of plugins
So, you’ve decided to separate between “design” and “functionality”. You’re going to use a simple theme, which mostly takes care of the design and you’re looking to build the functionality with something that’s not part of the theme. Good call.
If you think that there are many WordPress themes to choose from, you should know that there are almost x10 plugins, and that’s just on the WPORG plugins repo.
With over 53000 different plugins at your service, you’re sure to find plugins that will do exactly what you need. If one plugin can’t do it all, you’ll be able to put it together with a set of plugins, working in harmony like an experienced orchestra.
And again, the benefits easily turn into the problem.
53000 plugins means almost as many different authors. So many different authors, try as hard as they will, cannot possibly coordinate their work with so many other authors. Of course, many plugins work great with others, but not all plugins work correctly with all others.
Each plugin is intended for a specific purpose and it usually accomplishes it (at varying degrees of quality). However, when you intend to put together a set of plugins to accomplish one big feature together, you start noticing that they don’t always connect the way you want them to.
Additionally, each new plugin that you use, especially when it comes from a different author, adds another point of failure and dependency to your project. Even if it all works right now, there’s no guarantee that failures and conflicts will never arise in the future. The more authors you depend on, the greater the chance of something going wrong, that’s out of your control (or even your influence).
Option 3 – I’ll just code it all from scratch!
I get it. If I choose a speciality theme, I invite customization problems. If I choose a set of plugins, I get myself in trouble with compatibility, stability and dependencies. I’ll start from scratch and code it myself.
If you’re responsible for the entire code, you definitely know how to customize it. You can add as many features as you need. There’s never going to be a compatibility issue and the developer (you) is always available. So what can go wrong now?
First, it’s expensive. Coding from scratch, even a simple function, is a lot of work. Instead of just installing something “that works” in a few minutes, you’re going to spend days and weeks developing it.
Over time, you’re going to build your own library of reusable code, which will help you speed up new projects. Problem is, code that you wrote today and you absolutely love, you’re going to hate in 2 years. When you’re coding for a client project, there’s no time to debate over best coding practices, conventions and code-level documentation. This means that your own code is not going to be that fun to read and understand, not even right after you deliver the project and certainly not after a couple of years.
Another problem is that sites that you code from scratch tend to turn into fosiles, which is a real business issue. WordPress evolves. Every few months, best practices change. Functions get deprecated and new ones are created in place. This is the only way for WordPress to grow and improve.
Unfortunately, it means that all PHP and JS code that you develop requires maintenance – just to continue doing the same. If you don’t re-test and update your own code between WordPress releases, chances are that one of the WordPress updates will break it. So, you decide to freeze WordPress updates until you “have time” to review the code and update it. Too often, this “have time” never comes and the entire project becomes a fossil. It works, but you can’t update anything. Not WordPress and not other plugins (which start requiring new versions of WordPress).
Then what? A bot finds your outdated site with outdated everything and hacks it. Piece of cake.
So, bottom line, it’s great to code things from scratch, but when you do this, you have to take maintenance into account. You have to price it and you have to keep billing your client for this work. If you don’t, it’s not going to end well.
Which approach should I choose?
So what are you saying? I shouldn’t use a speciality theme, I can’t put together plugins and I can’t code from scratch? Nothing’s going to work?
Of course not. You need to find something that works. Not just list what doesn’t work.
Let’s start with a list of what matters:
- Cost of buying different tools (theme and plugins)
- The development time you need to spend
- External dependencies (things that can go wrong and are outside of your control)
- Stability (the chance of something that works now to break by itself in the future)
- Future cost of maintenance work
Successful developers use a mixture of a good theme, reliable plugins and a bit of their own development to build great websites.
The right mix allows you to achieve your goals without overdoing it in one direction, at the expense of others.
To give you an idea, I’ll talk about a Contractors System, which we created for our own Toolset site.
Toolset Contractors system allows developers to sign-up as contractors. They need to fill out an application form and submit several portfolio site. An admin will review applications, either approve or raise issues. When applications are approved, they appear in a parametric search. Then, visitors can look for contractors and contact them about projects.
Sounds simple? Look at the business-logic behind this process.
When we started this project, we had the same constraints as everyone else would have. We wanted it NOW, we didn’t want to pour a lot of development effort into the project and we wanted something that works.
We ended up implementing our Contractors System using:
- Design from the theme (all the styling went into the theme, in an organized way)
- Most of the functionality from Toolset plugins
- All sort of “contact forms” from Gravity Forms
- SEO meta-data control from Yoast SEO
- Cache from W3TC
- A bit of custom PHP code, which implements the business logic and ties everything together
This table shows the elements that make up the entire contractors system:
|New contractor submission form||Toolset CRED||This form allows users to sign-up as contractors. It creates the Contractor entry in the database.||2 hour|
|Contractor edit form||Toolset CRED||This form allows Contractors to edit their profile||30 minutes|
|Contractors search||Toolset Views||A View that displays the search filter and results||6 hours|
|Contractor template||Toolset Views||The template that displays each individual contractor||12 hours|
|WordPress user custom meta fields||Toolset Types||The fields that will allow the status of the contractor to be automatically monitored and set||30 minutes|
|Contractor Custom post type||Toolset Types||The custom post type for the application and Contractor profile information||5 minutes|
|Contractor custom fields||Toolset Types||An array of custom fields that allows gathering information about the contractor and adds to his profile page||1 hour|
|Custom taxonomies for countries, languages and WordPress themes||Toolset Types||These taxonomies associated to each Contractor entry allow to add filtering elements and catalog Contractors.||6 hours|
|Contractors management||Toolset Views||A page that displays all Contractors submissions and their showcase entries for a review||4 hours|
|Custom PHP||Glue code that uses CRED hooks to implement our business logic.||3 days|
As a result, we’ve built a fully-featured Web app, in under two weeks by two people. One person did everything inside WordPress and the other person implemented the custom PHP code. Doing it in PHP from scratch would have taken at least 6 months. Doing it using plugins only would have required serious hacks and compromises. Mixing between plugins and custom code allows us to implement 95% of the functionality with existing and well-maintained plugins and focus our custom-coding efforts on the remaining 5%.
When you’re developing a custom site, there’s almost always some business logic. That’s the logic that determines the workflow and controls what happens. Like each business is unique, the business logic of every site is unique. Trying to build a plugin that would cover all possible workflows by all websites is impossible. It’s going to be a huge plugin which still does almost everything that you need. Almost.
Our custom code still suffers from the inherent problems that I wrote about. We have to scan it before every new WordPress release and make sure that it doesn’t include any now-deprecated calls. We need to run testing on the entire site when we update WordPress, the theme or any plugin. There’s no way to avoid it.
The good news is that when you build 95% of the site with proven code and you’re responsible for only 5% of the business-logic code, this work is manageable.
Tell us how you develop custom sites
We develop Toolset plugins, so obviously that’s going to be our go-to platform. Toolset showcase includes hundreds of client sites that are using the same workflow successfully.
Of course, there are other workflows that let you build advanced sites and stay with a profit.
Leave your comments and tell us what you’re using!