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:
create_usersdelete_usersedit_userslist_userspromote_usersremove_users
There are many other admin-level capabilities like edit_files, edit_plugins, and 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