This blog is part II in the series, regarding inheriting legacy Wordpress
websites. In the first blog post I covered questions to ask when inheriting a Wordpress installation. If you have not seen this post already, you can read it here.
This blog post assumes you have already asked all the relevant questions, have decided to take the project on and are now looking to start work on your legacy Wordpress installation.
However before starting any new work, You should evaluate the current situation thoroughly. These are the steps I take at the outset of an Inherited Wordpress project.
If you are following this series, you will have already asked a lot of
questions. The first thing to do is to write up an overview of the answers and store it somewhere safe.
You should also store the original answers to the questions you asked: straight from the clients mouth.
If any part of the installation or plugin requires a licence, or there is any other relevant information what-so-ever you should document and store it here too.
At this stage, we get everything setup and ready for us to begin coding.
Get into version control
If not already under version control, get it under version control and make an initial commit in the state you receive the code.
If you are not currently using version control, you should consider adopting it. See Version Control, What It Is, Why It Matters.
If you can not be convinced to adopt version control, then instead make a backup of the original code received from the client and store it along with the documentation.
Get it setup in your local environment
Get the website set up and working locally, don't forget to disable any 'cache' plugins which can confuse this process.
Test, Test, Test
You need to set aside a good chunk of time for testing the code base you
are inheriting. Your target is to discover any bugs or problems the website has at this stage so that you can distinguish between pre-existing bugs and bugs caused by your team.
The more time you invest at this juncture, the more you will save later in the project. So throw everything you have at testing the site. Test it on as many devices and browsers as possible: give it everything you have got. Essentially, do your best to break the site.
Before moving forward with any new work, present these existing bugs to the client.
Not many moons ago mobile detection was a common thing. Although the web is now moving away from it, a lot of older websites still have mobile detection libraries in place.
Take a look at any mobile detection libraries and if new tech is available to replace it, do so accordingly.
Secure The Installation
If no security best practises are implemented, I would strongly recommend installing and enabling the following plugin: iThemes Security.
This plugin takes car of basic security and will thwart bots trawling the net looking for potential website to hacks. iThemes Security has a lot of options, the more you enable, the better.
In Addition to this
- remove any old users from the database.
- Force password updates on all remaining users
- change the hashes and salts
- remove unused plugins
- removed unused themes
For those comfortable with the command line. After making these amends, it is worth running WPScan which is a popular hacking tool. At the time of writing, iThemes Security will thwart WPScan just by being installed.
Every plugin installed on a Wordpress installation will slow the website down a little. They also represent a security risk - especially when the plugins are third party.
Trash any plugins that are not essential
Take a look at the plugins in use and work out what exactly they do.
While you can't do away with all plugins (some are handy), you should consider all third-party plugins a security risk until you have picked apart the code and thoroughly evaluated what they are being used for and why.
If they are being used to plug holes in knowledge, can they be done away with? For example, I regularly see plugins used to
- Register a post type
- Register a sidebar
- Add a custom field
All things which are extremely easy to do programmatically and will be notably faster than a third party plugin.
For the essential plugins come up with a backup plan of what you will do if that plugin were to fail.
Introduce A Task Runner
If a task runner such as Grunt or Gulp can be introduced without smashing everything, then do so.
At this point, you need to inform the client of any surprises that have popped up in this process and if appropriate, amend the quote accordingly.
Plan to commence work
By now you should have a pretty good feel for this Wordpress installation, its build quality and some of the intricacies that surround it. The Next staging is to plan your modifications with a thorough functional and / or technical specification.