WPSandbox Cat Dog with Glasses Code Vs Plugins

Custom Code vs. WordPress Plugins: Which Is Better?

Do you need a temp WordPress site? Test it now!

Sharing is caring!

Choosing between writing custom code or using existing WordPress plugins is a common dilemma for developers. Both options have their advantages and drawbacks, and the best choice often depends on the specific needs of the project. In this article, we’ll explore the pros and cons of each approach and offer guidance on making the right decision for your site or your client's site.

Is it better to use or write custom code instead of using an existing WordPress plugin?

Sometimes plugins and themes come with lots of functionality that is supposed to cover various cases that your site or client's site may not necessary need.

Custom Code = Higher Efficiency (Usually)

The code you write is specialized to solve exactly the problem that your client is facing and because of that it's usually efficient. You have to know php in order to evaluate and write the code efficiently.

Plugin are made to solve a set of problems. The trend is usually to add as many features as possible and almost never to remove features. Having a plugin that provides lots features will definitely slow things down and if you have 20-50 plugins that problem will become worse over time.

For example in our plugins (under the Orbisius brand which is the parent company of WPSandbox) we have simple checks before doing the complex checks and this improves the performance. There's no point of calling an resource consuming function when there's no need for it.

For example before doing a regular expression check e.g. !/users/(\w+)!si we check if the text even contains /users/.
Another example if we have a function that is supposed to check a buffer if it's a html_string or a binary file. Let's say that the file size can range from 5KB to 5MB. We could take the first 20 characters of the buffer and check for common starting bytes for know file types such as zip, rar, 7z, images, PDF etc. if it's a binary we return right away and let the other code handle this type of content. Next, we do another check but we take a small buffer e.g. 32kb and then search for common HTML tags and as soon we find them we return html_buffer as a result.

Custom code vs. Existing Plugins

Several years ago we had a client that was using a really nice newsletter plugin. He has a SaaS app and wanted to let his customers compose emails from within WordPress. The plugin's user interface was good, flexible and full of features. It also created between 10-12 extra database tables. It may not sound too bad but my client had a WordPress Multisite setup. Each subsite in a WordPress Multisite set up is duplicating all tables and this started accumulating over time. So every new site had those extra db tables. We didn't catch this on time to advice him about the technical issues.

Another reason to use custom code is some (old) plugins in the official plugin repository may collect user data without asking the user permission or may be abandoned at any time.

Another bad habit that plugin authors have is to start adding all kinds of stupid stuff in the WordPress notifications (admin_notices hook)... basically spam or put promotional offers. It may be relatively ok if only the developer/designer sees this but when the site is in your client's hands it's not ok for the clients to keep seeing different upsells as this ruins the user experience.

When write custom code follow these simple rules

  • if it's related to the currently installed theme -> then add it to the functions.php file.
    Hopefully you have created a child theme otherwise your changes will be lost after an update to the (main) theme. If you are not using a child theme then it's better to use a custom plugin for your code snippets and custom code.
  • Custom code in a plugin. It's better to use a custom plugin then to use another plugin that will store php code.
    You can use our Simple WordPress Plugin Generator to package your snippet(s) into a plugin that you can install.

Have you ever checked the code of the plugins you use pretty often? Most of the time the functionality that you need can take between 5-20 lines of code and the rest of the plugin's code doesn't serve you in any way. Sometimes plugin authors use hooks (via closures) in a way that are hard to unhook. Some plugins may check for licenses validity very often and that slows things down as well.

Anther good reason not to use a bloated theme or plugins is security. The more code you have running and handling your site's functionality the higher the chance of some security issues to happen just because of that especially if you are using a plugin that hasn't been updated in a long time or is poorly maintained.

You should strive for to have as fewer installed plugins as possible and that should improve the performance and security of your and client sites.

Sometimes you and your clients have a choice - use a fully featured and bloated WordPress theme or start with a minimalistic or custom one from scratch. It really depends on the project but sometimes it's way better to start with a custom or minimalistic theme and create a child theme to apply your customizations to.

By the way it's important to put your code into git so you know what's the latest version. You can have it under your account or under client's (github/bitbucket) account.

Generally when you write code it's very important to write lots of comments and especially why and what you're trying to achieve with the code. For example this may be the output of a hook that you had to run.

// We're outputting some custom CSS so we don't have to load yet another CSS files.
<?php echo "<style>.my_custom_class { color: green; } </style>";

When you write something make sure you've taking a bit of time to plan things.

For example:

Use site unique/specific prefixes for function/method/class names, js functions, css IDs and classes. You're a professional WordPress freelancer, so you can't just name functions like get_results() or get_news(); It's way better to have

ClientName_CustomPlugin1::getNews();
or
client_name_custom_plugin1_get_news();

The Drawbacks of Writing Custom Code

The main drawback of the custom code that you wrote is that you have to maintain it over time. You will have to communicate that with the client so they don't say oh, we've already paid for this and you want more money from us?

Let's say you created an awesome shortcode that pulls the latest news feeds from external sites and there's a bug in it. Unless you have developed a custom updater for the custom plugin you'll most likely have to go in each site and update the plugin manually.

Another thing is integrating with a Payment Gateway or creating a WordPress plugin to handle subscriptions. Do you really want to build this? Probably yes but because you can, it doesn't mean that you should. Because it will most likely take more time and resources to build this. Do you have a team that can tackle all the challenges that may arise?

After doing some evaluations you need to make a conscious decision whether to write custom plugin, code and sometimes, indeed, the right thing to do is to build the plugin yourself because you control what and when gets implemented and fixed.

If there's an official and well supported plugin you'll need more information and reasons to evaluate if building something yourself is the right path.

For example a New Payment Gateway plugin for a known given Payment Processor or a Subscription plugin are big projects and better suited for large teams which are going to maintain the code over time. If the official plugin is well written, maintained and extendable via hooks (WordPress' actions and filters) it's better to build on top of the plugin rather than developing your own.

If the official plugin doesn't have the hooks that you need, you can always how to submit suggestions or features requests. Usually, plugins are on github and you can submit a ticket about a feature or if you have a fix a pull request. That way you'll help improve the plugin for others as well. While you're waiting you can patch the plugin temporarily patch the code with the hooks that you need. You have to add that to project's notes so you and your client remember this.

There has to be a nice balance whether to write custom code and use an existing WordPress plugin to achieve your goals because you can't possibly have the time or client budget to build everything from scratch and also if relying on existing plugins the site will end up with 50-100 plugins easily.

if it's your site is a SaaS product and you've been in business for several years you know exactly what your customers need and also what areas of the site are less performant you can have everything custom made.

Sharing is caring!

Do you need a temp WordPress site? Test it now!
This code shared in this post/site is provided "AS IS" without any warranties or guarantees of any kind. The authors and distributors of this code cannot be held responsible for any damage, data loss, or other issues that may arise from its use. It is strongly recommended that you test this code in a staging environment before deploying it to a live site. Always ensure you have proper backups and understand the implications of running this code on your WordPress installation. Use at your own risk.

Leave a Comment

Your email address will not be published. Required fields are marked *

The new new server is up and running. Enjoy!