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

 > CPTs and CTs are what drives WPs content engine and they aren't going
 away.

 I'm a big fan of [http://www.slideshare.net/MikeSchinkel/mastering-custom-
 post-types-wordcamp-atlanta-2012 CPTs] and CTs, but I also prefer to use a
 screwdriver to drive screws instead of a hammer. Not ever tool, no matter
 how good, it the right tool for every job.

 > The only valid use case for serialized content that I can see is a log.
 Write log once, read all entries at once, but have no searching, no
 updating. Pretty much like with a NoSQL DB. Just with a regular clean up
 task.

 There are numerous other valid use-cases for serialized content besides a
 log.  Here are two:

 1. A cache for data; unserializing is the fastest PHP way to move from
 disk to a complex in-memory data structure when those data structures are
 always initialized the same for every page load.

 2. Plugin or theme options ''(Because [http://osdir.com/ml/wordpress-
 hackers/2010-03/msg00543.html Otto says so]).''

 OTOH, I can't envision lots being all that useful as serialized arrays but
 I'm always willing to assume maybe I'm not seeing the full picture.

 > (1) Structural changes are expensive

 Agreed in general, but not for this use-case.  Menus model to an object
 and lists of other objects better than they model to database tables, and
 an object structure containing everything you'd want to know about a Menu
 takes a lot of code and SQL queries to load up, ever page load.

 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.
 OTOH, loading menus from the current table structure takes a lot more time
 and page load time for the user on ever page load is what should be
 optimized, not how long it takes to update something that is likely
 updated less than 0.01% of the time it is online and available for
 visitors to access pages.

 > (2) Serialized content can't be queried and filtered inside the DB
 layer.

 Agreed in general, but not for the menu use-case.  It's usually important
 not to serialize data stored into `postmeta` or `usermeta` because you
 frequently need to query on it, but I still cannot envision how that would
 ever need to relate to menus.

 Also the WordPress API discourages direct SQL as it is only acceptable
 when the API doesn't support a use-case. So the coding model to craft
 dynamic navigation would be to use the API, not to run SQL, and if the API
 didn't exist it would just require extending it.

 Maybe it's just not clear what I'm envisioning, but I'm struggling to
 envision anything that would be ''more'' difficult for this use-case
 compared to what we have now.

 > (3) Stuff like our "post type archive links"-plugin [A] would be much
 harder to accomplish as the menu items foundation wouldn't be that dynamic
 anymore: Check rewrites/routing on the fly, use the WP_Query API, etc.

 I looked through the code for your plugin and I'm confident that I can say
 not only would your plugin be easier to write if core used the approach
 for menus I advocated in this ticket but your function
 `ajax_add_post_type()` would become much simpler with ~1/2 as much code,
 your function `setup_archive_item()` would work very similarly, and
 chances are you wouldn't even need the function for the
 `'wp_setup_nav_menu_item'` hook.

 > (4) The options table is for options. Not for menu items.

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

 The options table is a table of name-value data pairs for global use
 across a site. Currently you can find options as well as serialized data
 for at least Widgets, User Roles, Cron tasks and Transients ''most of
 which are used similar to how I proposed serialized data be used for
 Menus.''  Menus are not out of line considering what else core stores
 here.

 Also, the WordPress database provides a collection of data storage
 patterns, and we as developers should strive to use those patterns if at
 all possible before we go and roll our own tables.  Options would work
 perfectly for Menus ''(at least I think it would.)''

 > It's already tough enough to keep that one clean when test driving
 someones plugin or theme.

 Funny, that's what I'm saying about the posts table. :)

 > If they shouldn't be a CPT or CT, then please a completely separate
 table.

 Proposing a new tables is pretty much a non-starter for WordPress, more so
 than most anything else.  Adding a new table is a HUGE decision, and one
 that won't be taken lightly by TPTB. To add a new Table WordPress.com
 would have to run a migration script over millions of sites, which is I
 understand one reason adding a table is such a big deal.

 > Then someone could at least add different menus for different themes and
 it would be much easier to keep them -

 Why is another table any better?

 > think about multisites as well.

 I'm pretty sure what I proposed could work equally well with multisite as
 it would for single site. Multisite has an options table per site; what am
 I missing that you see here?

 > (5) I can't see a real reason to use the system if you aren't satisfied.

 But I can see a real reason. I'd like to be able to offer end-users the
 ability to update their own menus ''and'' be able to more easily implement
 changes without making the menu system less robust.  If I hardcode them,
 then users require me to change them; that's what I'm trying to avoid.

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