Security page feedback and improvements

[anon71687268]

@viktor

I was thinking, since ClassicPress introduced Security page should we consider making it into a requirement for security settings to be added to the Security page? Developers like to add top level menus or add menus to the Settings, so it might be a good idea to require them to use Security page so it can be used to its full potential. Otherwise it will remain largely unused.

The reasons it remains largely unused are because the code was rushed, it seemed more like a vanity project than something useful for the community, and, ultimately, wasn’t implemented very well.

I ended up writing a gist to “fix” my local installs. This is one of those things that sounded good on paper, but, didn’t pan out in the implementation. IMO, the security page should just be removed; the person who created it is gone and I can’t think of a single person willing/able to work on it any further.

---

Here’s the gist if anyone needs it.

https://gist.github.com/johnalarcon/d6429389c5740320ec62c760b3ab13e3

[azurecurve]

I don’t think we should be mandating that security related plugins use the Security menu as it will ne another barrier for developers who want to support both.

Plugins which create a top level of their own is usually because their is a CPT and /or complex settings which are broken out to make things easier for users. I don’t think we should be mandating developers change this.

[azurecurve]

@anon71687268

the security page should just be removed

Removing it has the potential to break things, so probably too late to remove it.

[viktor]

Thanks for providing feedback. I didn’t realize it had problems. Getting feedback like this directly from developers definitely helps us understand the problem better and what we can do to improve it. Would hate to see us add code bloat with new features that don’t work as expected.

I would love to get a bit more feedback. The idea was and still is to unify all security settings in one place, so users can easily find settings they are looking for. You were in favor of this feature initially, does that mean this feature can still be useful if it can be improved? Or should it be removed completely?

In the Gist comments, you mention you already have a Security entry in the menu so now you got 2. The whole point behind the Security page is to unify security settings, so doesn’t it make sense to integrate with the Security page and instead of adding a new menu item simply rely on the built-in one?

Lastly the shield icon. As far as I can tell, the menu icon uses built-in functions and CSS that are used for all many items in CP. So any issues with shied icon for the Security page would also be issues for the rest of the menu items. Am I missing something here?

Thanks, I appreciate your feedback.

[viktor]

@azurecurve

Removing it has the potential to break things, so probably too late to remove it.

Have you used it in any of your plugins? I’ve yet to see any plugins use it, but I haven’t used that many. So I’m curious to see it in action.

[azurecurve]

@viktor

Have you used it in any of your plugins?

No, I add my plugin settings to my own top level menu.

[anon71687268]

@viktor

Getting feedback like this directly from developers definitely helps us understand the problem better and what we can do to improve it. Would hate to see us add code bloat with new features that don’t work as expected.

There was a lot of discussion around it and I shared the same feedback before writing the gist. I’d guess that was about 2 years ago by now – it got lost in the mix, I guess.

@viktor

The idea was and still is to unify all security settings in one place, so users can easily find settings they are looking for. You were in favor of this feature initially, does that mean this feature can still be useful if it can be improved? Or should it be removed completely?

Yes, it can be improved – the gist shows a couple of cosmetic improvements, for example. I played with it in a mocked-up plugin and didn’t care for the implementation. IIRC, the docs were also on the slim side. The effect of removing the page would be little-to-none, I suspect. Probably the main issue was that there was a lot of discussion, but, there was never any developer buy-in. In the end, it was sort of, “Here’s the security page. You can use it if you want.” I spoke to the developer (who created the page) about this long after the fact and he agreed that the stakeholder buy-in wasn’t present.

@viktor

In the Gist comments, you mention you already have a Security entry in the menu so now you got 2. The whole point behind the Security page is to unify security settings, so doesn’t it make sense to integrate with the Security page and instead of adding a new menu item simply rely on the built-in one?

