I’m not a fan of forcing this behavior on plugins. A settings (or direct) link is fine if the plugin doesn’t have a top-level menu item, but, anything more than that is just messy and unnecessary. A lot of plugins use this space as a dumping ground for links to settings, docs, upsells, review requests, home-links, bug-report links, and every other thing they can think of. The worst ones add their own logos and custom styles, even though it looks desperate and tacky AF. A security link would just add to the mess.
More importantly – just like all those other links – a security link is not at all needed. After all, the security page will be a top-level item, not an obscure item buried who-knows-where. My feeling is that adding a security link to this space should remain optional (as is the current situation.) so those of us who don’t want it aren’t forced to add supporting code to remove it.
Core allows for plugins to insert themselves into the privacy functionality while not forcing them to display such a link. To me, it’s pretty much the same thing here, and it shouldn’t be forced. I find it to be needless clutter…and to remove it, I’d have to add needless clutter to my plugins. It’s like two wrongs trying to make a right. I’m voting against adding the link. Plugin authors can add this link if they feel it’s necessary and the rest of us shouldn’t be forced to undo it.
But you’re looking at this from the PoV of a plugin author - I’m trying to look at it from the PoV of an end user. I know I’ve found the “Settings” link a lot of plugins add to be a useful shortcut; I imagine end users would feel the same about a “Security” link.
Also, the fact that some plugin authors abuse that area shouldn’t prevent us from adding something useful; if anything, we should curtail that abuse.
As I said, I’ll think on it some more and probably do a poll.
Not true. I’m looking at if from the PoV of an end-user, same as you are. I’m just not interested in adding redundant clutter to an interface (as an end-user), or to my plugin to remove it (as an author).
You don’t find the “Settings” link a lot of plugins add useful at all? I really do - I think it’s a very useful shortcut, and to me a “Security” link would be just as useful. Sure, it’s not something you use every day, but a little redundancy in a system can make it a whole lot easier to use.
In the more monolithic plugins that do not have a top-level menu, yes, the Settings link is helpful. In all other cases, it’s needless. However, it’s already been there for a long time and everyone expects it, so, I deal with it. I’m not saying remove all the existing links, I’m advocating for not cluttering it further.
A little redundancy here, a little redundancy there… is one of the recipes for code-bloat.
Anyway, there’s no sense our going back and forth in disagreement. We’ve made our points. It’s time to get back to work.
I think is just about a personal way of working. I install a plugin and get back to the plugins page. Now is time to setup the plugin, and I like to see a link to the settings right there. If there is no link it takes 2 seconds to find the right menu item. But maybe some people don’t espect to have to configure something about security elsewhere. Security menu is pretty new!
I agree with you @anon71687268 about bloat, but if you don’t want the link you don’t have to remove it and just use register_submenu_item().
Remove the $capability parameter for this function, it should always be manage_options. A multisite with super-admins who want to limit what “regular” admins can do is a separate, advanced problem that should be solved separately, using e.g. custom capabilities code for the multisite.
Don’t automatically add any (more) links to the plugins screen, this screen is already cluttered and there’s no way to tell whether a plugin has already used up all of the available space for their own links. I doubt we need another way to make plugins’ security settings easier to find, since they will already be accessible from the security menu, but a set of links from the “main” security page might be something to consider also.
$capability is going as I’ve yet to think of any reasonable scenario where it’s not redundant
$menu_slug must match an active plugin slug; you’ll get a “doing it wrong” otherwise, but only if WP_DEBUG is true as there’s a performance hit
No “Security” link. I’m experimenting with adding a dashicon instead - I think that’s a good compromise - and I’ll update the PR later tonight so people can have a play. It’s trivial to remove so there are no time implications
The screenshot is from a mockup, but yeah, I can do a boilerplate plugin - might even have time to do it before release, but as all the info is on the security page I don’t think this is a blocker.
As a plugin developer this is certainly something I would want to see. Agree not a blocker for release, we can link it up to whatever page we use to document this.
