20 Comments

  1. Dylan Roberts

    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

    Report

    • Claudio Bernoulli

      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.

      Report

    • CW

      Man I wish I could get plugin support to setup meetings with me.

      Report

  2. Andre

    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.

    Report

  3. David McCan

    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.

    Report

    • Justin Tadlock

      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.

      Report

  4. Matthew Harris

    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.

    Report

    • Justin Tadlock

      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 manage_options, 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.

      Report

      • CW

        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.

        Report

        • Justin Tadlock

          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 edit_theme_options too.

          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.

          Report

  5. Tom

    @Justin
    What do you think of a plugin like “Temporary Login Without Password”?

    https://wordpress.org/plugins/temporary-login-without-password/

    That’s a plugin I recently saw a developer recommend to a forum member when needing access to their site.

    Report

    • Justin Tadlock

      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.

      Report

  6. wwwolf

    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.

    Report

    • Justin Tadlock

      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.

      Report

  7. Rick Alday

    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.

    Report

    • Justin Tadlock

      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.

      Report

  8. Dan

    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.

    Report

  9. Steven Gliebe

    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.

    Report

  10. Alex tycor

    Hi,
    My question is, is there any super admin role or administration is the one who can control the whole site?????

    Report

    • Justin Tadlock

      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.

      Report

Comments are closed.

%d bloggers like this: