mpemburn

Hi?@wfpeter,

Any progress on this?

Mark

Hi @wfpeter,

Thanks! We’re on version 6.3.1.

Mark

Hi @wfpeter,

The number of items is set to the default of 20, so it’s getting the full user list on the back end.

Mark

We are using this plugin on a multisite network, but it’s not network activated. I’m not sure how a fatal PHP error is solved by saving changes, but we did that. Thank you.

Hi,

Are we close to having a solution to this issue? We are still experiencing extremely long load times.

Regards,

Mark

Paul,

We do have version 3.6.2 installed now. What I reported above was an issue yesterday, but has not been a problem since. I can see that it might have to do the sweep through the many, many subsites once, but apparently it’s settled down now.

The only question now is: will it do this the next time there’s an update to Authorizer? If so, we should make sure to access the problem subsites immediately after an update.

Thanks,

Mark

• This reply was modified 1 year, 9 months ago by mpemburn.

Thanks Peter–I just sent the report.

After creating this ticket yesterday, I passed it along to our web host support team, since we work closely on our WordPress issues. They saw your reply and said, “It’s also worth mentioning that you have a relatively high number of blogs (300+) and a high number of users (600+) so it might simply not be feasible to call the?can_activate_2fa?and?_user_can_for_blog?for each user/blog and they may instead need to add an array version of the checks which would perform the capability check for many users at once, reducing the number of individual calls.”

–Mark

Ugh, sorry… I spoke too soon. It seems that my original test page was not sufficient to vet the problem. Other pages on my staging site are now doing the same thing: taking ~30 seconds to load (or timing out before they do) because they are writing updates to each of nearly 200 wp_{n}_options table on every page load. This is what I did to circumvent this:

$network_active = is_plugin_active_for_network('authorizer');

if ( is_multisite()  && ! $network_active) {
    $auth_version = get_blog_option( get_network()->blog_id, 'auth_version' );
} else {
    $auth_version = get_option( 'auth_version' );
}

and:

if ( $needs_updating ) {
    if ( is_multisite() && ! $network_active) {
        // phpcs:ignore WordPress.WP.DeprecatedFunctions.wp_get_sitesFound
        $sites = function_exists( 'get_sites' ) ? get_sites() : wp_get_sites( array( 'limit' => PHP_INT_MAX ) );
        foreach ( $sites as $site ) {
            $blog_id = function_exists( 'get_sites' ) ? $site->blog_id : $site['blog_id'];
            update_blog_option( get_network()->blog_id, 'auth_version', $auth_version );
        }
    } else {
        update_option( 'auth_version', $auth_version );
    }
}

Unless there is some compelling reason not to do this, please incorporate these changes into your next release.

–Mark

Thanks Paul–it works like a champ!

Paul, I don’t know if you’ve caught this, but an additional change is needed in order to prevent the update code from writing to all of the wp_{number}_options tables:

From line 30:

$network_active = is_plugin_active_for_network('authorizer');

if ( is_multisite()  && ! $network_active) {
	$auth_version = get_blog_option( get_network()->blog_id, 'auth_version' );
} else {
	$auth_version = get_option( 'auth_version' );
}

On line 525:

if ( is_multisite() && ! $network_active) { ...

I patched these changes into our production site today and it cut about 25 second off the load time of one of our private subsites. For reference, we currently have 184 subsites on our main website.

Hi Paul,

If you can make that small release, it’d be fantastic!

Beyond the items I mention here, the bug that’s described here: https://www.ads-software.com/support/topic/lots-of-queries-from-class-updates-php-when-using-multisite/ has caused some real headaches. I had our hosting provider research an issue on particular subsite, and they found that Authorizer\Updates->auth_update_check()
took over 27 seconds to complete.

-Mark

Thanks Paul. That other ticket is from a coworker. We’re trying to nail down a bunch of issues before our hosting provider throws us off the PHP 8 cliff.

Do you have a timeline for the next update?

I just received this from our hosting provider, who is trying to track down the reason for timeouts we’ve been experiencing of late. I don’t know if this is useful to you:
“We were alerted a few minutes ago to a slow login on wp-login.php that took nearly 30 seconds. I was able to find a trace in New Relic. It looks like the bulk of the slowness is coming from the Authorizer plugin performing update checks or ‘set_default_options’ calls.”

Hi Paul,
I’m afraid that I can only report what I was getting from the error logs. Our system logins are managed by ADFS and CAS, and I’m not as conversant in the complexities of this as I might be.

All I can say is that given how fussy PHP has become in version 8–and will only become more so in future versions–it’s not safe to make assumptions about data types anymore. Clark University has vast multisite systems with numerous plugins, and it has been a real headache ferreting out the incompatible code in preparation for this version upgrade.

–Mark

I am having the same issue. I’ve tried every variation I could think of, but the only thing that avoids the “Oops” is to use more than one amount in the shortcode. This is less than ideal, but it should work for now.