Every security (specific) plugin has a ton of screens. Should all these screens be injected into the security page and sub-navigated via the designers idea of how to lay it out? Is there a sub-page mechanism to make it look native? What about other plugins that inject a setting or two – how should these be presented? What about a plugin that does something similar to another plugin (security-wise) – in the security page, they are not likely to be grouped in any meaningful way. These are a few questions that arose when I played with it. Virtually every plugin author has a certain design aesthetic by which they lay out their screens/data – if all these styles reach the security page, it will be a mess.

@viktor

Lastly the shield icon. As far as I can tell, the menu icon uses built-in functions and CSS that are used for all many items in CP. So any issues with shied icon for the Security page would also be issues for the rest of the menu items. Am I missing something here?

Yes, it’s all core stuff. What it isn’t is consistent in this interface. Plugins that do it right use a text-link in this interface, not an icon, logo, or graphic. Core using an icon here is inconsistent with the current display and sets a bad precedent that others will most definitely abuse. I can think of at least one CP plugin that already defaces this area with notices and marketing. Anyway, the icon was also poorly placed, had a needless divider that was overlooked, and an icon is less translatable than plain text.

[gellenburg]

What if the Security Page was moved out of core and into its own plugin, that way it could be updated at its own schedule (if and when there’s a new maintainer?)

Then the recommended guidelines could be for plugin developers to conditionally check to see if the Security Page plugin is installed, and if it is to move security settings there, but to fall-back to doing their own top-level menu if they desire.

But not make the Security Page be a requirement.

Just a thought.

[anon95694377]

To me, the security page always seemed to be a case of adding something distinct to CP for the sake of doing so.

Speaking as a plugin developer, any of my plugins that have security related settings are likely to have other settings as well, and I will always choose to put all plugin settings in the same place, on a page dedicated to the plugin, so it can be found by name in the admin menu.

[timkaye]

I have always seen it as a great place to hook in mu-plugins and that’s how I use it. Yes, I do use it and actually find it helpful.

[viktor]

Thanks, Tim. That looks great. Based on the feedback, I’m thinking out loud here, I see two possible ways forward with the Security page:

1. We move Security Page to a core plugin, so it can be used as needed.
2. We keep it in the core but disable it by default, so a plugin or theme could activate it if they are using it. Something similar to add_theme_support() function.

Right now it sits empty for most websites and with feedback from plugin devs it might be seldom used in particular situations. We want to avoid code bloat, so we shouldn’t be adding any new bloat after removing WP’s bloat.

Would love to hear what everyone else thinks.

Adding new features to the core must be done with developer and user buy-in. We don’t want to do what Gutenberg has done and avoid this:

@anon71687268

there was never any developer buy-in. In the end, it was sort of, “Here’s the security page. You can use it if you want.” I spoke to the developer (who created the page) about this long after the fact and he agreed that the stakeholder buy-in wasn’t present.

This is not what we want or need.

[viktor]

Reading some old threads about the security page, I found a petition thread for this feature. I guess the last comment on that petition says everything about it:

@discobot

Unfortunately many of the proposals for ClassicPress are a hodgepodge of niche personal whims and not explainable in terms of consistent logic or philosophy as far as a CMS goes; I think much of this needs to be more thoroughly considered and discussed to avoid impulsive code changes…

And as per some of my other comments, let’s keep in mind that we are all advanced users, and the success of WordPress is making things easy to understand and use for newbie users (e.g. the UI) while allowing for developers and web hosts to manipulate advanced settings using code-only.

What’s interesting, the original petition called for some security-related settings from the core to be added to the page. So the feature was implemented without following through on a petition many have voted.

[timkaye]

I think the original idea of having it under Settings is still the best one. It shouldn’t be a top-level menu item, because it’s not something to be used very often. But I still think having such a place for security-related settings, especially in mu-plugins, is an excellent idea.

[viktor]

In addition to moving it to Settings, what do you think would be a better approach: disabling it by default and enabling it if plugin/theme adds settings to it, or moving it to a core plugin? The page will be empty most of the time, which is useless to users and takes up menu space. So we need a better approach to it.

