Skip to content

Sometimes you just want to be someone else… in WordPress

WordPress User Impersonation class

I was recently asked to develop an easy way to allow the administrator to perform specific action on behalf of as user.  Many of these tasks were already set up to auto-populate fields with information pulled from the current user, so I figured the easiest way to address this task would be to allow the administrator to impersonate a user and perform these actions using the same process any other user would.

With this concept in mind, I set about creating a user impersonation class that would allow just such functionality.

The first issue to address was the creation of a way to initiate this impersonation.  Luckily I had already created a report system which lists all the users I would need to impersonate and displayed some information about them.  This proved to be the perfect place to build the link.  A simple URI string let me initiate the process.  By passing the users id as the value of a URI parameter, I could have my class watch for that variable and capture its value.  I implemented WordPress’s nonce with this link to ensure some level of security.  To make this process even easier, I created a static method within the class that creates the necessary link while giving me the ability to specify the link target, which I set to ‘_blank’ so as to allow me to keep the admin page window open while I do what I need to do on the front-end.

Now that I had the link in place, I had my class create session values to hold the original admin user id, the impersonated users user id, and the nonce string I had generated to allow for continuous validation (note: the $_SESSION super global needs to allowed in wp_config.php in order for this class to work).  Additional validation was set in place using roles and capabilities to make sure that the user doing the impersonation was actually allowed to do so.

Now that I had the necessary values stored in the session, I used WordPress’s wp_set_current_user function (which really seems to have been designed for just this purpose) to set the current user to the specified user while on the front-end.  The session allows for persistence.

Once I got all that working, I wanted an easy way to stop impersonating the user, so I hooked to the admin_bar_menu and added a ‘Stop Impersonating [username]’ menu item.  I wanted this to take me back to the admin page (since theoretically I’d be done on the front-end), but this resulted in permissions errors.  I added nonce to the link, but that had the same result, because I was clicking the link as the impersonated user but getting to the admin page as my original admin user.  I ended up replicating WordPress’s nonce creation functions to allow me to use the session stored admin user id to generate the nonce so that when I hit the back-end it would be accurate.

This class works great for my needs and could be modified to maintain impersonation on the back-end if needed since the abort link in the admin bar would allow you to get back to your original user if necessary.

This functionality could prove exceptionally helpful when testing permissions, user-specific issues, or anything else where being another user temporarily would be required.

capabilities covered
B2C Solutions B2B Solutions Government Higher Education What We Do IT Consulting Support

The Atlantic BT Manifesto

The Ultimate Guide To Planning A Complex Web Project


Atlantic BT's Insights

We’re sharing the latest concepts in tech, design, and software development. Learn more about our findings.

Questions & Answers

Are there differences in application architecture that are important for the cloud?
It is important to build applications and workloads specifically for the cloud. You will want to carefully consider what services the cloud provider of your choice has to offer and how your application leverages those services.
Learn More about Are there differences in application architecture that are important for the cloud?
Are there any drawbacks to cloud hosting?
Yes, there will always be some risks associated with any hosting option. You are relying on the resiliency and engineering of infrastructure that has scaled at an astounding rate.
Learn More about Are there any drawbacks to cloud hosting?
What’s the benefit of hosting in the cloud vs. traditional options?
Reasons not to host in the cloud are few and far between. If you don't host in the cloud, you will spend more in both CapEx and OpEx to manage your applications or websites in a traditional environment.
Learn More about What’s the benefit of hosting in the cloud vs. traditional options?
How can I improve the performance of my application?
There are several primary reasons that applications perform poorly, and in some cases it’s a combination of several. 1) Data latency: If your application is making calls to a data source (whether it’s an API or a direct call) and there is latency at the data provider, your application performance will suffer.
Learn More about How can I improve the performance of my application?
Should I move my application to the cloud?
The answer is ‘probably yes’. There aren’t many reasons for an application to be hosted elsewhere, aside from occasional compliance standards, or requirements to integrate with local services that would require large amounts of data to move from on-premise to cloud.
Learn More about Should I move my application to the cloud?
Where should my application be hosted?
There are many different options for hosting, but most applications would do well with one of the cloud providers -- Amazon Web Services, Google Cloud Platform, Microsoft Azure.
Learn More about Where should my application be hosted?