Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #26946, comment 11


Ignore:
Timestamp:
01/27/2014 01:47:21 AM (12 years ago)
Author:
F J Kaiser
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #26946, comment 11

    initial v1  
    1515
    1616'''(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.
    17 '''(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.
    18 '''(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.
    19 '''(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.
    20 '''(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.
     17'''(2)''' 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.
     18'''(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.
     19'''(4)''' 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.
     20'''(5)''' 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.
    2121
    2222[A] http://wordpress.org/plugins/post-type-archive-links/