timkite

That seems to have made a remarkable difference. 181 MB -> 28 MB to render the options page (plus an error about $pages not being defined, of course) with that section commented out. With 'update_post_meta_cache' => false, added to the array of flags to get_posts(), the memory use of the options page on this site goes back up a little to 58 MB, but that still seems reasonable.

Thanks!

They actually already were using Query Monitor, so I bumped up the PHP memory limit enough so the Authorizer settings page would load in non-Production and took a look.

Yowza! A series of calls from WordPress Core running update_meta_cache() against blocks of specific post IDs. Each query returns between a few thousand and almost 50,000 rows. Any idea what it’s doing there or why it would be doing that on the Authorizer settings page? It’s not doing it on the regular Users page.

Thanks for the response!

This multisite only has about 85 users total, with most on the base site, and the high RAM use is specifically when loading the Authorizer options page, not elsewhere. In fact, the site owner discovered they could approve/deny new users from the widget Authorizer adds to the main Dashboard page, because that doesn’t seem to consume any more RAM than usual. It’s just the Authorizer settings page that wants well over the 128 MB we normally allow PHP sessions.

Since the base site has the biggest issue, I tried setting all of its auth_* options to not autoload, but that didn’t have any impact on the memory used.

One additional thing that’s worth mentioning is they’re using User Role Editor Pro to define custom user roles. They have other memory use issues too (they have 27 plugins active and most settings pages take between 30 and 97 MB to render), but the Authorizer dashboard pages definitely use the most RAM by far.

I’ve confirmed that manually running through the “update forms” procedure ahead of updating the plugin does in fact resolve the problem. Thanks!

Oh, I don’t lock down permissions for WPSC. I lock them down to reduce attack surface. It’s just a happy coincidence WPSC can’t break sites by changing wp-config.php’s permissions.

I’m at least able to avoid WPSC mucking with wp-config.php’s permissions by preventing write access to pretty much everything in WordPress from the web server process save what it explicitly needs. On my installs WordPress can only modify the contents of wp-content, minus the plugins and themes folders. Authorized users can use SFTP to do things like change wp-config, update WordPress, or manage themes and plugins. Removing the web server’s access to wp-cache-config.php, however, means that the WPSC’s GUI no longer works for changing settings, forcing site users to make those settings changes by hand, which is less than ideal.

The only workaround I have for that so far is a cron job that runs through every so often and fixes permissions, hopefully before it matters.

I would agree, which is strange since I did the downgrade via WP-CLI (which should replace all plugin files).

Ultimately I got it working again by downgrading one step further to 3.2.1, which should work until I can get these sites all migrated to newer systems. This can be marked resolved.

Yeah, it does seem like www.ads-software.com should give you the tools to say “this is my release branch, please base any automated statistics on this.”

In the end, given the other piece of the WP-CLI discussion linked earlier, I may just have to give up on being able to reliably automatically audit plugin integrity and leave it to file permissions to keep sites safe. If devs can change files without incrementing the version number (bad practice though that may be), I don’t need 200+ false alerts every time a popular plugin has something like that happen to it!

This is WP-CLI’s verify-checksums command. Based on what I’m reading, it would be comparing against the following, which does seem to be pointed at the trunk:
https://downloads.www.ads-software.com/plugin-checksums/wp-accessibility/1.6.4.json

Based on the following open issue, they are looking at supporting edge cases where plugins update without new checksums being generated, but I don’t know if that would cover this case:
https://github.com/wp-cli/checksum-command/issues/46

Is this just something that www.ads-software.com is doing incorrectly when it generates plugin checksums? It would seem if this is common that checksum verification wouldn’t be very reliable.

That’s an excellent point, I’ll do just that. Thanks!

I should add…there’s no error message. WP-CLI simply returns with no status, and the plugin doesn’t get activated.

It should be stated that if you’re on Enterprise Linux (RHEL 6, for example), PHP 5.3.3 is still receiving security updates. Any possibility of continuing to support older PHP?

Last one, I promise. Yeah it’s Friday but it didn’t take long to find preg_match():

if ( preg_match( "/^ldaps?:\/\//", $auth_settings['ldap_host'] ) ) {
	if ( ! empty($auth_settings['ldap_host']) ) {
		// URI with port provided, append port to URI
		$ldap = ldap_connect( $auth_settings['ldap_host'] . ":" . $auth_settings['ldap_port'] );
	} else {
		// Only URI provided, send it alone
		$ldap = ldap_connect( $auth_settings['ldap_host'] );
	}
} else {
	// URI not provided, pass host and port as separate parameters
	$ldap = ldap_connect( $auth_settings['ldap_host'], $auth_settings['ldap_port'] );
}

Here, with comments even:

// Establish LDAP connection.
if ( substr( $auth_settings['ldap_host'], 0, 7 ) === "ldap://" || substr( $auth_settings['ldap_host'], 0, 8 ) === "ldaps://" ) {
	if ( ! empty($auth_settings['ldap_host']) ) {
		// URI with port provided, append port to URI
		$ldap = ldap_connect( $auth_settings['ldap_host'] . ":" . $auth_settings['ldap_port'] );
	} else {
		// Only URI provided, send it alone
		$ldap = ldap_connect( $auth_settings['ldap_host'] );
	}
} else {
	// URI not provided, pass host and port as separate parameters
	$ldap = ldap_connect( $auth_settings['ldap_host'], $auth_settings['ldap_port'] );
}

Actually I definitely missed something. In the event it’s a URI, you need to test if ldap_port is set before trying to append it, or ldap_connect() will complain that “ldaps://foo.bar:” is an invalid URI. Also I’m not super happy about that substring test and would rather do a regex, but since I don’t normally work in PHP I’d need to go look that up. Yeah, I know, but it’s Friday.