This post is the second part in a series I’m working through that talks about WordPress Metadata Association, and the first part of this involves working through the process of programmatically creating WordPress users (but it’s been five years!).

I’ve talked about doing this before, but things change over time as we gain more experience, right? And in working through a series like this, I think it helps to have a set of requirements we can follow, at the very least, to simulate what it might be like to have this happen in a real project.

So in this particular post, we’re going to take a look at the following:

  1. Receiving user information in a particular data format,
  2. Identifying what information is required to create a user,
  3. Creating the user,
  4. Making sure our code is up to par with coding standards and readability.

It sounds like a lot, though I’ve no intentions of making this a long post. That said, if this is something you’re looking to learn how to think through or how to tackle, then here we go.

Creating WordPress Users

Assume that someone – perhaps a client or maybe even just yourself – as information that will be used to create a user. It needs at least the following information:

  1. a username,
  2. a password,
  3. an email address.

When it comes to creating a username, I tend to favor using the email address as the username as well because it’s something that’s guaranteed to be unique to almost anyone who uses the account.

So for this tutorial, that’s exactly what I’m going to use. As far as the password is concerned, I’ll talk about password generation momentarily.

Finally, you can assume the data you have comes in any form: Perhaps it’s in JSON, perhaps it’s in a CSV, perhaps it’s in an XML. Whatever the case, it’s up to you to parse this information into PHP so you can easily work with the information.

To keep things simple for this post, I’m going to assume we have a single record and we’re going to have the information available in an array. This doesn’t mean it starts in an array, but it means we eventually place it into an array.

1. The User’s Information

Assume we’ve got a person named “Meghan” we’re going to be adding to the system. We have an email address, and that’s it.

Creating WordPress Users: A Persona

An example persona (artist rendering, of course :)

But that’s okay. It’s the barebones of what we need. So let’s take this information:

And turn it into something we can use to create an account.

2. Creating the Account

The first thing we need to do is make sure a user doesn’t already exist for this email address. If it does, then we’ll simply return. You may want to display a settings message or some other type of information to let the end-user know you aren’t creating this account because it already exists.

But that’s beyond the scope of this post.

Instead, we’re going to return:

Then again, let’s assume the user doesn’t exist. If she doesn’t – which she shouldn’t (otherwise, there’s no reason for this post 😏) – then we’re going to create an account for her.

To do this, we need her email address and a password. Luckily, generating a password is simple:

So now we can take the email address and the password and create the user account.

Note in the code above we’re also setting the role. The way to go about doing this is to first grab an instance of WP_User and then with our $user_id then set the role.

Creating WordPress Users: Roles and Capabilities

I’m opting to use author, but there’s a set of others from which you can choose (or use whatever is in your data structure).

3. Isn’t There More to It?

And with that, your user should be created. Part of the this largely depends on the hook you’ve used, how you’ve implemented this into your process, and the way in which you’re allowing an administrator to create accounts.

This is a more advanced topic that I’d eventually like to cover in a future post. To keep this series as direct and as lean as possible, I’m trying to stay as focused on the core steps required.

Everything else can be implemented or dressed up around whatever else is needed as per the requirements of the project.

That’s Just Creating an Account

This is just the processing of programmatically creating WordPress users, though. In fact, this is just creating one user.

To create multiple users, assume that you have multiple arrays with information through which you can iterate and then create the users. The implementation is the same though it will vary from each account.

With that said, tomorrow I’m going to take about programmatically creating  post content programmatically. And after that, we’ll talk about relating a given user to the given post content and what we can do with that (as well as why this would even matter).

Series Posts

  1. WordPress Metadata Association: How To Do It
  2. Programmatically Creating WordPress Users
  3. WordPress Post Types: An Abstraction For Entities
  4. WordPress Metadata Association: Relating Entities
Category:
Articles
Tags:
,

Join the conversation! 4 Comments

  1. Hi Tom,

    I’m wondering why you’re using PHP’s FILTER_VALIDATE_EMAIL filter (filter_var( FILTER_VALIDATE_EMAIL, $email )) instead of WordPress’ sanitize_email() function. Any specific reason?

    P.S. I think you have a syntax error. Unless I’m mistaken, it should be filter_var( $email, FILTER_VALIDATE_EMAIL );

    • I think you have a syntax error. Unless I’m mistaken, it should be filter_var( $email, FILTER_VALIDATE_EMAIL );

      Yeah, oops, I fixed this shortly after publishing it — thanks, though!

      I’m wondering why you’re using PHP’s FILTER_VALIDATE_EMAIL filter (filter_var( FILTER_VALIDATE_EMAIL, $email )) instead of WordPress’ sanitize_email() function. Any specific reason?

      It’s generally because most the projects I’ve used have been better served by filter_var but that’s not to say sanitize_email shouldn’t be used. At minimum, use one or the other or – at the most aggressive way – use both :).

      Though I’m normally a fan of using the application’s API when possible, this is purely an example of my using an example from some code I’ve previously written. It’s not an argument for/against the WordPress API.

      Thanks for mentioning that function!

  2. Not to get too far away from your main point of how to create a user, but there are some privacy and security issues to consider along the way.

    WordPress publicly displays the username in various places, for example, when a user leaves a comment on a blog post. Using the e-mail address as the username means that a user’s e-mail address can be revealed to the public. That’s not only a privacy issue but it pretty much guarantees the user will be inundated with spam as bots scrape every e-mail address shown on web pages.

    Coming back around to coding automated user creation, it may require building a username from the left portion of an e-mail address (still could have privacy concerns), a hash of the e-mail, or generating a random username.

    On the security side of things, wp_generate_password() creates a 12-character password by default. Since 12 characters are just out of reach of current brute force password cracking techniques, a few extra characters make for reasonable future-proofing without inconveniencing the user too much more. I believe that’s why WordPress defaults to generating a 16-character password for new accounts and resets.

    • there are some privacy and security issues to consider along the way

      Absolutely (and always :)

      Using the e-mail address as the username means that a user’s e-mail address can be revealed to the public. That’s not only a privacy issue but it pretty much guarantees the user will be inundated with spam as bots scrape every e-mail address shown on web pages.

      Agreed. There are times where this is okay (such as within Intranet appliations, sites, and so on — and I’ve worked on those before), but as a public site, definitely. Good point worth mentioning here so thank you for that.

      Coming back around to coding automated user creation,…

      The ways you’ve mentioned are good. I also like…

      • generating a name based on the first and last fields (if provided),
      • creating a username, like you mentioned, that’s random
      • using a combination of the first part of the email address and the last name
      • etc.

      <

      p>There are a lot of ways to do it but simply using the email address in a public settings is going to result in lots of frustrated users :).

      Since 12 characters are just out of reach of current brute force password cracking techniques, a few extra characters make for reasonable future-proofing without inconveniencing the user too much more. I believe that’s why WordPress defaults to generating a 16-character password for new accounts and resets.

      Point taken and gist updated!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.