[wp-trac] [WordPress Trac] #13822: Menu items that get unpublished still appear

[WordPress Trac]

#13822: Menu items that get unpublished still appear
------------------------------------------------+---------------------------
 Reporter:  nacin                               |        Owner:  nacin    
     Type:  defect (bug)                        |       Status:  reviewing
 Priority:  highest omg bbq                     |    Milestone:  3.0      
Component:  Menus                               |      Version:  3.0      
 Severity:  major                               |   Resolution:           
 Keywords:  has-patch dev-feedback i18n-change  |  
------------------------------------------------+---------------------------

Comment(by nacin):

 Dead link is not the only consequence, it is exposure of data that should
 be hidden.

 I have
 [http://core.trac.wordpress.org/attachment/ticket/13822/13822-on-r15218.diff
 attached a diff] that shows my changes against r15218, which shows the
 limited changes of the diff (a lot of it is removing the specialized trash
 handling).

 The patch you posted to get us going is missing the exclusion of
 $old_status == $new_status and also would probably duplicate efforts with
 trashing and untrashing of posts. The current implementation is not ideal
 UX, it overlapped with the no-JS pending, and triggered a bunch of bugs
 related to unpublished handling, starting with menu items associated with
 trashed posts. On the other hand, 13822-reverts-r15219.3.diff is ready for
 commit. I thought [15219] was way too many changes so deep into an RC
 phase, and additional bandaids on it now is probably the wrong direction.

 Handling this on generation is exactly how wp_list_pages/wp_page_menu
 functions, in that its get_pages() call only grabs published pages. I fail
 to see any simplicity in generalize-object-change-logic.1.diff that is not
 present in 13822-on-r15218.diff, and it's hardly a code rewrite. It's more
 code changes and more points for failure than what's currently in core.

 > This proposal puts additional burdens on the public generation of menus,
 rather than handling the issue one time when it happens.

 Absolutely not. It's extraordinarily light code.

 wp_setup_nav_menu_item() decorates a menu object based on the properties
 of post object it is associated with. If the properties of the post object
 invalidate the menu item for public display, that is clearly within the
 definition of setting up the menu item. It opens up no additional "bug
 possibilities".

 I think most of the concerns outlined here are exaggerated. Your
 suggestions of where logic needs to go is largesly based on opinion, and I
 largely disagree with the assumptions made here. Calling it "questionable
 design decisions with long-term implications" is laughable and
 reactionary, and I think we both know that.

 Two tactics here: focusing on synchronizing object stati with menu items,
 and handling this on generation. I frankly don't care which we go with,
 though I feel handling this on public generation would be far more
 versatile.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13822#comment:14>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software