[wp-hackers] Custom Post Types and pending incompatibilities

[Peter Westwood]

On 12 Jul 2010, at 23:24, Rich Pedley wrote:

> On 12/07/2010 21:24, Peter Westwood wrote:
>> I've read through the whole thread and he are my comments.
>> 
>> Personally I would recommend against people "reserving" post types
>> - you are creating mines in which your data will be stored which
>> won't make it easy for other plugins or themes to interact with
>> without breaking arbitrary rules:
>> 
>> "like custom post types must be prefixed in a plugin specific way"
>> 
>> I would rather recommend that if you are creating a plugin which
>> allows people to create "Events" you use a post type called "event"
>> and you write your code in such a way that if some special piece of
>> post_meta you need is missing you have a default for it which you
>> use.
>> 
>> That way when I decide to switch from your Events plugin to this
>> new kid on the block I can still manage and use all those events I
>> already created using the new plugin.
> 
> I cringe whenever I read people saying this. Maybe my thinking is wonky on this issue, but surely different plugins will have different ideas on how to use things. Example: 2 plugins each using 'event' as their custom post type.
> plugin one uses start_date & end_date
> plugin two uses startdate & enddate
> 
> (and yes I'm thinking specifically of post meta here).
> 
> You stop using plugin one and go to plugin two - but you will potentially lose any extra data stored. The only commonality is the post type name - every thing else is potentially different.
> 
> Yes the post itself remains, but all the extras won't. I'm not sure I see the benefit of actually using the same custom post type.
> 
> So am I missing something here?


There is in my opinion a huge user benefit in the following:

When I switch from Event Plugin A to Event Plugin B I don't "lose" all my events.

The bulk of the info stored for this post type will be in the standard fields.

Yes there will be some probably plugin specific post_meta but there is no reason why on activation you could not schedule a cron task to scan existing "events" for missing meta data and help the user fix those old events.

To take this a step further the fixing process could actually just help the user tell your plugin which of the existing meta items contain the info it needs.

I would much rather the user experience revolves around a little work to solve the differences between meta storage than just "losing" all there content.

Cheers
-- 
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5