[wp-trac] [WordPress Trac] #35305: do_meta_boxes() does not display correctly with screen names that contain charaters outside sanatize_key()'s limits

[WordPress Trac]

#35305: do_meta_boxes() does not display correctly with screen names that contain
charaters outside sanatize_key()'s limits
--------------------------------+-----------------------------
 Reporter:  GregRoss            |      Owner:
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Options, Meta APIs  |    Version:  4.4
 Severity:  normal              |   Keywords:
  Focuses:                      |
--------------------------------+-----------------------------
 Specifically the "Screen Options" tab is not displayed.

 This is because WP_Screen sanitizes the slug where as add_meta_box() does
 not, resulting in each looking for a different key in the $wp_meta_boxes
 global.

 When WP_Screen->show_screen_options() checks the list of meta boxes for
 the screen it does not find any and does not display the "Screen Options"
 tab as it looks for the sanitized slug but the unsanitized slug was to
 populate the global.

 To make matters worse, add_menu_page()'s default behaviour is to return a
 screen name in the format of "toplevel_page_" + plugin_base(), which will
 include a / between the directory name and the file name of the plugin's
 main php.

 There are a few options on what to do to resolve this:

 1. Change the call to sanitize_key() to something else to support more
 characters in the WP_Screen->id field.

 2. Change add_menu_page() (and probably add_submenu_page as well) to use
 the same logic and call sanitize_key() on the slug before it is returned.

 3. Update the documentation and note the incompatibility but leave it be.

 Option 1 and 2 both have significant impact on existing code and plugins.

 In option 1 any code that relies on the slug being safe to use in SQL or
 other places would have to be reviewed.

 In option 2 any code the has hard coded a menu slug based on the current
 behaviour would have to be updated to use the new slug that is returned by
 the code.

 Option 3 is probably the safest :)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35305>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform