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.

Continue reading

When using the CMS, we’re used to relating data through WordPress metadata associations. Sometimes it’s well-used; other times, it’s abused.

If you’ve worked with web development in any other application, there are probably strategies you’ve used to associate data with different types of entities. That is, you’ve likely created tables specifically for the two types of information and then related them in a variety of ways.

It’s completely possible to do this in WordPress, but I think we often jump to either/or conclusions. That is we either think we can use the metadata table for everything or we have to create custom tables.

And, as with many things related to programming, I think it depends on our implementation.

Continue reading