Last Updated on January 19, 2020 by Christopher G Mendla
Imagine trying to unscramble eggs and put them back in an intact shell. If you think you can accomplish that, then skip this article. Otherwise, read on for some tips as to how a developer can leave you with an expensive mess.
I’ve seen this scenario several times. A business owner hires a developer to build a site. After a year or two, they have problems and the site never seems to get to completion. They hire another developer to take over. There have been a number of times when I’ve been the developer taking over a site. Most of these have been Joomla sites. The owner is frustrated with the inability to get the site exactly the way they want it.
When I start diving into the site, I find out that the original developer made a huge mistake that will make the site vulnerable to attack and difficult if not impossible to maintain, change or upgrade.
Let’s drop back a bit and look behind the scenes of Joomla and WordPress sites. In both cases, the code that is used to build WordPress or Joomla is “Open Source”. That means that the source code is available and in both cases, there is no charge for the platform.
However, neither Joomla nor WordPress can build a useful website out of the box. You need to add Plugins or extensions to enhance the capabilities of the site to make it a serious, useful site. For example, if you wanted to show rental vehicles, you would look for plugins or extensions that provide the ability to show and manage the rental of vehicles on your site. The developer could write their own code but in most cases, the cost would be prohibitive. The plugins and extensions are usually reasonably priced.
What happens is that the site owner often wants modifications in terms of layout or functionality. This is where the problem starts to come in. Many of the more sophisticated plugins and extensions are commercial products.
Suppose the business owner decides that he won’t rent trailers to people who are driving Ford Explorers. (if you know what I’m referencing here, leave a comment !) The business owner asks the web designer to not complete a rental if the person is renting a trailer to be towed with a Ford Explorer. Let’s further assume that the plugin has no capability in their control panel to facilitate this requirement.
What all too often happens is that the web designer says “OK”. They think about it a bit and then decide to modify the php code of the plugin. In some cases, they will outsource the actual writing of the code overseas. After a couple of weeks, the web developer calls the site owner and says “Great News. The system will now refuse to rent trailer to people towing with a Ford Explorer”. The site owner is happy.
What we have at this point is something like the following:
- WordPress Version 4.0 released Jan 2017
- The Super Duper Rental Plugin – Version 2.5, Released December 2016
Great, everything is working the way the site owner wants.
However, if you look at the scenario above, you see version numbers. Applications such as WordPress and Joomla are constantly updated for functionality and to address security concerns. When a new WordPress site is launched, hackers are usually attacking it within six hours. They are probing for vulnerabilities that will allow them to use YOUR server for whatever they want.
Suppose it is now February 2018. The site owner has become frustrated with the original developer who hacked/modified the plugin. Changes to the site are taking forever.
What happened? It is not unusual for a plugin to have a release every month or two. Some of these updates are for functionality and some are for security. At this point we might find that there have been 5 releases for WordPress since the site was built and 8 releases for the Rental plugin.
If you upgrade WordPress to the latest version, you run a risk that the new version will not be compatible with the old version of the plugin. If a new developer updates the plugin, the site owner suddenly finds that all of the customization they wanted is gone. When you update a plugin, the files for the plugin were overwritten.
My experience with modified code is that the changes are spread over dozens of files and hundreds of lines of code. If the original developer changed the structure of the database tables, that makes the problem much worse. If you leave the old version of WordPress and the plugin on your site, sooner or later the site will break. This could be due to the hosting company upgrading PHP or the database manager. It is not a matter of if it will happen, it is a matter of when. The other danger is that running old plugins with security flaws will sooner or later lead to a hacker getting lucky. The site owner will wake one morning and find that the site has become a marketplace for Viagra, a repository for stolen credit card information or that all user’s personally identifiable information has been stolen.
Prevention
A good developer can prevent this by:
- Understanding that plugin code should not be modified.
- IF there is absolutely no choice, then the code should be modular where one or two lines in the plugin are modified to call functions in another file. That way, updates for the plugins will be more manageable. Again, this is a Last Resort.
- The developer should make the risks clear to the site owner if the features require modifying the plugin code.
- In some cases, if the plugin is open source, the developer can submit their modifications to the publisher and they might be integrated into the next release of the plugin. This approach will probably cause a significant delay in making the changes.
The site owner can protect themselves by:
- Minimizing customization to the absolute minimum.
- Writing the contract to stipulate that
- There be no modification to the code without the owner’s approval.
- If there is a modification, the code changes must be thoroughly documented.