Set_screen_options() ignores many page names. add_menu_page() and friends breaks others. Etc. — at Initial Version
|Reported by:||Mick P.||Owned by:|
This gem breaks screen option support for screen names with non-matching characters.
If your screen name is generated from add_menu/submenu_page() and you go the slug route, you can make ?page= style pages which have characters such as / ... even though that is not very slug-like. Ironically if you choose a slug with a dash (slug-like) your page will not be accessible.
However if you want set_screen_options to work, you are then limited to a-z and underscore. I thought underscores were not allowed in slugs, but I might be wrong.
So unless you want to use underscore in your page url (which looks real bad for some reason) you are limited to single word page names.
The problem with single word names is they often collide. So I don't know if my "revisions" page might clobber some other "revisions" page for example. So I might want to stick in a / to create a kind of namespace, but no that won't work (see above)
Final thought. It's pure folly to be generating the screen names from the menu. Admins/users have every right to want to customize their menus at some point, and in doing so they would totally break the screen framework from the plugin POV. Many pages in the codex suggest sniffing out your screen name and hard-coding it BTW.
Screen names should be synonymous with page permalinks. Admin pages should ideally follow the same slug guidelines as blog pages, so if you wanted to you could rewrite them. Dashes should definitely be allowed in an admin page slug/screen name. And probably slashes should also be respected indicating a hierarchy of slugs.
Screen names should be purely based upon the page name. They should not incorporate the top-level menu. Even if you have A) the internal menu, and B) the reworked menu that is written to the page, it's confusing. I realize the menu system needs a lot of work, so please think about.
Finally, as it stands, this makes it frightening to code a plugin with screen options support. And makes it impossible to add screen option support to many plugins with more exotic page names. If you do so, then you are limited to more or less to page names which will likely collide with names that other plugins would like to use, or even WP itself might use if WP intends to use this framework in the future.