Acquiring Administrator Access

At White Heat Design, we manage our websites as (usually) the sole Administrator user role of the websites. We do this to as part of our hosting and maintenance agreements in order to:

  1. minimise risk
  2. ensure high performance
  3. relieve our clients of the burden of technical decision making
  4. deliver our contracted services

However, we understand that from time to time clients wish for greater control than other user roles will allow them.

Assuming the Administrator role on a WordPress-driven website brings with it a plethora of risk and responsibilities, and it is important to understand the full scope of these before taking on the role.

These include but are not limited to:

Managing WordPress Updates

WordPress is an open source platform and therefore continually evolving. Updates are released periodically, usually on a ~4 month rolling cycle, and in most case should be applied in a timely manner, dependent on the type of update. Security patches (usually in the form of a “point release”) should be applied immediately, but full version releases carry a higher potential of breaking and changing the way a website and/or theme functions. These should be considered more cautiously, with database and file backups made before the update is applied.

Managing Plugin Updates

Plugins are the behind the core functionality of most WordPress websites. They are often made by third parties, some for free, some for commercial gain. Because of the open nature of plugin development, there is no one size fits all blueprint for how a plugin must be made. As such, their update cycle and the quality of the release can be unpredictable. In most cases updates should be fine to run, though if they adversely affect the performance or behaviour of the website they will need to be removed. Always read the changelog of a plugin before running the update in case there is mention of breaking changes. Developers will/should make note of these.

If your website has been built by WHD, then it will most likely already include all of the necessary plugins required to operate the website. Plugins should be deeply researched and meet a range of criteria before being installed and activated. To pass this criteria, a plugin should:

  • Be developed by a reputable, experienced developer. Check their profile to see what else they have developed.
  • Be regularly maintained by said developer. If a plugin has not been updated with the last 3 full version releases of WordPress it should be considered a candidate to be removed or replaced.
  • Be installed on as many active applications of WordPress as possible. Higher numbers means more data, means more feedback, means higher likelihood of active development.
  • Have primarily positive reviews in the WordPress plugin repository. This is a fairly subjective point, but if in doubt read the reviews – both positive and negative. Look for red flags and categorical reasons why the plugin should not be installed.
  • Be tested up to the latest version of WordPress. Not all plugins will work with all versions of WordPress.
  • Work with the website’s current version of PHP (minimum 7.1). This is not highly visible information and will change periodically – if in doubt, contact the team at WHD.
  • Offer a maintained development changelog.
We do not endorse the widespread “trial-and-error” nature of plugin installation. This is a surefire way to bloat the database of the website, slow it down and introduce potential security issues. This is not the wild west, this is a business asset and it should be treated as such. 

Managing User Access

The Administrator use role is responsible for the delegation of roles to other users of the website. In practice, there should only ever be one Administrator. Where there are multiple, it becomes difficult to keep track of who has made changes, when and to what. Delegating access to other people or agencies should be done under extreme caution, only when there is a good level of trust, and in the knowledge that you are essentially handing out the keys to your house.

If any information contained on your website (front or back end) is sensitive and should only be viewed by specific people, ensure you are not delegating access that accidentally unearths it.

Be mindful of what permissions each user role has and always consider worst case scenarios – what damage could a user with that role potentially do?

Strong Passwords

Weak passwords are a global pandemic. Passwords are your last line of defence against attackers, so should be as strong as they can possibly be. A weak password is akin to  having no password, and this is often the first thing hackers will attempt to crack. If a person or bot is able to acquire access to a website with an account that has the Administrator user role, they have free reign to do as they please.

As an Administrator, if you create other new Administrators (something we strongly advise against) and set passwords for them they must be strong – using a minimum 16 characters made up of lowercase, uppercase, special characters and numbers. It goes without saying, your own password must also follow this rule.

Tips on creating strong passwords can be found here. We strongly advocate the use of independent password managers (not ones built into browsers). Options include Dashlane, LastPass (our preferred tool), 1Password and Bitwarden.

Managing Security Plugin Configurations

There are many security plugins in the WordPress repository and they offer differing types of protection for WordPress websites. Over the years, we have tested many of them and whittled these down to the the ones offering the most protection for sites on our platform, with as little disruption as possible to either website visitors or administrators of the website. Our chosen plugins and configurations take into account the most common forms of attack, our current hosting environment, software versions installed on our servers and many other factors.

We advise not to touch security settings unless you are confident in doing so. 

Managing Caching Settings

Caching is a technique designed to speed up websites. There are different methods of caching that all fall under two broad areas: client-side and server-side and these encapsulate different types of caching, including page caching, database caching, object-based caching and opcode caching.

We fine tune each website depending on the website’s function, it’s level of traffic and other factors.

We advise not to touch caching settings unless you are confident in doing so.

Managing Theme Options

Your website theme may include an options panel that allows you to make adjustments to the design and functionality of the website. While it may be tempting to play around with these, it is important to be aware of the consequences of doing so. Options panels are great for quickly making widespread changes across a website, but every change should be fully tested so as not to cause undue issues in the design or function of the website. During development of a website, developers often make customisations specific to the client’s requirements. Adjusting theme options can nullify, erase or alter these customisations to the detriment of the website.



Restoring hacked, broken or unintentionally altered websites is time consuming, laborious and expensive work. Not to mention the cost to the business whose website may have been defaced, erased, redirected or simply broken.

By agreeing to assume the role of “Administrator” you indicate that you:

  • have read and understood all of the above
  • will ensure your password meets the expected criteria outlined above
  • are solely responsible for any errors, security breaches, or unintended consequences resulting from changes you have made, intentional or otherwise
  • expect to be charged if the above requires that a developer must fix, alter or recreate any and all parts of the website that have been damaged, removed or otherwise adjusted