Looking to do your first WordPress build within a project management system? Or are you looking to improve your current workflow? While this CMS continues to be the most popular on the web, it has its own inherent risks that you should be aware of when it comes to project management.
Let’s take a look at 2 risks that come with every WordPress build, and how you can account for them in your own processes:
Updates Throughout Your WordPress Build
If you already work with WordPress, you already know how frequently updates become available. Besides WordPress core itself, any number of plugins publish new versions and patches on a recurring basis. Depending on how many plugins you rely on, and which you use, this can add up to a dozen updates each month.
When you factor that into your development time, which may be anywhere from 1 to 3 months (shorter or longer depending on the exact project), that becomes a lot of updates. For many of these, the update will go completely as planned and have no negative effects on your project.
For some though, the updates will change a core functionality you were relying on, remove a feature that you client was expecting, or cause larger-scale failures for you build.
With some planning, you can avoid this.
How to Handle Updates During a WordPress Build
The exact fixes to each issue will be unique, but here’s some questions that will help keep everything on track, and more importantly, keep things clear between you and your client:
- Will you be supporting updates to plugins (and potentially themes or WordPress itself) beyond the initial build?
- How do you define the initial build? Is it when plugins are first added, or when the site launches?
- If you choose to support updates during development, will you update them on a regular basis throughout, or deal with the fallout at the end?
- What is your process for updating plugins? For more important plugins, it might be critical for your team to read the update notes, and make the choice on a case-by-case basis
While some issues will still inevitably slip through the cracks, defining the answers to these questions will go a long way to keeping your project on track.
If a plugin is mission critical though, let’s check out why you might want to consider implementing it as custom code.
Plugins or Custom Code?
When it comes to core functionality, should you utilize plugins, or replicate the features as custom code?
Each individual’s answer will be different, and it might even swap from project to project (or even feature to feature). When making the choice, be aware of these risks and benefits of each solution:
Relying On A Plugin
If your project contains a core feature that can be handled by a plugin, should you do it? A great example is a website that lists events. There are quite a few plugins out there that can handle this, but what effects will it have on your project?
First, let’s look at the benefits. Plugins are often much easier to implement, provide functions to access the features you need, handle their own updates, and start off a bit easier to use for the end user. This makes them great for many of the supplementary features of your site, but when they’re carrying out critical functions, they carry some hefty downsides.
While they are easier to add into a project, they may be more “bloated” than necessary for your needs, potentially adding excess code. They may also be difficult to extend if the need arises.
Finally, their independent updates are a double-edged sword. While they do perform their own updates, creating less code for your team to upkeep, there are some disastrous potentials, including updates adding security gaps, updates that break core functionality of the project, or a plugin that becomes deprecated.
Planning now for these issues can save you headaches down the line.
Creating Custom Functionality
In most cases, custom additions to a WordPress site offer the opposite benefits and downsides of adding in a plugin.
When adding a custom feature, it can be more easily extended to contain the needed features, will have less extraneous code, the functionality can be easier to use (given enough development time) and in many cases, may be considered more stable.
On the other hand, you’ll need to maintain the code itself, spend development time creating the functionality, and potentially some design time to make it easy for your clients to use.
Regardless of which option you choose for your situations, just remember to be aware of their downsides as well as their upsides when planning.
What Else Should WordPress Project Managers Be Aware Of?
These are far from the only risks and benefits associated with WordPress projects. What are some that you’ve run into? Comment below, and we’ll do our best to include them in future articles!