Categorize Users

Categorize them how? There’s roles already but I think you mean something else.

I’ve thought about this before. In my work, it would be useful to have the core taxonomy UI for grouping users in various ways. Then when doing something like get_users, maybe you could do a tax query.

I think this makes a lot of sense.

@jan categorise them in the same way you can currently categorise posts, as Scott suggests.

@scott yes indeed, I keep stumbling over this one. the last 3 three web clients I had all wanted a categorisable, searchable member index, it brings a lot of value to community sites

Users have built in membership roles (subscriber, author, contributor etc.) and for the most part, that’s what we think when you say “organize users.”

You’d prbably want to use a custom user meta field and have that be your ‘role’ like ‘CEO’ etc, and then display that.

I didn’t say “organize users” I said “categorise them”, please don’t misquote me.

I’m not necessarily interested specifically in member roles, which anyway is only one category. I might want to also categorise them by skills, teams, cars, tools, whatever.

Right now I have a site to do for independent birthing professionals. I need to be able to categorise them into about 20 specialisms, like antenatal classes, breech birthing specialist, home birthing, etc.

I’m aware there are probably ways to script round it. I just think it should be part of the core UI like it is for posts. This is the Requests & Feedback section ??

Ipstenu,

I agree with you that that is a good workaround — but it IS a workaround (at least for a few of us. I get that most users/projects don’t encounter this situation).

I think the spirit of this request though, is more like this:

We really like the core taxonomy UI. That’s exactly how we want to manage users, too.

Does this fail to meet the standard of > 80% of use-cases? Absolutely. I’m not suggesting it be part of core. I’d be happy enough if all I had to do was, say, register a taxonomy for users in my plugin code.

* Correction, I suppose it would be part of core, but it’d play fine as something not exposed by default.