I updated my sites to v6.2 and can no longer update premium plugins from the dashboard or directly on the child site. I rolled back to 6.1.8 on the child site and can update premium plugins again. I have tested multiple premium plugins across vendors with the same result.
WP 7.0.4
PHP 8.3
Hey @7thcircle
In 6.2, we introduced a new Premium Updates page under MainWP > Settings > Premium Updates, along with changes to premium-update handling. We’ve reviewed those changes, but haven’t confirmed what’s causing the failures you’re seeing directly on the child sites.
1/
Was your MainWP Dashboard also running 6.2 when this happened, and did it remain on that version after you rolled MainWP Child back to 6.1.8?
2/
Please test with both MainWP Dashboard and MainWP Child on 6.2, using just one affected child site initially.
3/
Also, before upgrading, were you using the premium-plugin compatibility snippets from this guide, through the Custom Dashboard Add-on, functions.php, or another method?
I do have all of the premium plugins listed using the code snippet in the custom dashboard and they have been working prior to 6.2
Both the dashboard and child MainWP plugin were at 6.2.
The part that makes no sense is that when I go to the child site directly and try and run the premium plugin update it fails with 6.2 but if I roll back to 6.1.8 it works.
I have started the process of adding the premium plugins that were missing to the new premium updates page and will try the update again tonight.
I have added all of the current premium plugins to the new section and then tested the update for ACF PRO on 1 site and get the below error. This plugin I was able to go to the child site itself and run the update.
ERROR on the child site: Unauthorized access.
There are no errors in the child or dashboard logs.
Thanks, that error helps narrow this down.
In 6.2, we added an additional permissions check when MainWP requests a premium update.
It checks for WordPress’s manage_options permission, which administrator accounts normally have. MainWP Child returns “Unauthorized access” if that permission check fails during the request.
Do you currently have any other premium plugins with updates pending on an affected child site?
If so, please open a support ticket so we can take a closer look while an update is still available and investigate why that check is failing.
All site admins have the manage-options permission. The other piece that may help is all of the affected sites so far run Redis Object Cache (some are Pro) and all of them run Redis Page Cache as well. I tested by clearing the cache and I can run the updates on the child site if I am on the child site but the update sin the dashboard are hit or miss. I will open a ticket and get you a site with a premium plugin to test.
That may be a indeed a useful clue. We will investigate further.
Great, thank you.
I have rolled back to 6.1.8 across my entire fleet because updates for premium plugins are broken and having to update them manually by logging into each site is not viable at scale. If it was possible to update 1 site and test it might be a different story.
Sorry to hear that.
We haven’t been able to reproduce this on our Dashboards yet, but we are still investigating.
If you’d like, please do open a private ticket so we can examine your setup.
After upgrading to MainWP Child 6.2, premium plugin/theme update detection began failing on sites protected by Snicco Fortress with:
Unauthorized access
PREMIUM_ACTION_ERROR
WordPress.org plugin updates continued working normally, and premium plugins could be updated directly via WP-CLI, so the problem was isolated to MainWP’s premium-update path.
Tracing MainWP Child showed that 6.2’s new simulate_admin_visit() method checks:
current_user_can( 'manage_options' )
before performing the simulated admin request.
The MainWP connected user was successfully authenticated as an Administrator, but Fortress’s sudo-mode capability protection was filtering protected capabilities from the remote session. As a result, manage_options was false even though the connected user was the correct Administrator.
This appears to be a compatibility regression introduced by the new premium-update mechanism in MainWP Child 6.2. MainWP Child 6.1.8 did not use simulate_admin_visit() or this manage_options check for premium update detection.
I confirmed the cause using Fortress’s current DeterminingProtectedCapabilities event. Allowing the necessary protected capabilities for trusted MainWP process_premium_updates requests immediately changed premium detection from:
Unauthorized access / PREMIUM_ACTION_ERROR
to:
success => 1
I then tested an actual premium plugin update through MainWP. MainWP returned PREMIUM_ACTION_REQUESTED, launched the upgrade, and the plugin updated successfully.
So the issue is specifically the interaction between MainWP Child 6.2’s new premium plugin/theme update mechanism and security systems such as Fortress that restrict administrative capabilities when a remote authenticated session has not entered sudo mode.
It may be worth having MainWP review whether simulate_admin_visit() should depend on current_user_can( 'manage_options' ) in this context, since MainWP has already authenticated and authorized the remote request before reaching this code.
Thanks @7thcircle.
This matches the permission-check issue we identified, and we’ve prepared a MainWP Child fix that removes the unnecessary manage_options check.
Your findings explain why the connected user could be an Administrator and still encounter this error.
Would you be willing to test the patched version with Fortress enabled and your workaround disabled?
That would help us confirm the fix resolves the issue in your setup.
I would be happy to test it. I can push it to several sites later today and report back in the next few days.
Thanks, @7thcircle.
I’ve sent you a DM with the pre-release build.
I have tested the new build with 5 sites and 3 premium plugins and it looks to be working now. I have also not seen any sites disconnect since updating the dashboard.
Great, glad to hear that and thanks for letting us know.
We’ll have those fixes in the upcoming release.
A fix for this was included in today’s v6.2.1 release of the MainWP Dashboard and Child plugins.
Thanks again for reporting this to us.