[wp-hackers] "commenter" user role

John O'Nolan john.wp at onolan.org
Mon Mar 8 02:05:58 UTC 2010

I'm afraid I don't agree with that at all - a user is not a type of  
content... that's taking the content type abstraction to a whole new  

However you did make one excellent point that a lot of people have  
been confusing over the last few days:

"You are unnecessarily conflating "has a record in wp_users" with  
"having registered as a user."  Commenters would not be registered  
users, they would have a record in the wp_users table, nothing more."


On 8 Mar 2010, at 00:17, Mike Schinkel wrote:

> On Mar 7, 2010, at 2:34 PM, Stephen Rider wrote:
>> The more security conscious admin right now (generally speaking)  
>> does *not* let outsiders register at all -- unless they have  
>> specific reason to allow it.
> You are unnecessarily conflating "has a record in wp_users" with  
> "having registered as a user."  Commenters would not be registered  
> users, they would have a record in the wp_users table, nothing more.
>> The main security concern regarding making all commenters into  
>> users is that being a user -- of any type -- is a point of access  
>> to the system and a significant step toward hacking the site.   
>> Several times in the past a vulnerability in WP has come up related  
>> to Subscribers being able to elevate their own privileges.
> So, as I've said, but additional checks in that disallow commenters  
> from logging in. The problem with elevation of privilege is that you  
> let them login at all; put multiple checks in place to ensure they  
> can't login then this becomes a non-issue.
>> It's not superstition and it's not some emotional flight of fancy.   
>> When the user elevation bugs cropped up in the past, I'm pretty  
>> sure they only applied to sites that actually *allowed* users to  
>> register.
>> That's not superstition, that's historical fact.  Had all  
>> commenters been Users at the time, those vulnerabilities would have  
>> applied to any blog with comments.  It's a legitimate concern.
> Please address how incorporating multiple checks doesn't resolve the  
> situation?
> Anyway, it's becoming clear to me that this issue is becoming much  
> like a conservative debating a liberal or vice versa; both sides  
> have their perspective and both sides are intractable.
> So as I was replying a solution occurred to me that I think will  
> solve almost everyone's issues, especially those that are concerned  
> with security.
> Proposal:
> -- Add a "person" post type into WordPress core. 
> -- Create a taxonomy called "person-role"
> -- Add commenters as posts of post type "person" with a "person- 
> type" of "commenter"
> -- Create and maintain a parallel record of post type "person" for  
> each user in the wp_users database.
> -- Set  with a "person-type" to "user" for records of post type  
> "person" that are associated with a wp_user.
> -- Use wp_users and wp_usermeta only for things related to login and  
> user capabilities.
> -- Use wp_post_meta for things like Twitter Screen name, Bio, Photo,  
> etc.
> This would solve a myriad of problems. First, it would "harden" the  
> security by making wp_users/wp_usermeta totally focused on security  
> and role management; essentially wp_users conceptually becomes  
> "wp_logins."  It would make wp_posts and wp_post_meta focused on  
> personal, demographic and activity information.  This make it easy  
> to have pages for every person on the site and a whole bunch of  
> other things I can envision but I hope you won't need me to explain  
> (I've already typed too much this weekend.)
>>> I was proposing to consider using wp_posts with a post_type of  
>>> 'user' instead of wp_users. In the case where we keep wp_users and  
>>> also created a record of wp_posts with a post_type of 'user', they  
>>> are parallel.  It seems a binary option; how is it not?
>> I hope I'm misunderstanding you, because this makes absolutely no  
>> sense.  Whether a commenter is a User is one discussion, but are  
>> you really suggesting that we define people as a type of POST???
> Absolutely, 100% YES.
>> That sounds like a very bad, not to mention arbitrary and  
>> confusing, idea.  As somebody else commented, this sounds a lot  
>> like the Drupal "everything is a node" paradigm.  Can't say I'm a  
>> fan.
> It's not arbitrary of confusing to me at all. I'm working on a site  
> for a conference right now (a WordPress conference, actually) and it  
> would be a lot easier if users were a post type.
>> Think of the web site rule of separation: "HTML for structure, CSS  
>> for appearance, JavaScript for behavior".  Different structures for  
>> different purposes.  The Posts table is for site content.  Users  
>> table for users.  Options table for Options, and so on.
> People *are* content. Think of a Facebook page as an example:  
> Photos, URLs (Twitter, Facebook, LinkedIn, etc.), Bios, etc. etc.
> Hopefully but proposing what I did above you can see it differently  
> now?
>> Philosophically speaking, I actually like the idea of commenters  
>> being "Users".  My opposition to it is pragmatic.  People -- actual  
>> people -- are a unique element in a site, because they have minds  
>> and motives.  The text of a post is never going to spontaneously  
>> decide it want to hack my site.  A person might, and thus people  
>> have to be treated a bit differently.
> My latest proposal rectifies that.
>> Personally I prefer my commenters to be "non-entities" as far as  
>> the code is concerned.  I value their input, but they don't exist  
>> in terms of code, or what Users can and can't do in the system.
> If you value their input then I assume you'd want a page where you  
> can see all their comments vs. only seeing their comments littered  
> around the posts.  This latest proposal addresses that.
> On Mar 7, 2010, at 2:55 PM, Stephen Rider wrote:
>>> BTW, since you're adamant against storing structure in wp_posts,  
>>> what are
>>> your thoughts on how the new menu system stores its data?
>> I guest the question to me becomes: Why are we so afraid to add to  
>> the database when appropriate?
> For me it's not fear to add to the database, it's a desire to use  
> what gives more appropriate functionality.
> Personally, the menu items are the things I'd least like to see in  
> wp_posts.  I'd far prefer to see people and comments in wp_posts.
>> That being said, others on this list are probably more experienced  
>> coders than I am.  But perhaps that in itself speaks to the danger  
>> of getting **too close** to the code so that it becomes difficult  
>> to step back and see it from the perspective of someone approaching  
>> it as new.  The more it's all abstracted, the harder it is to learn  
>> and work with.  Just because we're all so close to it, we may make  
>> it easier for us but make it a lot harder for new people to  
>> approach it.
> True, but I don't think this would take us there.
>> I found WP *extremely* approachable when I was new to it, whereas  
>> having to work with Drupal ("everything's a Node!") is frustrating  
>> and confusing.
> Drupal is frustrating because of its lack of focus on admin  
> usability and because it maintains control of HTML assembly;  
> WordPress has neither of those problems.  (I worked with Drupal for  
> 2 years before moving to WordPress and leaving Drupal behind.)
> Drupal has focused on genericity in the admin UI; WordPress doesn't  
> fall into that trap.  Take the menu designer in WP 3.0 for example.  
> Nowhere does the admin ever see that menu items are stored in the  
> wp_posts table. If it were Drupal, it'd be listed in the node types.
> Don't assume improving the architecture forces us to bring along the  
> same problems that other platforms have; the two can be separated.
>> I'd rather separate the tables and abstract the functions a bit  
>> more (with wrapper functions as needed for both clarity and ease of  
>> use).  For a prime example of that I can point to the  
>> get_file_data() function that I submitted to WP 2.9 -- now used by  
>> both get_plugin_data and get_theme_data.  We could abstract the  
>> functions to deal with different tables if necessary, and wrap them  
>> in seemingly table-specific functions
> I agree that we should separate things when separation makes sense.
> However, we *should* consider putting in wp_posts table if *even a  
> few* of the following add value for the use case:
> -- Having a title/body editor for the item has value
> -- Having status workflow for the item has value
> -- Having visibility control for the item has value
> -- Having visibility control for the item has value
> -- Having revisions for the item would be valuable
> -- Having trash/delete management for the item would be valuable
> -- Having ability to schedule publish date/time would be valuable
> -- Having a web page of content about the item would be valuable
> -- Having ability to define a template for the content page would be  
> valuable
> -- Having ability to set another content type as a parent of the  
> item would be valuable
> -- Having ability to reference the item in a menu with a menu  
> orderwould be valuable
> -- Having category-like terms associated with the item would be  
> valuable
> -- Having tag-like terms associated with the item would be valuable
> -- Having comments associated with the item would be valuable
> -- Having custom fields (meta) associated with the item would be  
> valuable
> -- Having images associated with the item would be valuable
> -- Having easy URL routing for the item in the form /item-type/%item- 
> name%/ would have value
> -- Having an admin menu section for adding and editing would have  
> value
> -- Having plugins that support custom content types would add  
> valuable additional functionality "for free."
> FWIW, that's a pretty long list.  I can see many of those things  
> being valuable related to people and hence why a person post type in  
> parallel with wp_users and to include commenters makes tons of sense.
> OTOH, I'm not certain that menu items really benefit from being  
> there (though maybe they do.)
> On Mar 6, 2010, at 11:17 PM, Ptah Dunbar wrote:
>> I raised that issue about core post types not using the show_ui  
>> argument so if one decides to remove them, Posts,  Pages, and Media  
>> would disappear from the UI.
> Excellent!
>> Outside of that, I disagree that the core post types are really  
>> that hardcoded into WP; and if so, then that's probably a bug which  
>> you should file a new ticket for.
> You are missing the point.  It's not weather or not they are too  
> hardcoded, it's the fact that without being able to remove them few  
> people are ever going to test the edge cases.  If they are removable  
> then its much more likely the edge cases will get tested.
> Its a concern over resultant process and not of the specifics of  
> post being hardcoded.
>>> By having (previously) "core" functionality like "Posts" and  
>>> "Comments" in canonical plugins those broken edge cases are much  
>>> more likely to be worked out by the core dev team instead of  
>>> individually by everyone who needs it and has the resources to  
>>> work on it.
>> I'm -1 on canonicalizing "Posts" and "Comments" but I am +1 on  
>> removing any hardcoded references to them in core.
> Without the former you'll never be able to ensure the latter.
> Why would you have an issue with them being default canonical  
> plugins?  I can't see any downside to that.
>> Again, version 3.0 decouples a lot of the default posts types  
>> (posts and pages) as well as taxonomies (cats and tags) so if you  
>> find anything that current still is hardcoded, get it reported so  
>> it can be patched.
> Many bugs won't be found until decoupling it's easy for anyone to do.
> On Mar 6, 2010, at 11:52 PM, Ptah Dunbar wrote:
>> The posts table is more like a content types table. But yeah that  
>> goes back to the teenager reference. WP needs better semantics :)
> Nah, we just need to get comfortable with the semantics we have.
> On Mar 7, 2010, at 12:18 AM, Scott Kingsley Clark wrote:
>> We definitely agree there! I just think it's funny is all.. Oh,
>> wouldn't it be great if "post" (blog reference ftw) wasn't the term
>> for content in WP? LOL.
> My experience with Drupal, which refers to nodes as "content" in the  
> admin is just as confusing a "post."  At least we don't have two  
> terms (Drupal = node & content, WP = just post)
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list