No. Nada. Nah. Nope. That’s a negative. Under no circumstances. My mama didn’t raise no fool. Heck naw. Not on your life. And, the other thousands of ways to tell anyone asking for site credentials to bugger off, even plugin support staff of a “trusted” WordPress development company.
That is my way of saying that I do not trust anyone. Neither should you. However, there are cases where it is necessary to provide admin permissions to a plugin’s support staff.
Today’s installment of the Ask the Bartender series comes courtesy of a reader named Niko. Because the entire text is over 1,000 words, I will simply link to the transcript via a .txt file for those who want to read it in full. Here in the post, I will stick to the vital bits. Or at least the parts that I want to address.
One of Niko’s Facebook group members kicked the discussion off.
‘Is it okay to send FTP details for a plugin developer to troubleshoot the issue we are having with WooCommerce. We have already provided WordPress Admin credentials.’
This is pretty normal practice in the WordPress world, right? Plugin developers helping out on issues, and if they can’t replicate an issue, they need the access so they can check if it is a plugin issue or a server issue and fix things?
Over the years, I have seen this become more of a common practice. However, it is not a practice that I recommend from either the user or developer end. Any site owner should ask whether they trust the person to whom they are giving credentials. If the answer to that question is no, you have the answer to the first question.
In over a decade of running a theme and plugin shop, I never needed admin or FTP access to deal with a support question. It did not matter if it was a large and complex plugin or a small one. Because I was the sole person at the company, I also personally answered hundreds of thousands of support questions over the years. Still, not once did I log into a user’s site to help them. That always seemed like a liability issue for me, but I also used such scenarios as teaching moments about trust and security.
Users sometimes provided credentials to me without me asking. Often they posted them in plain text in forums, email, or Slack (also, you should never do that). If on-site code needed changing, my users performed the task themselves or installed a bug-free version of the theme/plugin I handed over.
If they did not know how to perform a task via the admin, FTP, or otherwise, I took the time to teach them. Yes, that required more energy on both ends, but I believe we were the better for it. More than once, those moments led some users down the path of becoming developers themselves, or it was at least a tiny stepping stone for them. I remain friends with many of them today and am proud that they started with my little solo WordPress shop.
Some cases were rougher than others. Many times, I would replicate their setup (plugins, theme, etc.) on my machine. The majority of the time, this led me to the solution — I was using
__doing_it_wrong() long before WordPress introduced the idea. In the long run, I was able to pass countless bug fixes upstream to other developers. I made a lot of developer friends this way too.
I have no doubts that the road I traveled was the longer of the two. There were times when I spent an hour, two, or even more addressing one user’s needs. Popping into some of their WordPress admins would have been a quicker course.
However, my theme and plugin users never needed to worry about whether they trusted me enough to provide that level of access. Plus, I had no chance of accidentally breaking their site by making custom changes.
Are there times when a plugin’s support staff really needs access? Probably.
The original question was regarding WooCommerce. It is one of the most technically advanced plugins in existence for WordPress. Replicating a user’s setup off-site for it is trickier than most others. There may be rare times when you need to provide some access, but you should never trust anyone.
The second part of Niko’s question revolves around the European Union’s General Data Protection Regulation (GDPR) and user data. It is a vital part of dealing with those times when you decide to hand over the keys to your website.
Alright so here comes the issue after we think about GDPR. If this developer happens to be outside the EU, then you would need to anonymize customer data and make an NDA agreement with that exact dev or company that is behind the plugin so they can come around and fix things.
I will preface this with the usual I am not a lawyer. However, protecting user data is always a legal and ethical priority on any site you run, regardless of what jurisdiction you fall under.
In those — again, rare — cases where you need to provide access to your WordPress admin, there are steps you could take to better protect your site and its data. Regardless of the trustworthiness of a developer or a support staff member, there is always one rule of thumb when dealing with website security: trust no one and trust nothing.
The first step should always be having a backup system in place. On the off chance that the support staff breaks something, you will want to revert the site back to its previous state.
Never provide complete admin-level access. I recommend installing and activating a role and capability management plugin. This will allow you to create a custom role for support help and limit the areas of the site they have access to. You would then create a user account for them with this role. Once they have completed their work, delete their account.
If you do not want them to see registered users or do anything with user data at all, make sure their user role does not have the following capabilities:
There are many other admin-level capabilities like
edit_themes that you should also avoid. Essentially, disallow most of the caps from the Administrator list in the WordPress documentation.
Most likely, plugin teams might need access to the
manage_options capability and any that are custom to their plugin. Even those can be dangerous, but that backup you put in place should mitigate any potential issues.
As for an FTP password? I trust very few people with that level of access.
This reply probably sounds like I do not think any plugin shops or developers are trustworthy. Honestly, I do not know of any that have breached user trust using login or FTP credentials in this way. On the other hand, I have no way of knowing whether the staff member I am talking to plans to rage quit his job in the afternoon and is willing to burn everything down in the morning.
I have also seen a handful of cases where a developer dropped in to fix something but ended up breaking the site along the way. Backups were crucial in addressing those issues.
This post is not meant to make plugin developers or companies appear untrustworthy. Most are good people just trying to make an honest living. However, not trusting anything is website security 101. It is merely the baseline in which users should operate. If you go into any interaction with this mindset, it should help you make smarter decisions on a case-by-case basis.
I’m a systems analyst in government and we just simply setup a meeting, login with our admin creds and then give the vendor the control of the mouse if necessary. It’s not that complicated. Thanks
As soon as any remote support can upload a plugin or theme which would be required to test changes/new version on your site, you are pwn3d anyway, no matter of any capabilities.
Man I wish I could get plugin support to setup meetings with me.
Setting up credentials for support needs, in my opinion, is a last-resort option. Sometimes access is generally required if you really need to dig deep into an issue, especially when you’ve exhausted all other avenues to troubleshoot. However, there is always a risk, and before I request access, I make sure I have an agreed disclosure with the client. Plus, I tell them to ensure they make a full site backup (including the DB).
One of the things I really liked when I was developing Joomla templates and running my own site(s) on Joomla, is that it has an awesome ACL (Access Control List) setup. Extremely powerful! This is something WordPress should really have in the core, rather than having to install a “third party” plugin(s).
For the end-user, it’s more about trusting the developer and going on your gut feelings–and common sense. Know who you are giving access to. For the developer, it’s about realizing the liability you will accept, even with an official agreement.
Years ago we hired an expert to help us with some tricky server upgrades. He had us do a screen share where he could see our screen and he walked us through it. He didn’t want access and he felt that this would also help us learn and be able to do it next time. I think that is the ideal, if it can be coordinated.
Screen-sharing is definitely a more ideal practice. That’s more common where you have client support rather than product support. I’d love to see it start becoming a bit more standard.
It’s a kind of side issue to this but I have long felt that wordpress needs some kind of non-technical admin role.
Manager isn’t appropriate for somebody who wants to get in there and really edit the site content.
But I don’t want them being asked technical questions about installing updates, or confirming the site admin email is still valid, or editing security plugins.
I know I can edit roles in theory but it just seems like a lot of learning. Learning is not bad but trial and error with security is not something I feel comfortable with.
It just feels like there should be a “site admin” for all content management, and then a “developer admin” above that.
I have often heard this from many others. They need something that’s a step up from Editor but not have the God-like capabilities of Administrator.
There’s not much in-between space there. The
edit_theme_options, and maybe a few Tools-screen caps would really be the difference. Once you give access to any user or file-editing caps, they may as well have full access. And, with many plugins overrelying on
manage_options instead of using custom caps, I’m not sure how secure this is (not a fault of WP).
I think it’s something worth exploring though.
Widgets are in this in between category, which has been the frustration for me. However, rather than making a new role, I don’t see why editors shouldn’t be able to edit widget content by default. For larger groups, there may be editors who shouldn’t have access to widgets, but at that size installing a permissions plugin and adding a new roles seems like a fine solution.
Obviously since widgets are on their way out anyway, no point on a permissions overhaul now just for that. But I’m curious how full site editing features handle similar permissions, haven’t investigated that yet.
Yeah, widgets and nav menus were always an issue. The way core handled those made it impossible for plugins to break them away from the
edit_theme_options cap. I know there is a years-old ticket out there for this. Not worth digging up or exploring at this point.
As for FSE, it’s all tied back into the
edit_theme_options cap. This is hardcoded for the
add_menu_page() call for adding the Site Editor screen. All of the caps for the templates, template parts, and global styles post types look to be mapped to
Presumably a role/cap plugin could unhook the Site Editor screen, re-add it with a custom cap, and provide a full suite of caps for the post types.
I haven’t dug under the hood much more than that. There may be problem areas that I’m unaware of.
What do you think of a plugin like “Temporary Login Without Password”?
That’s a plugin I recently saw a developer recommend to a forum member when needing access to their site.
Based on just reading its description and not actually testing it, it sounds like it would be a good solution for many cases. Two things stood out to me though:
1) Temporary users cannot delete other users. That’s a major plus.
2) It allows site owners to assign any role to the temporary user. If that’s the case, I would still couple it with a role/cap management plugin to make sure they are not accessing screens they shouldn’t have access to.
Recently I’ve twice been asked by a theme dev and a plugin dev for admin access to a staging copy of the site to troubleshoot, which seems like a reasonable compromise, as long as potential privacy issues are addressed. I set up the access on the staging site itself, so there’s no access to the live site, and at the end of the process, I just delete the staging site.
The staging site solution is a good compromise. The OP brought that up in the longer text. If you have other user accounts on the install, which are also often stored in staging, just be mindful about securing their data.
I’ve been doing WP tech support for over 10 years for themes and plugins. I agree that most of the time issues can be resolved without a need to access the client’s admin. However, depending on the issue, sometimes it’s impossible to diagnose what’s going on without accessing the backend.
In those cases, not having access to the admin is like trying to fix a car without being able to look under the hood.
In my experience, most customers have no problem providing credentials but in those rare cases where the customer cannot provide admin credentials for any reason, I would put the ball on their court. The customer needs to provide a place (staging site) where:
1. the issue can be reproduced
2. support staff can access
3. there’s no sensitive data
Customers also need to be educated that their site is their responsibility. I often hear the “I am a (insert non-technical profession here) and I don’t have time to learn about FTP (or any other basic website tool)”. Guess what? Yes, you do. Depending on the type of site you run, maintaining it can be a full-time job.
If you rely on your site for income in one way or another, you need to be able to perform basic to intermediate troubleshooting procedures and not rely on plugin/theme support staff to fix your issues.
We used to have a term for that: webmaster.
That was a big thing I always stressed. If you run a website, no matter your technical skill, you are a webmaster. With that title comes certain responsibilities.
The other side of this question is when people (especially paying people) give you their credentials upfront and you didn’t even ask for them. Saying “no thanks” and making it a positive learning experience for someone who just wants you to make their problems magically go away — that can be tricky.
This article surprises me as a commercial theme/plugin seller but not as customer myself…
We have a higher plan that includes “we’ll log in and fix it if you can’t after following our instructions”. It is a matter of last resort that makes things easy for a customer in a pickle, especially someone new to WordPress. Never once has a customer rejected our offer to log in and help and we’ve destroyed exactly zero sites.
You have to do it right, though:
Have a very clear Support Policy and never stray outside of it
Ask the customer to make a full backup before providing access
Ask them to create a new account rather then sending their own
Get WordPress admin access via the new account / password reset process
For FTP, instruct a secure means of transmission (never email)
Store credentials securely (e.g. password manager) and only temporarily
With that said, I personally have not and never would give access to my own critical websites to a third-party, even a reputable one, because I do not trust anyone either. This my livelihood. I trust myself with other peoples’ sites but not other people with mine.
My question is, is there any super admin role or administration is the one who can control the whole site?????
On single-site installations, the Administrator role has access to everything by default. On multi-site installations, the Administrator has a limited set of capabilities (for example, it doesn’t have any file-editing caps) while the Super Admin has a full set.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable