[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:10 MikeSchinkel]:
 > 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.

 Agree that it's (currently) not the most robust system and it surely has
 its edges and shortcomings. But - at least for me - that doesn't mean that
 we should start spreading forces by introducing new systems. Let's face
 it: CPTs and CTs are what drives WPs content engine and they aren't going
 away.

 > I am usually against serialized arrays being stored in the database
 because most things really do need to be processable by SQL.  But for
 menus I've yet to find myself in a position where I've needed to process
 menus using SQL ''(other than that's how WordPress currently works.)''
 I'm not saying reasons do not exist but simply that I've not seen them and
 one of the reasons for this ticket is to hear from others if there are
 indeed reasons that serialization does not fit this use-case.
 >
 > > I hope I don't need to, but I'm able to elaborate that in detail.
 >
 > Please do.

 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.

 Anyway, here're some reasons why I'd never consider using serialized menu
 items in the options table:

 '''(1)''' Structural changes are expensive. You'll have to read all the
 data, filter it, change and then add it back to the stack, then update
 every single element/entry. This would only be worth it, if every item is
 ''exactly'' the same as every other one. Else you'll have to craft a fresh
 API to deal with all the variations. And variations (CSS classes, XFN,
 etc.) can be found all over menu items.
 '''(3)''' Serialized content can't be queried and filtered inside the DB
 layer. That means that every attempt to craft dynamic navigation based on
 arguments would be a pain. Imagine seasonally changing menu items in an
 online boutique/shop.
 '''(4)''' 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.
 '''(5)''' The options table is for options. Not for menu items. It's
 already tough enough to keep that one clean when test driving someones
 plugin or theme. If they shouldn't be a CPT or CT, then please a
 completely separate table. Then someone could at least add different menus
 for different themes and it would be much easier to keep them - think
 about multisites as well.
 '''(6)''' I can't see a real reason to use the system if you aren't
 satisfied. There have been enough cases where I hard coded a menu into a
 theme. Just because it was faster, it was the only menu on this site and
 no one would ever change it. Rule of thumb: Only make dynamic what needs
 to be dynamic. And from what I could read, you don't really need dynamic.

 [A] http://wordpress.org/plugins/post-type-archive-links/

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