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.
I would go with CP Security to make it a bit clearer that it’s part of CP itself.
This is another option, but I don’t think it’s a good idea to make a menu item magically jump around depending on what plugins are installed on a site, this would also be unexpected and confusing behavior. “You might find Security under Settings… unless you have certain plugins installed… but it’s not easy to know which plugins those are…”
I would rather see it hidden in the v1 release series (based on a user decision, so that there are no back compat concerns) and removed in the v2 release series.
2 Likes
I think that’s a good way to proceed. For the name, what if we borrow from Site Health and call it Site Security?
I’m OK with CP Security if others like it, but would prefer something a bit more descriptive.
2 Likes
Good to see this is being discussed. I never understood the point of the extra Security menu item and ended up putting in some code to hide it as it seemed useless.
To support @viktor, CP Security suggests to me a specific security plugin developed by CP (like the SEO and Commerce options). Site Security sounds more generic.
1 Like
Here’s the mu-plugin I use to remove the Security stuff. It’s based on Code Potent’s gist but simply removes the Security icon instead of replacing it with text.
<?php
function zp_remove_security_menu() {
remove_menu_page('security.php');
}
add_action('admin_menu', 'zp_remove_security_menu');
function zp_remove_security_icon() {
if (!function_exists('\add_security_page')) {
return;
}
foreach (array_keys(get_plugins()) as $plugin) {
$func = '_security_page_action_links';
$hook = 'plugin_action_links_'.$plugin;
if (has_filter($hook, $func)) {
remove_filter($hook, $func, PHP_INT_MAX);
}
}
}
add_action('load-plugins.php', 'zp_remove_security_icon', PHP_INT_MAX);
Just save this as remove-cp-security.php or any name you like, and drop it in the mu-plugins folder.
Just a few comments here on this topic:
-
I wouldn’t prefix anything with “CP”, such as “CP Security” to make it clear that it’s native to CP. Users aren’t thick and they don’t need to be reminded that a feature is core to CP. That’s counter-intuitive. It’s actually the other way about. Have a look around WordPress’ admin to see anything prefixed with WP - the only real examples I found was plugins/themes use the “WP” prefix.
-
We have a security plugin and frankly it’s impractical to use the Security page when we have so many pages in our plugin itself.
WP has actually created quite a useful sub-tool through Site Health which does a great job in encompassing many different elements of the site, including security. This Site Health tool has been mentioned in this thread but I get the sense that if it’s in “WP Core”, then you don’t want it in “CP Core”. That’s also counter-intuitive. The ideal approach is to take the best parts and ideas of what’s out there and incorporate where you can. Copy if you have to. -
Whichever approach is taken, some serious thought needs to be given to the practicalities of implementation for a new feature both from UX and developer standpoints. Was there any in-depth digging into what the Security page would and should be? From some of the earlier comments on this page, it sounds like it was partly a user-voted project and a way to help distinguish CP from WP.
Simply moving it to a submenu, or changing its name, or whatever bandaid doesn’t solve the underlying problem. My suggestion would be to removing it entirely and bringing it back in another form once it’s been thought over.
It can be done at any time by removing the top level page for everyone by default (i.e. it’s empty/unused), and where someone, or a developer, has actually used it - which appears to be a small minority based on this discussion - only then it gets rendered.
I actually think having a cental security hub/page is a good idea, with a few CP Core settings supplied with a developer api to extend it. This is probably best as part of a “Site Health” -equivalent section. If you name it “Site Security” then it’s all about “Security”. If you name it “Site Health”, then it can be adopted for many different applications.
-
If you make this a “Core Plugin”, then you’ll restrict developers’ ability to integrate since no-one is going to write an integration with something that may or may not be available on most sites. Unless you have a dependency management system. Does/Will CP have a dependency management system?
-
I wouldn’t provide an “option” to enable/diable the menu. After developing a massive security plugin for a few years, one thing I know is this: users don’t need any more options. If you’re going to make it optional, make it a filter.
Just a few random thoughts.
6 Likes
Thanks for sharing your feedback, Paul. It’s good to get feedback from a developer of a security plugin.
That was discussed and I believe it’s in the plans, but no concrete plans on when it might be implemented. @james might be able to answer this question.
This is all started with this petition and as implementation began it stopped short of implementing additional features because the developer doing the work left.
I think combining the security page with the Site Health tool/page would be a good idea. There is a petition for Site Health.
I actually found a way to remove this menu, without breaking backwards compatibility, without requiring Developers to do any further work than the usual function needed to add their submenus in that menu…
Pushed change to Git here:
This is perhaps not perfect, but it removes that stain which the Security page is.
Once we decide that we have time, commitment and actual ideas to put in there, we can simple as delete a line of code, add it back.
Plugins which use the page are not going to break.
I hope we can see that this is a first step towards a CMS that can be taken serious. This page really is a joke and each time I propose CP to a client I hope to god they will not notice it.
It is nice if there is something inside.
But the current state (vanilla core) is just really not useful.
If a plugin manages(d) to add useful settings there, then that is cool and it still will work just as usual.
Yes, it “magically” adds/removes the menu page. But … I prefer a tad magic than a fist in the face of “looks cool but does nothing”
2 Likes
@Simone found an issue with this, which is that if a plugin loads the security page add_security_page on admin_menu hook, it will not show the menu.
The add_security_page doc unfortunately does not state when to load this. When you load it in init, which is typically used by plugins to initialize, the change I made will work.
So now we have a situation where we need to decide what is even expected to work. Let’s not have another “because it broke a plugin we do not change”.
The right thing IMO is to state in an api when it is available and when it is too late. I think init is not a bad hook for something like this.
Hooks that will work are
init, plugins_loaded, wp_loaded, for example.
@timkaye - you are the other dev I know using this function.
When do you hook it?