[timkaye]

A core plugin sounds a good idea and consistent with our general approach.

[viktor]

In addition to moving the security page out of the core to a core plugin and making it a Settings sub-menu I think it would be a good idea to still figure out a way to offer unification of security settings based on the feedback from plugin devs.

One idea I have, instead of putting settings on the page why don’t we encourage plugin devs to simply “declare” they offer security settings which would link to their own security settings pages? (If there’s more than one page, it would link to the main or the first settings page). This would help users find all the security settings their plugins and themes add to ClassicPress in one place, but keep it independent for plugin devs to do what they want. Here’s a mock-up of what I’m referring to:

We could offer plugin devs an option to include a summary of what security settings their plugins add. You can see it in a form of a bullet list under Classic SEO settings.

Actual settings can still be added as desired, that won’t change.

I would love to hear what @anon71687268 @anon95694377 @azurecurve think as plugin devs. And @gellenburg with his IT security experience, and @timkaye as an actual user of the security page.

Let’s get that developer/user buy-in to make this a better feature for all

[gellenburg]

@viktor

One idea I have, instead of putting settings on the page why don’t we encourage plugin devs to simply “declare” they offer security settings which would link to their own security settings pages?

I am by no mean a UI/UX expert but anything that simplifies finding the items I’m looking for is a win in my book.

One of the things that is incredibly frustrating though (from an admin perspective) is the convoluted mess we have today with every plugin author doing something just a little bit different.

If you have multiple plugins installed, from multiple vendors/ authors then the chances are one plugin uses radio buttons, another plugin uses check boxes, another uses sliders.

Some default to having options turned on, while other default to having options turned off.

I have to consciously remember does selecting an option actually enable a feature or disables a feature instead.

Maybe ClassicPress should enforce a whole settings paradigm where ClassicPress could provide a UI framework not just for security settings, but also for other general settings. Then plugin authors could interface with that framework.

Where a plugin’s settings becomes a child object of the parent CMS settings?

That way you could enforce some uniformity and UI/UX standards behind the scenes.

Plugin authors could still have their “promotions” but they would be confined to their plugin settings “tab” or page or what have you.

For that matter maybe it’s worth adding to core an API for displaying different (and STANDARDIZED) types of alert messages (Info, Warn, Error, Debug, etc. with an optional minimum role to show the alert to) to the admin that plugins could call so they all don’t have to roll their own too. Again just a thought.

But as for providing just a link on a page? I don’t think that would be very helpful.

The vast majority of plugins have no specific security settings, unless you’re actually talking about a *press “security” plugin like WordFence, etc.

Just my $0.02.

[james]

I agree with the criticisms of the Security page raised in this post.

I think the security page could have been a pretty good idea if it had been developed hand-in-hand with plugin developers. I gave similar feedback multiple times during the development of this feature, and also suggested adding a few example settings to demonstrate the value of this addition. This feedback received responses such as “we have to ship it first, then we will work on marketing”. Then, later on, “that’s not important, once we do this amazing thing then people will just flock to use it”.

After creating a petition for this feature, there was fairly wide agreement (though not universal), the petition had a large number of votes, and the code for a minimum viable product existed. I also wanted to give this a chance to succeed. But finally, the person who was leading this effort decided not to continue contributing to ClassicPress.

How can we move forward? A few ideas:

1. We can change the shield icon link to say Security on the plugins page (the second icon in this image) in the next minor release of ClassicPress after the corresponding code change is submitted and approved on GitHub. This is one of the things that @anon71687268’s gist fixes. It was done this way based on the preference of the original author, but this is non-standard and not as accessible as a plain text link. I think this is a pretty obvious win and I can’t think of any drawbacks to going ahead and doing this.
2. We can hide the Security page when it is empty. This would need to be done in a new major release of ClassicPress, and honestly I’m not a huge fan of this change because it leads to somewhat “magical behavior”.
3. We can add a new option for this behavior: “Hide Security page when empty”.
   3.a. If this option is disabled by default (i.e. the Security page is shown when empty, as it works today), then this can be added in the next minor release of ClassicPress after the corresponding code change is submitted and approved on GitHub.
   3.b. If this option is enabled by default (i.e. the Security page is hidden when it is empty), then this would need to be added in the next major release of ClassicPress after the corresponding code change is submitted and approved on GitHub.
4. We can remove the Security page from the codebase completely. This would need to be done in a new major release of ClassicPress, and any existing code that calls add_security_page would break upon upgrading to that version. Although this is an option, I don’t really see the need for it, because the existing code for the security page is minimal, with basically no performance impact and no other risks that I am aware of.
5. We can begin adding our own useful basic security settings to this screen, which would improve its usefulness and hopefully alleviate most of the issues raised here. This is the most difficult path from a technical perspective (security-related code changes are hard to do correctly) and from a social perspective (there would be a lot of debate about what to add and how it should work, and misconceptions about security are extremely common). Unlike most of the other proposed changes, this would be a larger project and we would need someone with experience in web security programming to volunteer to lead it.

Please discuss and voice your preferences. To keep things organized, please use the same numbering that I’ve used above when indicating support or opposition for any of the options I’ve listed.

[anon71687268]

@gellenburg

If you have multiple plugins installed, from multiple vendors/ authors then the chances are one plugin uses radio buttons, another plugin uses check boxes, another uses sliders.

This is also my concern with the security page – each plugin injecting its own CSS to make their settings “branded”.

@gellenburg

I have to consciously remember does selecting an option actually enable a feature or disables a feature instead.

This is a shortcoming of the label used to describe the particular input(s). In cases of enable/disable (et al,) the label should describe one or the other.

@gellenburg

Maybe ClassicPress should enforce a whole settings paradigm where ClassicPress could provide a UI framework not just for security settings, but also for other general settings. Then plugin authors could interface with that framework.

The Settings API already gives developers exactly what you’ve described here. However, it’s not all that robust and lacks support for modern HTML elements (IIRC.) For these reasons (not even to mention branding, and just plain vanity,) most developers roll-their-own solution. There’s really no way to enforce a UI/UX standard; a recommendation is about all you can do.

@gellenburg

Plugin authors could still have their “promotions” but they would be confined to their plugin settings “tab” or page or what have you.

This has been encouraged for quite some time in the WP space and CP developers seem to be falling on it as the default – that is, “keeping their screens and notices to themselves” where they belong.

@gellenburg

For that matter maybe it’s worth adding to core an API for displaying different (and STANDARDIZED) types of alert messages (Info, Warn, Error, Debug, etc. with an optional minimum role to show the alert to) to the admin that plugins could call so they all don’t have to roll their own too. Again just a thought.

This already exists. Some use it as intended; many abuse it. This functionality is why many WP dashboards are a disaster.

[viktor]

Referring to @james answer:

1 - See, I didn’t even realize that’s what @anon71687268 was referring to. I thought he was referring to the icon in the main menu. We need better documentation and an example for this probably. I do agree that the icon alone isn’t the best option and should be replaced with a text link.

2, 3, 4 - If you think it’s not an issue to have it there, I’m OK with it. What do you think about moving the menu to Settings sub-menu?

5 - I would prefer to go with 3b option, hiding security page by default if empty, unless we do add a few default options that a user can take advantage of. The obvious choices would be an ability to disable XML-RPC and REST API, but if we’re moving them to core plugins those options might not be needed.

A few simple options to consider adding to the security page that some security plugins have:

• Option to enforce specific password strength for all users
• Remove generator tag and/or general clean up of the <head>
• Enable SVG support (this would require adding SVG support which would be nice)
• Disable (or make them generic) login error messages

These are just suggestions.