[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 aaroncampbell):

 First, I think we can all agree that the issue of shared terms across
 taxonomies needs to be fixed.  It's a clear win and will definitely help
 fix some of the oddities that affect menus.

 Other than that, I have to say that I'm with Wonderboy, Nacin, and F J on
 this.  I definitely don't see the benefit of storing menus as a serialized
 array or object.  They are notoriously hard to query for, which limits the
 flexibility of menus quite a bit.  Right now you can do things like add
 another taxonomy and build dynamic menus by pulling menu items from any
 number of menus.  You can also easily do things like pulling all menus
 that contain a certain post.

 Replying to [comment:17 sc0ttkclark]:
 > As for the ticket, I do agree that the taxonomy issues should be
 addressed either way. But IMO configuration should never be stored in
 CPT/CT, core and other plugins should architect in such a way that
 treasures proper database architecture and separation over ease of API. I
 speak with large projects in mind, recently which have had to deal with
 some plugins storing certain types of config as post types and meta, where
 the DB had millions of rows in posts/postmeta, and was slowing down the
 page needlessly, even if cached (during generation of initial cached
 value).

 The "menu options" are stored as options.  Whether to auto-add root-level
 pages is stored as a regular option and the menu locations are stored as a
 theme mod, which is just a namespaced option.

 Yes, things like the item type, parent, target, etc are stored as post
 meta, but that means they are able to be included in a query.  I can pull
 a menu and filter out the items that are set to open in a new window...all
 in the query (and I've done this).  It will definitely cause the post meta
 table to grow, but I'm far less worried about the number of rows than I am
 the ability to query them.

 Maybe I'm not understanding the concern about number of rows.  We're
 currently working on a client site that has over 2.5M rows in the post
 meta table, and it's still lightning fast.  I've worked with post meta
 tables more than ten times that big and never had any issues.  I like that
 the data is highly available and the ways I can use it are flexible.

 Replying to [comment:10 MikeSchinkel]:
 > I used to think that, but after lots of attempts to use CPTs for many
 things in my own libraries I've move away from that in some cases. If you
 overload them too much you end up with a very fragile system where it's
 far too easy to break something when you are working on something else.

 I haven't really experienced this, but maybe you can make some tickets
 that help address the weak or unscalable parts of the CPT system instead?
 It's definitely not a tool for every purpose, but it actually seems to fit
 menus quite well.

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