-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow add_menu_page
& add_submenu_page
#254
Comments
It was mentioned, it was decided. No discussion really about the consequences happened. |
@joyously that's why yesterday we had a 90-minute meeting, where we discussed things. If you have any objections by all means feel free to say what they are. Is your objection regarding the decision itself, or the decision process? |
I was unable to attend yesterday's meeting, so I'll formally raise my objection here. What is the reason to break away from the standard Appearance menu and change the user experience? How many themes would truly benefit from having a top-level menu (in terms of making a better user experience)? What issues may arise from allowing top-level menus for all themes? I think it'd be good to discuss those things before pulling the trigger on this one. |
Both. |
With strict requirements it can be a good thing. I don't see any cons. |
I don't have any objections to users having a top-level item providing that it is a standard item, with no priority modifications and no custom styling. In my oppinion it neither improves or degrades user experience to have it a top level item vs having it under appearance. What could become an issue is the text users choose as their link title though or decide they want to add a fancy styled icon or do something crazy with the link colors. I am stronly in favor of the title being short enough to fit onto only a single line and matching the theme name however some theme names are very long and would wrap. A check could be added here to enforce a max length of the title. Traditionally users have had only the customizer as the only persistant place they can link to their page but use of customizer is dwindling due to the forthcoming FSE changes and also the ability to inline widgets through the editor now instead of going to customizer to add those. What is incresingly common is users using their activation notice to display information better placed on their custom page and team reps having to constantly contact those authors and request they change it. Allowing this more prominant location for a link could help to reduce that happening so often. |
I can't make time for people to attend the meeting but that shouldn't stand in the way of trying new things if those who were active thought it was worth trying. I think this is worth trying - or at the very least opening disucssions here about it. Everyone is welcome to pop by the channel and chat about it too :) |
The concern is that we limit things too much, and as a result authors will keep finding ways to circumvent the checks. |
Just out of interest: why allow a toplevel menu ? As there is a Note: I have no stake in this discussion, it is just a question which popped into my head when I read through the comments here. |
This was discussed and decided in yesterday's meeting.
Checks for
add_menu_page
andadd_submenu_page
should now be removed.The text was updated successfully, but these errors were encountered: