[wp-hackers] Custom Post Types and pending incompatibilities

[Rich Pedley]

On 13/07/2010 08:03, Peter Westwood wrote:
>
> 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.

well no the data is still there.

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

agreed.

> 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.

Interesting, though how many people will do this? It would need to be 
in every plugin that uses custom post types.

> 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.

Search on stored data and trying to match to your setup - not easy to 
accomplish. But I suppose it is no different to an import routine. 
Which i admit I hadn't thought about, so yeah it is making sense now.

> 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.

Thanks for clearing it up for me - sometimes things just don't seem 
right until things are pointed out (and sometimes even obvious things 
pass me by).

Rich