WordPress admin login vs. server access

When we help clients update or assess their WordPress websites a surprising number of them give us their admin privileges. They often expect that we can update or manage their website with that information.

domain.com/admin is a login web page example.

When you type in a username and password there, it lets you use WordPress.

Most Content management systems work like this. You have a website address and then a login area to manage the website content. Some of these will let you update the site using that interface.

That is not the file access level you need to safely back up the website’s files.

If you click on an upgrade button and it breaks the website, you can’t fix it from the website.

You can’t use the website to repair the website if the website is broken.

A WordPress website has files and a database.

The files are scripts that run the website.

The database is a set of data in the server that stores dynamic information.

So, things like pictures: that’s files.

Logos, button images, style sheets, HTML to make things look and feel like your brand. All of that would be files.

Things like how much an item costs. That’s information stored in the database.

Most of the data you update, like blog posts, would be dynamic data stored in the database.

In order to backup and restore a website you need a copy of both.

The files.

And, the database.

If you’re running a business, systems administration probably isn’t one of your core skills. Nobody expects you to be a coder, hacker, or sys admin.

That’s where we come in!

However, you do need to know the difference.

One set of information is the username and password you use to log in and make changes to your website. The other is the credentials to manage your hosting account.

For a lot of common hosting services, you may have a panel account like cPanel. That has a URL (web address), username, and a password. Once logged in, you can add FTP accounts and mange databases.

Most hosting accounts have an account login that you use to access things like billing, payment history, domains purchased, and other hosting account information.

You almost always access this information and make changes through some kind of web based system. Usually, that will mean you have a URL, username, and password to access those account details.

Maybe your web host also registers domains and perhaps they manage name services that point your domain name to a server through an IP number.

GoDaddy is a very common web host.

They sell domains, email services, DNS (domain name services) attached to those domains, and hosting. Their hosting comes in shared hosting accounts, where you have an address or IP number with a username and a password. But, you can also buy a dedicated virtual server or a dedicated server. Those usually have panels that allow you to manage the services at the server level.

The server itself has an access protocol.

That’s where your files and maybe even your database are stored.

Maybe it’s SSH, SFTP, or FTP. With a root account on SSH or a shell account, you can do pretty much anything quickly. With some web based systems things can be painfully slow and even unintentionally obfuscated.

Typically, the more a system is designed for a less technical user the more difficult it is for an administrator to perform server level duties.

On AWS (Amazon Web Services), for example, you would have an Amazon account and you can assign AIM account to handle administrative duties.

The Amazon account would handle billing, service purchases, even server configurations. You can access keys to log into the instances (virtual servers) as a root user. And, you can assign an AIM account to someone that allows them to perform administrative services you want them to perform on a granular level.

In other words, you can pick and choose what they can see and do.

Unfortunately, AIM management is not for the novice.

Once someone has an access key to a server, they can execute any command they wish on that virtual server. In the right hands, this is a powerful tool.

FTP and SFTP limit the user to uploading and downloading files, and then only the files they were granted permission to change or see. FTP and SFTP credentials don’t give the user database access. However, an administrator can upload a tool that lets them manipulate a database if the credentials to the database are stored somewhere in the website’s files.

Most CMS (Content Management System) store dynamic information in a database, use active script files to perform tasks, and have site assets in web enabled folders in that file system.

There are WordPress specific hosting services that are less vanilla and specifically geared to the WordPress site owner. WP Engine is one of these.

WP Engine allows someone to run a scalable WordPress website and handles most of the heavy lifting on the backend. All you need to do is log in and run your changes in Staging, then push to the live environment to make them live on your real website.

Things like backups and restorations are done with a few clicks.

The disadvantage to this is most of the low level work a system hacker would want to perform is at a level locked out for the WP Engine user. It’s really intended to run WordPress the way most WordPress websites work. But, it can help you avoid a lot of headaches and even expenses if you’re primary goal is to run a vanilla WordPress website.

If you’re handing off upgrades to a developer, they will need account level access to use the backup, restore, and staging services properly.