Support

This is not possible in WordPress. There is no per-plugin access control like there is in Joomla!.

As I said, the problem is that the CMS itself does not offer this functionality. However, this doesn't mean I am an idiot who allows users with inadequate privileges to execute privileged functions! If you had tried accessing Akeeba Backup as an Editor you'd have known.

Network and CMS access control are unrelated. What network? Windows? UNIX user/group? Linux ACL? Novel, assuming you're of a certain age (I had the misfortune despite being only 43)? Each one had its own model which is fundamentally different in concept than the next. Which CMS? Joomla? WordPress? Each CMS has its own model which is fundamentally different in concept than the next. Am I supposed to be impressed by your non-transferable skills in an adjacent but unrelated IT field? I have 25 years of experience in network and server administration, and 18 years of experience in CMS access control. So what? Only the latter is relevant to this discussion.

Moreover, invoking your 25 years of experience when you have obviously not even checked that what you complain about actually happens has the exactly opposite effect than what you intended.

Having established that your experience is irrelevant and invoking it a liability, let's take a look at how things actually work.

In Joomla!, it is the CMS offering the access control functionality, not the extension. Lacking this CMS functionality, we used to map WordPress' roles to the internal permissions in Akeeba Backup. However, roles are inadequate, because it is perfectly possible to create a custom role functionally equivalent to an Administrator without calling it an Administrator.

This is why since 2017 we are mapping WordPress capabilities to the internal permissions in Akeeba Backup. We allow full access to the plugin to users with the activate_plugins capability and deny it from everyone else. The thinking here is that if you have this capability you can install and enable any custom plugin, i.e. you can run any and all arbitrary PHP and SQL code against the site. In other words, this capability gives you God–level access to the site. Therefore, whoever has this capability is trusted enough to do far more than what Akeeba Backup does.

In the past, Editors could take backups (and only that). People like you complained that on WordPress sites they really did not want grunts to even take backups, so I removed that in 2023. Now the activate_plugins capability is required for doing anything, even taking a backup.

The corollary to that is that Editors can do absolutely nothing whatsoever in Akeeba Backup. If they click on the link they see an interface which only allows them to see the CHANGELOG of the currently installed version. That's the beginning, middle, and end of it. They do not “have any control over backups”. Something you could have easily verified yourself if you tried clicking on the menu item link before coming here.

As to the menu item, yes, it is displayed even to users who have no access to the plugin's features. This is not an oversight, it's a side-effect of WordPress lacking in access control. Joomla! only loads extensions the currently logged in user has access to, i.e. determining user permissions precedes third party software loading (with the exception of authentication and api-authentication plugins, the authors of which know what they are getting into as they are a very specialised type of software – and I can say that as someone who's written core Joomla and third party plugins of that type). WordPress is, well, bass ackwards. It loads all plugins before it determines access control for the user. The problem with that is that what we have available at the time WordPress loads the plugin, when we need to register the plugin hooks (because the plugin architecture is primitive compared to any other major CMS or e-commerce application), is the is_admin() core function. This does not check user roles or capabilities – which are not loaded yet at this stage – but only whether we're under wp-admin. Therefore, we register our handler for the admin_menu hook if we're in WordPress' administrator, regardless of the user role or capabilities.

But, surely, I could check permissions before adding the icon in the admin_menu hook, then? That's what I thought, too! To test it, I created a custom role (with a third party plugin) that had the activate_plugins capability, and logged in with a user assigned to that role. The menu item wasn't there. I never figured out exactly why, but I did find out that not checking for capabilities when displaying the menu item was an adequate solution. And that's why your Editors see an Akeeba Backup menu item which allows them to do absolutely nothing whatsoever. To cater for the case of custom roles.

The menu item is just a menu item. Displaying the menu item DOES NOT say anything about the access control in the application itself. Access control happens within each and every controller of the application (see \Solo\Controller\ControllerDefault::aclCheck). The privileges it checks against are defined in \Solo\Application\WordpressUserPrivileges::onBeforeLoad where you can see the WordPress capabilities to Akeeba Backup privileges mapping.

So, yes, it's not possible to hide the otherwise pointless menu item from Editors because of the way WordPress works, exactly as I said in my previous reply. No, we do not allow Editors to manage backups.