[wp-hackers] Custom taxonomies for authors

[Mike Schinkel]

On Mar 14, 2010, at 11:44 PM, Dougal Campbell wrote:

Thanks for responding. I always appreciate your perspective.
> 


> On Mar 13 2010 4:15 PM, Mike Schinkel wrote:
>> Sigh.  I covered that already in an earlier post to this list.  Only mirror users that have rights to a WPMU blog into that blog, simple as that. It would just not make sense to copy user "John" in the posts table for user "Mary"'s blog.  
> 
> But if you are copying user data from blog-to-blog "as needed", you break single-sign-on, right?

Nope, login (as proposed) stays in wp_users table.  "Content" about a user mores to wp_posts/wp_postmeta, as proposed anyway.

> And further, you now can have user 'foo' on Blog A that is not the same as user 'foo' on Blog B.

True.  Which brings me to how I dislike the multiple duplicated tables in WPMU, but I won't go there today (nor will I probably ever.)
 
> That's not necessarily a bad thing in all situations, but it's definitely not backwards-compatible. Assuming the goal is a backwards-compatible refactoring, how would you propose syncing the user data? Would there be some special-case user record that acts as a pointer to the userid & blogid of the "master" user record? That's the only thing that comes to mind right now, and to that I'd say yuck. Special case exceptions are the devil.

I can agree with that.  

But it seems neither way is perfect, so let's discuss two different yet probable use cases?  Since we both live in metro Atlanta, I'll use local examples:

Use-case #1:  Student Blogs for a University
-----------------------------------------------------------
Let's assume Georgia State University puts up a WPMU site and requires all students to publish a blog and to comment on other blogs.  Metadata related to users might be name, address, home town, Facebook URL, etc.  In this case the cross-over between users on each blog would be relatively high.  To your point having to enter the same info into each blog would be a serious burden on the user.

Use-case #2:  Local Newspaper Blogs for Local Writers
---------------------------------------------------------------------------
Let's assume Creative Loafing puts up a WPMU site and and solicits ~50 blog authors.  These authors get to blog on a topic and get a cut of ad revenue from their own blog, and even get to solicit guest bloggers if they like.  These blogs cover topics that are across the board; some are music blogs, there's a doctor who blogs, a motorcyclist, a marathoner, and "Internet Marketing" coach, a "local celebrity watcher" blog, and more.  

Each blog appeals to a different demographic but there is cross-over.  What's more most people who are active commenters happen to be active on more than one blog, but at each they expose a different persona of themselves.  The doctor is also a motorcyclist, but on his doctor blog his profile includes his degree, school he attended, papers he's written,  conferences he's spoken at and more.  On the motorcycle blog he lists the different motorcycles he has owned over his lifetime, his favorite places to ride, the tools he owns, pictures of his bikes, etc.  So for this use-case it's important to separate out the user info between sites, and currently WPMU doesn't really support that (or at least I don't think it does.)

So after writing the above I realize that we really need BOTH; i.e. all people in the main database in the wp_posts AND each applicable person in the wp_posts table for each blog, as applicable.  Then the admin would get to choose what person meta is global and then each site owner could get the global meta for free on their site (or hide some of it) and also define their own site-specific person meta.

If you really think about it this is a general pattern that applies to many things, not just people.  In the case of the WPMU install for Georgia State University it would be very appropriate for them to create custom post types of "Building", "Course" and "Degree" in addition to "People" and share those across ALL blogs of their WPMU install.  

So instead of discrediting the use of wp_posts to keep track of people as a first class post type in core because of issues that WPMU may present we have in reality identified a new and yet very useful general purpose pattern, don't you think?

> I think a key phrase here is 'when people represent content'. I think the difficulty with this idea is conflating the concept of a 'user' with 'information about a user'. Personally, I still think that the use-cases for moving user data into the posts table are outside the norm.

When you really look at data about a user isn't (almost?) everything except login and password are content. Why is my website, my AIM, my Yahoo IM and my Jabber / GoogleTalk fields not considered content? (and where's my Twitter, Facebook, and LinkedIn URLs while we are at it, by damn! :-)  

I think the bigger problem is when we make an arbitrary distinction between what is content and what isn't and then we have the "have nots" problem.  It's like how Links are in their own table and because of that we don't get link metadata, we don't get link tags, nor do we get any of the other goodies a custom post type gets. (But we are forced to have special infrastructure to support link categories.)  Same is true with a person so I ask please let's not make an arbitrary distinction.

FWIW, today for a website I'm building I really need a "person" content type that mirrors wp_users but I don't know that subsystem well enough to get my fingers dirty in the time I have to allot to the task. I have the person content type but it's not mirrored to the user table meaning people can't maintain their own data in their Person post type record. :-(

> I do, however, like the idea of being able to relate custom taxonomies to a user. And if you want to be able to tie more data to a user, what about a custom post type? I could see making a 'user-bio' post type, and maybe even overloading the post_parent field to tie to the userid instead of to a postid...

Now you are talking!  But rather than a "user-bio" post type why not just make it "person" post type and give it a tag taxonomy of "person type" (author, commenter, etc.)?

> (but then, that's a special case exception, isn't it?)

At the end of the day you do ultimately have to hardcode some things.  There is post-thumbnail, isn't there? :)

-Mike