[wp-hackers] Custom Post Types and pending incompatibilities
elfin at elfden.co.uk
Tue Jul 13 07:51:46 UTC 2010
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
>>> 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
>> 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.
> 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).
More information about the wp-hackers