[wp-trac] [WordPress Trac] #37782: Duplicate Page Entry in View All Pages when generating a Menu

[WordPress Trac]

#37782: Duplicate Page Entry in View All Pages when generating a Menu
-------------------------------------+-------------------------------------
 Reporter:  garrett-eclipse          |       Owner:  garrett-eclipse
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  5.2
Component:  Menus                    |     Version:  3.0
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-unit-      |     Focuses:  ui, administration,
  tests commit                       |  privacy
-------------------------------------+-------------------------------------
Changes (by garrett-eclipse):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests commit


Comment:

 Thanks @xkon for the testing and CS update.

 @audrasjb I appreciate the testing and catching the missing tests, that
 was my fault I'd started with a clean install between diff 8 & 9 and
 forgot to `svn add` the new tests file. It's included with the last
 revisions I'd mentioned in #9.
 *Also thanks for noting the Customizer Menu, I did overlook that. I opened
 a separate ticket (#46829) to address that in a future release.

 @birgire thank you for your testing and unit tests. You'd provided some
 additional feedback and I wanted to address that in order to not leave any
 loose ends;
 > - Performance consideration using `post__not_in` on a large db.
 > - Could it behave like sticky posts, without modifying the query, where
 duplications only removed (via PHP) on the first page.
 This I assume stems from the WPVIP articlet
 (https://vip.wordpress.com/documentation/performance-improvements-by-
 removing-usage-of-post__not_in/);
 >Using `post__not_in` means that the query cache hitrate will often be a
 lot lower. It can also make the query slower if the exclusion list is
 large.
 The hitrate issue shouldn't be a problem as once pages are set in options
 they'll be fairly consistent. And with the exclusion list having a max of
 3 the list shouldn't be too large to slow down the query.

 > - Introduces new function get_post_states(). Name too general? Is there
 any guideline on when to use wp_ function name prefix? Should it be
 private? Didn't find such a function in wp.org plugin directory though.
 > There exists get_post_status(), get_post_statuses() and
 get_post_status_object() (not the same functionality though)
 The new function was a way to splice an existing one to serve two needs
 which I felt better than creating a completely unique functionality for
 this. The get_* methods in core don't provide the wp_ prefix in most
 cases. And I expect it can be useful in other places such as Customizer
 Menu.

 As the latest patch just re-introduces the missing unit tests going to
 move this back to commit but would love a final re-test from interested
 parties.

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