Security page feedback and improvements

Projects Core Development
18

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.

4 Likes