[wp-hackers] Custom Post Types and pending incompatibilities

[Paul]

Mike,

Just ignore most of my comment. Most were apparently just misinterpretations of your comments. Just need to learnt o keep my thought to myself. 

Thanks,

Paul

On Jul 10, 2010, at 7:59 PM, Mike Schinkel wrote:

> On Jul 10, 2010, at 5:51 PM, Paul wrote:
>> Personally I can't say I like the idea of theses solutions. Having a codex page or central site where you need to somehow register your post type name just seems wrong to me. Too many extra steps to just through. 
> 
> Not sure what others are thinking but my proposal was to offer an opt-in for those who proactively want to collaborate, not a requirement for those who do not.  
> 
>> One idea for the core WP side is to have all the post types proceeded with wp_ and make this reserves for all core post types to that plugin authors cannot register anything beginning with 'wp_'.
> 
> Any reason not to just go with an underscore prefix?  
> 
>> I agree with your thought here but don't really see a way to control this. It sort of goes against the openness of the WordPress plugin architecture. Consider how many Event/Calendar plugins are currently on WordPress.org (dozens). Some are great and do 75% of what I need. Others not so much. Even without the new custom post type functionality can you see a way to tell these plugin authors "Hey, if you plan to develop an Event/Calendar plugin it must meet this list of function and custom field requirements.". Again, I say it goes against the openness of the infrastructure which makes WordPress what it is.
> 
> That's not what I was suggesting. There's no need to control anything; this was more about enabling those who do want to collaborate.
> 
>> Nor do I like the thought that via a community there will be a combined effort to develop a single kick-ass Event/Calendar plugin. Because my needs for an Events plugin are not the same as your or others. I like having dozens of choices. 
> 
> I wasn't proposing a "plugin to rule them all"; no, much simpler than that.  I was proposing collaboration on post type and custom field naming, and possibly some shared classes and functions.
> 
> If five people want to each build event plugins wouldn't be be great if they all settled on the same way to store the basic subset of information they all needed about events like naming of the custom fields for the date, venue, etc?  That way there would be a great likelihood of there being compatibility.
> 
> It would be similar to the discussion of geo data on the list last month that pretty much everyone gave a +1 too. Rather than have one plugin store in a "latlong" custom field and another in "geo_lat" and "geo_long", better to get proactive people talking so they can use a common custom field name so as to avoid the arbitrarily incompatible naming.
> 
>> A bigger question is who decided what warrant putting these working groups together?
> 
> My suggestion was to set a number of people required to be interested and if enough people are interested then they would get a working group.  And "working group" could be too strong a name, maybe it's just a BBPress forum (or a wp-whatever mailing list.)  
> 
> But there easily could be other approaches; I just proposed one as a starting point.
> 
>>> 2.) Give people a place on WordPress.org to propose new working groups and if they collect enough "+1s" (10 people or more? 25? 100?) then they get their working group.
>> The 'Digg' effect. Personally I don't see it working for any of my client sites. Sorry. 
> 
> I am confused about why it would need to "work" for your client sites.  This is about a way for the people in the community who are building plugins to work together for mutual benefit, not about clients who typically could care little about the technical and organizational aspects of WordPress.  
> 
> So you have me completely confused on this; mind if I ask for elaboration?
> 
>>> 3.) Recommend that all values used for post_type in the wp_posts table be either singular or plural (my strong preference is singular but will go with whatever the consensus is) except for in use-cases where the rule would obviously not apply. And recommend that they use dashes or underscores for post type names, one or the other.
>> 
>> Yeah, but you are talking about the first parameter to the register_post_type function which is different than the labels. I can register an Events custom type as 'THX1138'. The post type 'key' really is insignificant except it needs to be unique for my post type needs.
> 
> The post key is insignificant until someone wants to run two plugins that do different things but use the same "key."  Or until you as a developer creates a custom post type with the same "key" that is identical to the key used by a plugin developer for a plugin your client wants to use. Point of note, the conflicts are going to happen, there's little if anything I could suggest that would keep all instances of post type keys from conflicting, mine what more about helping those who want to be helped.
> 
> Post keys are a global namespace, and global namespaces will always have conflicts. Having approaches to minimize those conflicts would be nice. 
> 
>> Personally, I worry about having this action in the init process. Why is it required to register a post type for every page load? Why is this not done once like when a plugin is activated? But I digress. 
> 
> Yes, you digress. :)
> 
>> Again my comment from above. Underscore works but why not 'wp_' like most of the functions in core. 
> 
> Two more chars to type and to store per record in the database?  But either one would address the issue.
> 
> On Jul 10, 2010, at 7:08 PM, Rich Pedley wrote:
>>> One idea for the core WP side is to have all the post types
>>> proceeded with wp_ and make this reserves for all core post types
>>> to that plugin authors cannot register anything beginning with
>>> 'wp_'.
>> 
>> Although I totally agree with the reasoning, this is likely to cause a few plugins with custom queries to stop working. So the change would have to cover both, for example, wp_posts & posts for several releases.
> 
> 
> Clearly.  Hence I understand how problematic it would be to do this with posts, pages, revisions and attachments and maybe even for nav_menu_items.  But for future ones...
> 
>>> Not sure how to get that "best practice" out there so that it
>>> becomes widely know?
>> 
>> Well adding it to:
>> http://codex.wordpress.org/Custom_Post_Types
> 
> 
> Yes, I guess that would be a start although it wouldn't necessarily address all the articles written about it. I guess I/we could comment on those posts in hopes that readers will read all the comments and/or the author will update the post.  But, at least for me it would seem premature because AFAIK there's not a reasonably agreed approach yet, or is there?
> 
> Would "myplug:event" be an appropriate prefix, or should it be "myplugin-event" or "myplugin_event?"  Which begs the question; is there a defined set of valid characters for a post type or is it defined by what works (and what doesn't, if any?)
> 
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers