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.
1 Like
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.
1 Like
A core plugin sounds a good idea and consistent with our general approach.
3 Likes
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 
2 Likes
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.
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:
- We can change the shield icon link to say
Securityon 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. - 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”.
- 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. - 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_pagewould 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. - 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.
4 Likes
This is also my concern with the security page – each plugin injecting its own CSS to make their settings “branded”.
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.
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.
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.
This already exists. Some use it as intended; many abuse it. This functionality is why many WP dashboards are a disaster.
3 Likes
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.
2 Likes
This would probably be the “cleanest” way to do it. In particular, it would keep the display clean and native without the risk of it becoming another ad billboard.
2 Likes
I don’t really understand why our security page is empty by default (and is empty after 3 years of life), while WP’s “counterpart” is useful, it is truly one of the perhaps most useful security things I have seen in WP so far specially for users.
Being it 5 months older than CPs version I was always surprised we didn’t back port more of them settings:
Site Health Check in 5.2 – Make WordPress Core vs. Introducing ClassicPress 1.1.0 | ClassicPress
I think the CP security page could be very powerful, but it is not right now. Right now it is something that hurts us, because we say “big” how we focus on security and that page is one of our “flagship” things we mention when we explain differences between CP and WP
However the only real difference is, we added some HTML to the Admin. Hoping that plugins will fill that page somehow is a risky game.
If we want to keep it which I think we should, then we should incorporate a bunch of things like WP’s page does.
Not all of those things, but several are very useful and are part of security.
Just my opinion, that right now, even having a link in there to some online post about security would make it a better instance than it is currently. I have removed it on my own CP Installs, because literally useless for me right now, even if I believe very much in its potential, and my next plugin (access controls) will rely on that page, right now it is a bit of a joke, which we should not advertise on our “cp is so much better” announcements/explanations, because it is like saying “I have the better jam” and then showing an empty jar.
2 Likes
Part of the problem is that we don’t have a workable plan for how to get these things included and polished enough to be worth shipping. Unfortunately, this is still true.
Agree, this is a problem, and while we look at what options to include by default and try to finish their implementations, this will continue to be an issue.
Therefore I am leaning towards options (1) and (3.a) above: fix the link that goes out to the Security page from individual plugins, and add a new option that leaves things as they are by default, but allows everyone to disable the Security page when it is empty. These are easy changes that can be done very soon, and these two changes together would remove the need for @anon71687268’s gist in the original post of this thread.
1 Like
Are you referring to backporting stuff? Maybe that’s what we should do, figure out a solid plan. For example, backport all security and accessibility-related changes that do not require the Gutenberg code, etc. This is related to the other conversation we had on Slack about creating a section in the docs for “standard operating procedures” so we have processes in place that we could rely on.
I agree that would be the easiest option. In code_potent’s Gist, he has an action to remove the security page menu because his plugin adds its own top-level “Security” menu item. What should we do in this case? Maybe move CP’s menu item under Settings?
As an order-of-magnitude estimate, this would take roughly 1,000 hours of experienced developer time. That is the main reason we don’t have a workable plan to get this done.
The Security page needs to be a top-level menu item because it expects to have sub-pages registered under it.
Just on a sidenote, inside the Security screen of current stable CP, we link to the page https://forums.classicpress.net/c/team-discussions/classicpress-security, which is dead ( Oops! That page doesn’t exist or is private.)
One of the issues with the security page is that if you have a security plugin (which is probably >90%) of sites, you’re stuck with two security entries on the top-level.
1 Like
The page that is actually linked to from within CP is https://link.classicpress.net/forum/security. This is a redirect and I’ve pointed it at the Core Development forum for now, so the link is effectively fixed even though the URL you pasted will remain dead. Since the Security forum no longer exists we will also need to update the wording in CP.
I am betting that those same >90% of sites have zero entries in the ClassicPress security menu, so with the addition of a new option that allows users to hide it, this issue would be mostly solved.
This is something we can do today. The other option that makes sense to me would be to just remove the security page completely, but that would need to wait until a new major version. It’s not as clear to me how to move the ClassicPress Security menu under Settings without breaking it, given that it expects to have sub-items when plugins register them.
2 Likes
Well, “solved” until they enable it.
Users would have that choice.
I agree with the concerns raised here, and I am looking for the best solution I can in the shortest amount of time possible. That means it’s not going to be perfect.
I started a PR: Security page improvements by nylen · Pull Request #779 · ClassicPress/ClassicPress · GitHub
2 Likes
Yeah, I know it won’t be perfect right off the bat; just noting that “solved” wasn’t really accurate there.
What if we rename it so it’s not a generic Security tab? Maybe Security Center, Security Settings, Security Options.
To go back to my previous suggestion, instead of creating sub-items in the menu plugins should create “cards” that link to their respective settings pages. As far as I can tell, that’s the only other option unless we introduce a separate menu on the Security page.
One thing to consider, if we agree that Security page should be sub-item of Settings menu then we should follow through with that and make top-level Security menu with sub-items disabled unless sub-items are added to keep it backwards compatible and not break any implementations. I doubt we would break anything but there might be a couple that use it.