Support

Thank you for reaching out. On a WordPress Multisite installation, Admin Tools is only accessible through the Network Admin dashboard, which requires a Super Administrator account (also known as a Network Admin).

This is not an arbitrary requirement; it is a security feature. Changes in Admin Tools settings apply globally (across all sites) due to the nature of security plugins, i.e. the fact that they can change your site's server configuration file (.htaccess) and the fact that their code executes before WordPress has resolved which blog hosted on the site you are trying to access. If we allowed regular, per-blog Administrator accounts to view and manage Admin Tools settings we would be introducing a major security issue, as each per-blog Administrator user could conceivably modify Admin Tools settings in such a way as to take over other blogs hosted on the WordPress installation, or even the WordPress installation itself. As a result, we elected to only allow the Super Administrator role to have access to Admin Tools for WordPress on WordPress multi-site installations since this role is explicitly assigned to manage the entire blog network, i.e. has the correct access level to manage settings which affect the entire WordPress installation, not just a particular blog hosted in it.

Based on the fact that you are getting a 404 error when trying to access the correct URL for Admin Tools in the Network Admin dashboard I suspect that the account you are currently logged into may be a blog-level administrator rather than a network super administrator. To access Admin Tools and unblock an IP address, please ask your network/server administrator to either:

1. Log in to the WordPress Network Admin (/wp-admin/network/) and go to Admin Tools from there; or
2. Grant your account Super Administrator privileges if that is appropriate for your role.

If you are unsure who manages the WordPress network for your installation, please contact your hosting provider or IT department.

We ask WordPress if you have the right capabilities. Somehow, WP reports you don't have the appropriate capabilities for the Super Admin role. There is nothing we could do on our end. You need to check what is going on with the roles and capabilities on your site, I'm afraid 

Let's try something different to see if it helps. Can you please download and install this dev release on your site: https://www.akeeba.com/download/atwppro-dev/2-0-2-dev202603101521-rev19588b49.html 

I cannot reproduce your issue. I installed a fresh copy of WordPress 6.9.4 and enabled the multisite feature. I even created two blogs in it with separate users. I then installed the same developer release of Admin Tools Professional (2.0.2-dev202603101521-rev19588b49) I linked you to.

I was able to see and use Admin Tools Professional just fine with the default Super Admin user.

IMPORTANT! Do note that the URL for Admin Tools' control panel page is /wp-admin/network/admin.php?page=admintoolswp%2Fadmintoolswp.php. The very important part is that the last bit MUST have the forward slash URL-escaped to %2F. If you do not do that, your web server might misinterpret that as an attempt to find a directory called admin.php?page=admintoolswp under /wp-admin/network which will, of course, result in a 404. Whether this happens depends on your server configuration, including your .htaccess content.

I then created a new user test in the network admin panel and gave it Super Admin privileges.

IMPORTANT! By default, even when using the Network Admin's Users page, WordPress creates a user for the main site, without any special privileges. To be able to use Admin Tools this user MUST be elevated to Super Admin, not just a regular Administrator. Super Admins can access the Network Admin Dashboard where Admin Tools and Akeeba Backup live. Regular Administrator can only access the content (posts, pages, widgets, config options, ...) of the main site. To do that, you need to edit the user after creating it and check the "Grant this user super admin privileges for the Network" box next to the Super Admin option.

I logged out from my regular Super Admin user and logged in with my new user test.

IMPORTANT! Do note that logging in with this user shows the main site's admin panel, NOT the Network Admin Dashboard. I had to go to the top menu, My Sites, Network Admin, Dashboard to see the Network Admin Dashboard.

In the Network Admin Dashboard I can see the Admin Tools sidebar icon. Clicking on it allows me to use Admin Tools Professional perfectly fine.

Do remember that both Akeeba Backup and Admin Tools will only appear in the Network Admin Dashboard which is only accessible to Super Admin users because they can be used to effectively escalate one's privileges to Super Admin, and have access to the totality of the information contained in your site. This level of access MUST be reserved for the highest privilege level available on your installation, i.e. Super Admin on WordPress multisite installations and Administrator on WordPress single-site installations. Anything else would be a privilege escalation and/or data leak vulnerability.

