[wp-hackers] Menu schema

[Mike Schinkel]

On Mar 20, 2010, at 8:19 PM, C T wrote:
> This is a very pertinent point being made I feel. A .0 release IS the
> time to make major changes to important high level WP design such as
> DB schematics.

+1, but not because of it being a .0 release but because I don't think it's a good idea to launch with one database structure knowing there is a plan to transition to something else in the near future. It can really cause chaos with themes, plugins, upgrading, etc. to see core DB structures change after an official release. Best to minimize those required course changes when possible.

> This is not the main issue however, the issue is the complexity and
> confusion this causes. So you can access a menu item with the get_post
> function?? 

Am I missing something?  Where is the confusion?  

> Storing menus as taxonomy also makes little sense. Taxonomy is the
> process of naming and classifying things. This has great benefit to
> discreet data and in classification, however what benefit does this
> give to objects such as menu items? (Are they really 'objects'
> anyway?) This really seems like a poorly thought out hack and very
> inconsistent with other areas of WP.

Menus seem to me to be more like classification than they are like posts.  They seem to fit well there although I've not looked at all requirements for menus so until I do I can't speak to it.

> For me there are two clear options. Firstly a temporary measure to
> treat menus similar to widgets, with one entry in wp_options for menus
> and one for menu_items. Simple.

-1

I'm haven't formed an opinion on how menus should be best stored but I do believe that storing in serialized arrays is too fragile and thus not a good idea.  So it's not a clear option to me.

What I have noticed has been how fervent discussions on this list have been about using wp_posts for certain things but how AFAIK storing menus in wp_posts was never discussed here. I think that is indicative of how decisions are made in core and that discussion on this list isn't an important component (and is something I think I'll be learning from moving forward.)
 
> actually look at the reasons the WP database is limited to so few
> tables. Lets not confuse different entities and lump different
> entities together.

For the record, I originally believed as you do that more tables were needed but the small number of tables has grown on me as I've seen the elegance of the approach. It just works.  I'd hate to start adding new tables every time someone has a new idea. The fact that Pods and Gravity Forms add so many new tables makes them less optimal solutions from my perspective, for example. I'd prefer adding tables only when existing tables absolutely can't be used for a required feature. I'm even on record as thinking we should reduce existing tables by one and deprecate wp_usermeta to instead use wp_post_meta. But I digress.

-Mike