Following on from discussions on using WordPress for Static Sites, what if you have “dynamic” sites that live in glorious isolation?
Over the last couple of months I have been experimenting with removing administrator accounts from WordPress sites all together. Not accounts named Administrator or admin but any account with the admin role, with Editor being the most common default role for ‘my’ user.
Why go Admin Free?
By default the account I use to add, edit posts and do 90% of tasks on a site is my personal user account, normally an editor. In addition I then have a second personal account with administrator role associated with it. This role I use to add plugins, check settings and update WordPress as needs be. To help distinguish the two accounts, I set Administrator accounts to have the sunrise Admin Colour scheme.
While it’s extra faff, having two accounts means I have a far greater audit trail, and it means activity related to writing content and running the site is kept separate from “administering the site”. It’s not a necessary step but one I take on sites which I both write for and administer as a matter of course.
The thing is, on most sites I never log as an admin user once they are set up and running. I either update the site via version control or use WP-CLI to manage adding and activating plugins etc. The only time I really need an admin role user is to change a setting on a specific plugin, or to enable or disable something.
For the rest of the time, the admin role user is superfluous and not needed, so it just sits there gathering dust. It’s also a weak link in the chain security wise, as a compromised Editor user account can result it some unpleasantness but assuming you have locked down file editing and made sure things that shouldn’t be executed can’t be from the uploads folder, the amount of harm is relatively limited*.
An admin account on the other hand can cause substantially more harm in the short term. Sure, in both cases restoring to a backup will normally resolve the problem, but I, like most people tend to take extra security precautions on admin role accounts, including but not limited to two factor authentication, IP checks and some obfuscation. The result is the need to jump through a couple of extra hoops to log-in as an admin.
WP-CLI and Automation
So let’s just delete them! Admin role users that is – we can always re-add them later if we need an admin role for something. Of course if we delete the Admin users we won’t actually have a way to add new users, at least not from the admin interface. However we can do via the command line with WP-CLI.
One of the reasons I feel you can get rid of the admin role users on some production sites is because of WP-CLI, which allows you to do most “admin” tasks via the command line including adding users, updating plugins, adding and activating new ones, managing WordPress core. You can even add posts, manipulate WordPress options and do database backups from the command line. Plugins can also supply their own commands to extend WP-CLI to allow you to interact with them.
One of the big features for me with WP-CLI is the fact you can automate a lot of the tasks to bash scripts or any scripting language. This means you can keep plugins up to date and the core without needing to even touch the site. It also means if you do need to perform an admin role function chances are you can do so from the command line.
We can even automate the testing of the sites afterwards with Acceptance testing solutions like Codeception to make sure all the changes made haven’t effected core functionality. Interaction with the site could simply be limited to when a notification something has gone wrong occurs, or as a backup the dead man ping, for if the site totally fails.
Where it all falls down
So what are the issues with not having WordPress admin role users?
Well first and foremost no one is expecting that, especially plugin developers. While WordPress core updates run smoothly these days, the db update can be initiated by anyone not just an admin and doesn’t normally require any checking of settings. The same can’t be said for the average plugin, and as users we have trained ourselves to expect a plugin update to require us to go through its settings to make sure they haven’t been wiped, to configure the new options and jump through any migration hoops with the database. This nearly always needs to be done by the admin user or at least someone with manage options capability. A very small selection of plugins provide their own capabilities for you to add to user, to give them the ability to manage that plugins options, and a few even provide a mechanism to manage them through the WP-CLI.
This means each time you update a plugin it’s possible that you will need an admin role user. Likewise while it’s perfectly possibly to install and activate plugins via the command line, if they have options setting them up you will need an admin role user to log in to use the interface.
Depending on your setup this is going to be the main pain point, and what I have found on small sites that are just sitting there is that this hasn’t proven to be to much of a problem. When I have needed to log in as an admin role user, I just create an account, login and then delete it afterwards, which takes about the same amount of time as finding my phone to login into the two factor auth app, or finding my Ubikey, plugging it in and waiting for my machine to realise yes it’s the same device as last time.
That said, this pain is limited, because the sites where I have experimented have few admin requirements having been set up, and so all the admin aspects are routine maintenance. During development and early life cycle of a site it would be impractical to run without an Admin role user.
Likewise sites under constant development (which you could argue should be always the case) will also find they are constantly creating and deleting admin users.
Adding new users
The second pain point is adding users. Normally I recommend when working on client sites that the day to day person in charge of running the site who isn’t a developer/sysadmin is set up as an Editor, but with extra permission associated to add users. You need to do some fiddling to make sure they can’t accidentally create admin role users, but once this is set up it means that you can delegate the ability to add users away from a admin role user. I tend to do this anyway as chances are a very small number of people will have admin privileges and nearly always these people will not be in charge to day to day management of people on the site.
Removing admin interface
Of course the question then is why should we have users or the admin interface at all? It is as feasible to run a site without the WordPress admin interface entirely. You can delete the admin interface and WordPress still functions (I really wouldn’t recommend it!) …but can you do away with its usage day to day?
Getting content into WordPress is now incredibly easy, either through the admin interface, the old XML-RPC API, the new REST API and through WP-CLI as well as dozens of other options and plenty of tools for pushing content into your site (mainly using the old XML-RPC API).
I’ve talked in the past about developer friendly workflows using Markdown and things like SublPress where you write posts in an external editor (in SublePress that would be sublime editor) and then push the content to WordPress and either automatically publish or then login and publish.
In theory these workflows can be used as norm, avoiding the need for ever going into the admin area, as a admin or as a user. We can do this! Should we do this? In my mind not really – the WordPress admin area is actually a quite nice editing environment and while I write my content separately from WordPress and import it in (I use Mou for most of my editing) I still look at it, upload images and manage metadata from within the WordPress editor.
Adminless WordPress – could it be the future?
So what does this all mean, other than that WordPress is flexible. Well, if you are a plugin developer it’s worth bearing in mind that many sites today sit unloved and unmanaged or are remotely managed, be it through a third party service like ManageWP, WPRemote etc or left totally automated with occasional WP-CLI script running. If you write a plugin could it survive an update in such an environment? As more power users start to embrace WP-API and WP-CLI is your plugin ready and capable of being used without having to routinely come to your settings page? Finally do you make use of existing WordPress roles or are you creating your own capabilities to allow non admins control?
For WordPress itself, do we need an admin interface at all? Will we see it become detached and turned into a default plugin much like Akismet or Hello Dolly which can be replaced or just removed? Probably not, but wouldn’t it be great if we could?
The concept of small unattended WordPress sites running without a WordPress admin user is an incredibly appealing one for me, and from my little experiments it’s certainly possible to do but with compromises. However, with some small mindset changes within plugin developers, this will become more feasible over time.
*The moment you install a single badly coded plugin that line becomes totally untrue.