As far as I can tell, your problem appears to be that you are using the wrong URL with a user that does not have the correct privileges and you are looking for the plugin in the wrong dashboard. I am not blaming you. The WordPress multiuser experience is a mess. Having a main site dashboard and a network dashboard accessible by the same users with the same login URL is unconscionable.

Please do take your time. I am very curious as to what is going on as well. I have never seen anything like that in the decade I have been publishing this software for WordPress – with WP multisite installations supported from day one. 

If it would help, let me explain the access control used to display the Admin Tools icon in the sidebar and access the plugin, as well as why I am so insistent there's an issue on your end. There's a technical reason, it's not me being lazy. If anything, I dug deep into WordPress' code after my first reply to make sure I am not missing something.

We install two hooks, one for admin_menu (AdminToolsWP::adminMenu()) and one for network_admin_menu  (AdminToolsWP::networkAdminMenu()). Their execution is mutually exclusive; the former returns immediately if WordPress' is_multisite() returns true, the latter returns immediately if the same WordPress function returns false. Therefore, only the AdminToolsWP::networkAdminMenu() method runs on a multisite WordPress site.

This method calls WordPress' function add_menu_page() to add the sidebar icon. WordPress lets us apply access control for the icon by passing the desired capability; we tell it we need the manage_network capability – for a more human-friendly description of what this capability means look here. This is also how WordPress would know what to do with the /wp-admin/network/admin.php?page=admintoolswp%2Fadmintoolswp.php URL; if that code doesn't run, or WordPress decides your user does not have the capability requested it won't know that this page is meant to call AdminToolsWP::boot(), therefore you'd get a 404 error which is then caught by WordPress itself and presented to you as the same WordPress 404 error page you'd see in the frontend of the site.

This is why I am inclined to believe that you are not using the correct user with the correct capabilities. If you are not using the built-in Super Admin role, or if you have customised the role with a third party tool, you may have ended up with a role that has most of the default set of capabilities of the default Super Admin role shipped with WordPress, but not the manage_network capability. Possible? Yes. Likely? I have seen something similar to that once, in a single-site installation. It is far more likely to have the wrong user, wrong role, or wrong dashboard – those are problems I have seen quite a few times.

This definitely points to a problem on your site.

There's no routing to speak of. As I told you, WordPress will handle the page query parameter as long as there is an admin menu hook installed. This is the entire "routing" WordPress handles, the rest is internal to our plugin BUT that code is NEVER executed on your site as per your troubleshooting.

You said that the bootstrap.php file runs; that's the top of the plugin's main file. However, you also claim that the admin hooks are never installed. The hooks are installed in lines 65 through 76; the one you are interested in is in line 66. If this line is not executed it means the surrounding if-block's condition is false. However, the surrounding if-block is fairly trivial and easy to understand even if you didn't "speak PHP":

if (is_admin() && (!defined('DOING_AJAX') || !DOING_AJAX))

Either is_admin() returns false, or DOING_AJAX is defined and is true.

As you can see in the linked WP documentation page, is_admin() returns true when you're in an admin page. Since it relies on a constant set when you access any wp-admin page it can't really be false. Your site would be completely broken and you couldn't even access any admin page whatsoever.

DOING_AJAX is a constant in WordPress that indicates whether an Ajax request is being processed. It is used to check if the current request is an Ajax request, allowing developers to execute specific code only during such requests. It's used directly by core WP code, e.g.  wp_doing_ajax(). This MUST only be defined when accessing WordPress' AJAX endpoint.

If you are right about your troubleshooting so far, the only thing that makes sense is that you have some broken plugin setting DOING_AJAX.

You can add some logging before the if-block, logging the results of is_admin() and defined('DOING_AJAX'), as well as inside the if-block (output a simple "Inside if-block" into the log) and after the if-block (output a simple "Outside the if-block"). If your site is working you should be seeing TRUE, FALSE, Inside if-block, Outside the if-block in exactly this order. Anything else, your site is effectively broken.

Regarding caching, yes, PHP has OPcache. Make sure to configure it properly. There's opcache.validate_timestamps and opcache.revalidate_freq which can be set to 1 and 2 respectively to let you debug more easily. Though, having established your problem is very much site-specific (not server-specific) you can of course take a backup of your site with Akeeba Backup and restore it on a local dev server where you can debug it more easily in controlled conditions and without affecting production.