[wp-hackers] Menu schema

[Mike Schinkel]

Putting menus in taxonomy seems more appropriate to me. 

-Mike 
P.S. Can you do the code work to make the change?  My guess is that it's much more likely to happen if you provide the code. (That's what I've been learning from my discussions on the list, fwiw.)

On Mar 18, 2010, at 12:52 PM, John Blackbourn wrote:

> Whoops, looks like I made a silly there. Of course, nav menus are
> already a taxonomy!
> 
> So my main issue is in creating new entries in the posts table to use
> as menu items. My suggested solution of adding an object type
> indicator to each term relationship still stands. This allows us to
> use multiple object types within one taxonomy and therefore removes
> all the issues around storing nav menu items in the posts table.
> 
> Discuss please!
> 
> John
> 
> On Thu, Mar 18, 2010 at 4:42 PM, John Blackbourn
> <johnbillion+wp at gmail.com> wrote:
>> Just starting this thread to try and move some conversation off of
>> ticket #11817 (Better Site Menu Management).
>> 
>> It's been pointed out that the schema of the new menu management
>> functionality might not be optimal.
>> 
>> An issue brought up by ceenz is that menu items are stored in the
>> posts table (with a post_type of 'nav_menu_item'). This introduces the
>> following problems (issues by ceenz and myself):
>> 
>>  * Menu items contain very little data that relates to posts and
>> therefore many fields are not relevant (for example, comment_status
>> when a menu item relates to a taxonomy term).
>>  * This introduces data duplication. The post title (or taxonomy
>> title, object title, etc), post content, comment status, post status,
>> author, parent relationship, comment count, etc etc, are all
>> duplicated. Although I've not dug into the code, it also appears that
>> in the case where a nav menu item relates to a post or a page, some of
>> these fields (comment_status and post_author at least) don't actually
>> contain the correct values relating to the post or page. Whether this
>> is a WIP or not I'm not sure.
>>  * There is no field in this table to simply relate to the
>> corresponding object (this is why all our data is duplicated).  *
>> Because the post_status field is used as a nav menu item descriptor,
>> this field does not relate to the object that the menu item links to.
>>  * We now have two places where external links are stored - the links
>> table and the posts table.
>> 
>> My proposed solution is that menus should instead be treated as a
>> taxonomy (in fact nacin has already stated [1] that menus are a
>> taxonomy). We could introcude a taxonomy called 'menu' and each menu
>> could be a taxonomy term (menu 1, menu 2, etc).
>> 
>> Each menu item would be a term relationship. This handles any menu
>> item that is in the posts table. For any menu item that is an external
>> link, we could either create an entry in the posts table like we do
>> with the current menu system or think about using the links table
>> instead (but this might not sit well with themes that print out every
>> link in the links table).
>> 
>> For menu items that are a taxonomy term (eg. category X), this will
>> need a little work. Simply using the object_id field in the
>> taxonomy_term_relationships table would introduce ambiguity as an
>> object in this table only relates to one object type by default
>> (whichever object_type is specified when the taxonomy is registered
>> (see register_taxonomy()). I propose that we introduce a new field in
>> the taxonomy_term_relationships table called 'object_type' and this is
>> used to identify which object type it relates to.
>> 
>> By treating menus as taxonomies, we retain a correct relational
>> structure between menus and the objects in them. As a bonus, there is
>> a (currently unused) term_order field in the
>> taxonomy_term_relationships table which could be used to describe the
>> order of items in our menu (this would even work well with nested
>> menus as the term_taxonomy table has a parent field).
>> 
>> Discuss please!
>> 
>> John
>> 
>> [1] http://core.trac.wordpress.org/ticket/11817#comment:334
>> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers