[wp-trac] [WordPress Trac] #26946: Decouple the Menu System from Posts and Taxonomies

[WordPress Trac]

#26946: Decouple the Menu System from Posts and Taxonomies
--------------------------------------------------+----------------------
 Reporter:  MikeSchinkel                          |       Owner:
     Type:  enhancement                           |      Status:  closed
 Priority:  normal                                |   Milestone:
Component:  Menus                                 |     Version:  trunk
 Severity:  normal                                |  Resolution:  wontfix
 Keywords:  needs-patch dev-feedback 2nd-opinion  |     Focuses:
--------------------------------------------------+----------------------

Comment (by F J Kaiser):

 Replying to [comment:12 MikeSchinkel]:
 > Not every tool, no matter how good, it the right tool for every job.

 True. But when I look at the box of screw driver bits that I got in my
 (real life) toolbox for each kind of screw head, I'd wish that there would
 be less variation. This would allow me to own less tools and instead get
 better crafted ones. Guess we can end the comparisons here.

 > There are numerous other valid use-cases for serialized content besides
 a log.  Here are two: A cache for data; (...) Plugin or theme options

 How is ''cache'' or ''options'' different from what I described as
 ''log''? (rhetorical question)

 > > (1) Structural changes are expensive
 >
 > Agreed in general, but not for this use-case. (...) Menus are updated
 very infrequently, so another 100 milliseconds to update a menu is not
 going to be noticed by anyone who is not being pedantic.

 I'm talking about structural changes of the menu system itself. For e.g.
 properties of menu items are changed with an update of WP core.

 > Where is it written that there is a "for" related to the options table
 and that that "for" does not include menu items? Seriously?

 Seriously. Else it'd be name ''options and other stuff'', right? Yes,
 currently people are using it as if it would be name ''crap and more
 crap'', but I wouldn't set goals that low.

 > Currently you can find options as well as serialized data for at least
 Widgets, User Roles, Cron tasks and Transients (...)

 Ok... core partly doesn't use it that different than users do.

 > I looked through the code for your plugin (...)

 I was afraid you would. Not the best example, but the one that came to my
 mind quickest. Still my point stays: Reduced abilities for dynamic
 querying.

 > Why is another table any better?
 >
 > > think about multisites as well.
 >
 > Multisite has an options table per site; what am I missing that you see
 here?

 Users are shared across multisites. That's what I'd propose (in this
 fictional scenario) for menus/items as well. Imagine multisite for
 different languages, all sharing the same menu with just some minor
 variations. Or magazine and shop, sharing the same main menu. Etc.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26946#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform