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

 Replying to [comment:21 mbijon]:

 Thanks for commenting.

 > Mike, what are your thoughts on using a nested set schema instead?

 Hmm, not really sure what ''"a nested set schema''" is. Examples?

 > Why specify serialized objects before mapping needed API improvements?
 Probably a bad way to open discussion though…

 Yes, I do believe I made a tactical error by opening the discussion this
 way, but it's just the way I think. I've got 30+ career years of
 indoctrination related to issues where the mantra has always been ''"Don't
 bring me a problem, bring me a solution."'' But for some reason proposing
 a solution as a [http://en.wikipedia.org/wiki/Straw_man_proposal strawman
 proposal] causes people to react negatively rather than just opening a
 discussion of alternatives, and I still can't grasp why that is.

 OTOH, I have also tried leading with the problem(s) to solve and then I'm
 told Trac is for code, not for discussions and yet there's no clear place
 I'm aware of to post discussions on specific issues.  So I feel damned if
 I do, damned if I don't.

 Frequently when I post an issue it's usually the last straw for me related
 to a concern but I don't always remember all the details of the several
 previous times I've encountered the issues so I can't always give
 exhaustive reasons; I guess it's my fault that I don't have a better
 cumulative memory for the details or that I didn't recognize the first
 time I recognized an issue that it would be recurring.

 So I would gladly change how I presenting things if I only knew a better
 approach that would indeed be more effective. But at this point I'm
 [http://en.wikipedia.org/wiki/Learned_helplessness learned helpless].

 Anyway, given that you've revised discussion here are the two (2) issues
 that my proposed solution was trying to solve:

 1. The API leaves a lot to be desired, and would IMO benefit significantly
 from moving to a `WP_Menu` class and related classes.
 2. More importantly, the impedance mismatch between posts used for
 managing content and posts used for managing Nav Menu Items. I'll
 elaborate on that to the best of my memory below.

 Regarding 2. above, here are the Top 10 reasons why IMO posts don't work
 well for Nav Menu Items, **in increasing order of importance** ''(Note: In
 general, I advocate people use posts rather than add tables, but
 experience has taught me that at least for Nav Menu Items, posts are not a
 good fit):''

 10. Posts have many fields that are simply not needed for Nav Menu Items,
 some being `to_ping`, `pinged`, `post_password`, `post_content`,
 `post_excerpt`, `post_date`, `guid`, and `post_mime`.

 9. Nav Menu Items don't have comments.

 8. Nav Menu Items use more post meta fields than they actually need to use
 fields in the `wp_posts` table in the the post table: `classes`,
 `menu_item_parent`, `object`, `object_id`, `orphaned`, `target`, `type`,
 `url` and `xfn`.  Together 10 and 8 make using posts a heavy solution for
 the use-case.

 7. Saving and loading posts fires many hooks, most of which are completely
 irrelevant for Nav Menu Items.

 6. All that hook firing and db access makes the process of using menus in
 the admin less responsive than it could be.

 5. The loading of so many records for one menu on the front takes up time
 that could be made a lot more efficient without having to implement
 caching.

 4. It's easier for a novice theme or plugin coders to break the menus in
 strange ways or to incorporate Nav Menu Items into lists of externally
 published posts because they don't realize the have to filter out
 `'nav_menu_item'` post types in large part because they had no menus when
 they were building and testing.

 3. Workflow that should affect all ''content'' posts must always filter
 out `'nav_menu_item'` posts.

 2. The `'transition_post_status'`, `'edit_post'`, `'post_updated'`,
 `"save_post_{$post_type}"`, `'save_post'`, `'wp_insert_post'`  hooks
 ''(and many others)'' need to make sure that they filter out
 `'nav_menu_item'` posts which isn't always obvious to everyone.

 1. `wp_unique_post_slug()`;
 [https://core.trac.wordpress.org/ticket/11863#comment:52 the ill-fated
 decision] to allow values for the `post_name` field in trash override the
 values of newly created posts makes Nav Menu Items and other programmatic
 used of posts a real data integrity nightmare. I wasted a literal month's
 worth of coding trying to use the WordPress menus in a system where my
 code generated the menus, with constant data integrity issues until I
 finally ripped it out and put in my own menu system and all the issues
 went away.

 P.S. Further, none of the WordPress admin UI for posts is used for menus
 which is a strong hint that maybe the two things really are different.

 FWIW.

 > I think there's a lot of API improvements that are needed for menus, and
 some may be limited by the current schema. Choosing a schema before
 planning a final or best-case API seems a little early.

 I probably agree, but I'll need your help to clarify with examples for me
 to be sure.

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