Plugin causes admin permission error
-
This is a weird one. When sg-cachepress is enabled, on one multisite I am unable to save the WordPress general settings with the error:
You need a higher level of permission. Sorry, you are not allowed to manage options for this site.
Also the SG Optimizer settings page at network level is blank with a load of javascript errors.
I tried deleting and re-installing the plugin, clearing browser cache. There’s nothing in the server error log.
I have other almost identical multisites which work fine, so I’m assuming there is something in the plugin settings which is corrupt.
-
Hello @skirridsystems,
We’re aware of the issue where a blank page appears when trying to access the Speed Optimizer’s settings page in the network admin panel. A fix for this will be released in an upcoming version of the plugin.
Regarding the other issue you reported, I was unable to replicate it on my end. I didn’t encounter any errors when trying to save changes in Settings -> General of a subsite in the Multisite installation. I tried this with both the super-admin user and an admin user of the subsite.
At this point, I’m unable to provide additional information about this issue. If you’re a SiteGround client, please open a ticket from your Client Area and our Technical Support team will verify if the issue is indeed related to our plugin.
Best Regards,
Kuzman StoyanovI’m having the same sort of permissions issue as @skirridsystems where I try to make a settings change in my multisite and get a WordPress error saying I don’t have permissions (despite being an admin on the site and a super admin overall). I deactivated Speed Optimizer and can now make those same changes it wouldn’t let me do before.
Hello @johncrhea,
Our developers are aware of the mentioned glitch and they are actively working on a solution. At the current time, we are unable to provide an exact ETA for when this issue will be resolved.
In the meantime, you can downgrade the plugin to its previous version(7.4.6) where the mentioned settings changes should be working as expected.
Regards,
Vladimir
I’m also unable to save options on a subsite. It appears the logged in user cannot be determined correctly when saving options only if the SiteGround Optimizer plugin is network activated (no issues when the plugin is activated for each site individually).
The issue is that the
/wp-includes/pluggable.php
file is loaded inSuperCacher::purge_on_options_save()
, before the cookie constants are defined (they are defined by callingwp_cookie_constants()
inwp-settings.php
, just after the network plugins are loaded). Therefore, the cookies can not be used to determine the logged in user. That’s an issue and also results in PHP warnings in the logs:PHP Warning: Use of undefined constant SECURE_AUTH_COOKIE - assumed 'SECURE_AUTH_COOKIE' (this will throw an Error in a future version of PHP) in /home/customer/www/example.com/public_html/wp-includes/pluggable.php on line 929 PHP Warning: Use of undefined constant LOGGED_IN_COOKIE - assumed 'LOGGED_IN_COOKIE' (this will throw an Error in a future version of PHP) in /home/customer/www/example.com/public_html/wp-includes/pluggable.php on line 925
Call stack leading to the unauthenticated user when saving options:
# wp_get_current_user() called at /wp-includes/pluggable.php:2317 # wp_verify_nonce() called at /wp-content/plugins/sg-cachepress/core/Supercacher/Supercacher.php:318 # SiteGround_Optimizer\Supercacher\Supercacher->purge_on_options_save() called at /wp-content/plugins/sg-cachepress/core/Loader/Loader.php:722 # SiteGround_Optimizer\Loader\Loader->add_caching_hooks() called at /wp-content/plugins/sg-cachepress/core/Loader/Loader.php:660 # SiteGround_Optimizer\Loader\Loader->add_supercacher_hooks() # SiteGround_Optimizer\Loader\Loader->add_hooks() called at /wp-content/plugins/sg-cachepress/core/Loader/Loader.php:119 # SiteGround_Optimizer\Loader\Loader->__construct() called at /wp-content/plugins/sg-cachepress/sg-cachepress.php:72 # include_once(/wp-content/plugins/sg-cachepress/sg-cachepress.php) called at /wp-settings.php:418 # require_once(/wp-settings.php) called at /wp-config.php:106 # require_once(/wp-config.php) called at /wp-load.php:50 # require_once(/wp-load.php) called at /wp-admin/admin.php:34 # require_once(/wp-admin/admin.php) called at /wp-admin/options.php:19
I hope this will be resolved soon!
Hello @pronamic_reuel,
Thank you for the additionally provided information. Your findings have been forwarded to our plugin developers and they are working on resolving this as soon as possible.
While we do not have an ETA, we will make sure to let you know once there’s an update.
Best Regards,
Gergana PetrovaAny update on this, @gpetrova?
Hello Reüel,
Our developers are still working on the issue. We’ll update this thread as soon as we have a resolution.
I’m posted to confirm I have experienced the same issue where trying to save an Options page provides a “You need higher Permissions” but the user had Super Admin role. The odd thing is this error only occurs on newly added Network Sites, as either cloned sites or existing sites do not have this error. At this time, I had to deactivate the plugin SG Optimize to get the error to not occur. It would be great to have this issue resolved soon.
The issues is marked as resolved. I’ve just tested the new 7.6.0 release and it’s still not working.
As a workaround I have to disable dynamic caching before saving settings, then re-enable it.
Not fixed for me, either.
Is there a function call I can use to programmatically turn off dynamic caching when an admin is logged in? I need to fix this for multiple subdomain admins or the plugin is useless on a multisite install.
The latest update of the plugin did not include a fix for the reported problem.
When a topic is reported to our developers, we mark it as resolved. We have a case logged for it in our internal system, which we track, and we will update the thread when the issue is resolved.
There isn’t a custom filter to stop the dynamic cache for an admin user, as our plugin does not cache the admin page and logged-in user content; hence, there is no need to add a turn-off custom filter for the dynamic cache.Here is my temporary solution, disabling the plugin entirely on admin pages except for the main dashboard url and the cache settings pages:
add_filter( 'option_active_plugins', 'disable_sg_cache_admin' ); function disable_sg_cache_admin( $plugins ) { if ( strpos($_SERVER['REQUEST_URI'],'wp-admin') && !(strpos($_SERVER['REQUEST_URI'],'index.php') || strpos($_SERVER['REQUEST_URI'],'page=sgo')) ) { require (ABSPATH . WPINC . '/pluggable.php'); // Use the plugin folder and main file name here. // is used here as an example $plugins_not_needed = array ('sg-cachepress/sg-cachepress.php'); foreach ( $plugins_not_needed as $plugin ) { $key = array_search( $plugin, $plugins ); if ( false !== $key ) { unset( $plugins[ $key ] ); } } } return $plugins; }
Actually, for this to work I can’t network activate the plugin. Instead I use the filter to make it active on the individual subdomain sites outside of the admin pages I don’t want it to mess with. Obviously, a hack, but until they fix this for real …
add_filter( 'option_active_plugins', 'disable_sg_cache_admin' ); function disable_sg_cache_admin( $plugins ) { if ( strpos($_SERVER['REQUEST_URI'],'wp-admin') && !(strpos($_SERVER['REQUEST_URI'],'index.php') || strpos($_SERVER['REQUEST_URI'],'page=sgo')) ) { require (ABSPATH . WPINC . '/pluggable.php'); // Use the plugin folder and main file name here. // is used here as an example $plugins_not_needed = array ('sg-cachepress/sg-cachepress.php'); foreach ( $plugins_not_needed as $plugin ) { $key = array_search( $plugin, $plugins ); if ( false !== $key ) { unset( $plugins[ $key ] ); } } } elseif(!in_array('sg-cachepress/sg-cachepress.php',$plugins)) $plugins[] = 'sg-cachepress/sg-cachepress.php'; return $plugins; }
Re: “There isn’t a custom filter to stop the dynamic cache for an admin user, as our plugin does not cache the admin page and logged-in user content; hence, there is no need to add a turn-off custom filter for the dynamic cache.”
Whatever the plugin does differently on the admin pages includes the permissions bug reported here, which is associated with dynamic caching being turned on. Thus, the need for a workaround if I don’t want to have to tell subdomain admins to turn off dynamic caching every time they want to update settings.
- You must be logged in to reply to this topic.