Title: timkite's Replies | WordPress.org

---

# timkite

  [  ](https://wordpress.org/support/users/timkite/)

 *   [Profile](https://wordpress.org/support/users/timkite/)
 *   [Topics Started](https://wordpress.org/support/users/timkite/topics/)
 *   [Replies Created](https://wordpress.org/support/users/timkite/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/timkite/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/timkite/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/timkite/engagements/)
 *   [Favorites](https://wordpress.org/support/users/timkite/favorites/)

 Search replies:

## Forum Replies Created

Viewing 15 replies - 1 through 15 (of 18 total)

1 [2](https://wordpress.org/support/users/timkite/replies/page/2/?output_format=md)
[→](https://wordpress.org/support/users/timkite/replies/page/2/?output_format=md)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] Authorizer Admin Page Using Too Much Memory](https://wordpress.org/support/topic/authorizer-admin-page-using-too-much-memory/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/authorizer-admin-page-using-too-much-memory/#post-17771417)
 * 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!
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] Authorizer Admin Page Using Too Much Memory](https://wordpress.org/support/topic/authorizer-admin-page-using-too-much-memory/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/authorizer-admin-page-using-too-much-memory/#post-17745000)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] Authorizer Admin Page Using Too Much Memory](https://wordpress.org/support/topic/authorizer-admin-page-using-too-much-memory/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/authorizer-admin-page-using-too-much-memory/#post-17736806)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Ninja Forms - The Contact Form Builder That Grows With You] Upgrade to 3.5.3 Crashes Site at Form Upgrade Step](https://wordpress.org/support/topic/upgrade-to-3-5-3-crashes-site-at-form-upgrade-step/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [5 years, 5 months ago](https://wordpress.org/support/topic/upgrade-to-3-5-3-crashes-site-at-form-upgrade-step/#post-14347502)
 * I’ve confirmed that manually running through the “update forms” procedure ahead
   of updating the plugin does in fact resolve the problem. Thanks!
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] Permissions on wp-cache-config.php too strict](https://wordpress.org/support/topic/permissions-on-wp-cache-config-php-too-strict/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [7 years ago](https://wordpress.org/support/topic/permissions-on-wp-cache-config-php-too-strict/#post-11930697)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] Permissions on wp-cache-config.php too strict](https://wordpress.org/support/topic/permissions-on-wp-cache-config-php-too-strict/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [7 years ago](https://wordpress.org/support/topic/permissions-on-wp-cache-config-php-too-strict/#post-11930647)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Redirection] Trouble Downgrading Plugin](https://wordpress.org/support/topic/trouble-downgrading-plugin/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [7 years, 10 months ago](https://wordpress.org/support/topic/trouble-downgrading-plugin/#post-10819237)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Accessibility] Version 1.6.4 Is Missing 2 Files](https://wordpress.org/support/topic/version-1-6-4-is-missing-2-files/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [8 years ago](https://wordpress.org/support/topic/version-1-6-4-is-missing-2-files/#post-10667060)
 * Yeah, it does seem like WordPress.org 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!
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Accessibility] Version 1.6.4 Is Missing 2 Files](https://wordpress.org/support/topic/version-1-6-4-is-missing-2-files/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [8 years ago](https://wordpress.org/support/topic/version-1-6-4-is-missing-2-files/#post-10658718)
 * 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.wordpress.org/plugin-checksums/wp-accessibility/1.6.4.json](https://downloads.wordpress.org/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](https://github.com/wp-cli/checksum-command/issues/46)
 * Is this just something that WordPress.org is doing incorrectly when it generates
   plugin checksums? It would seem if this is common that checksum verification 
   wouldn’t be very reliable.
 *   Forum: [Requests and Feedback](https://wordpress.org/support/forum/requests-and-feedback/)
   
   In reply to: [Please Add Support for Older PHP Back to WP-CLI](https://wordpress.org/support/topic/please-add-support-for-older-php-back-to-wp-cli/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [8 years, 1 month ago](https://wordpress.org/support/topic/please-add-support-for-older-php-back-to-wp-cli/#post-10593493)
 * That’s an excellent point, I’ll do just that. Thanks!
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] Authorizer 2.8.x cannot be activated by wp-cli](https://wordpress.org/support/topic/authorizer-2-8-x-cannot-be-activated-by-wp-cli/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [8 years, 1 month ago](https://wordpress.org/support/topic/authorizer-2-8-x-cannot-be-activated-by-wp-cli/#post-10541770)
 * I should add…there’s no error message. WP-CLI simply returns with no status, 
   and the plugin doesn’t get activated.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Firelight Lightbox] parse error after update..](https://wordpress.org/support/topic/parse-error-after-update-8/)
 *  [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [8 years, 5 months ago](https://wordpress.org/support/topic/parse-error-after-update-8/#post-10143147)
 * 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?
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] LDAPS Support Request](https://wordpress.org/support/topic/ldaps-support-request/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [9 years, 6 months ago](https://wordpress.org/support/topic/ldaps-support-request/#post-8845927)
 * 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'] );
       }
       ```
   
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] LDAPS Support Request](https://wordpress.org/support/topic/ldaps-support-request/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [9 years, 6 months ago](https://wordpress.org/support/topic/ldaps-support-request/#post-8845907)
 * 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'] );
       }
       ```
   
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Authorizer] LDAPS Support Request](https://wordpress.org/support/topic/ldaps-support-request/)
 *  Thread Starter [timkite](https://wordpress.org/support/users/timkite/)
 * (@timkite)
 * [9 years, 6 months ago](https://wordpress.org/support/topic/ldaps-support-request/#post-8845891)
 * 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.

Viewing 15 replies - 1 through 15 (of 18 total)

1 [2](https://wordpress.org/support/users/timkite/replies/page/2/?output_format=md)
[→](https://wordpress.org/support/users/timkite/replies/page/2/?output_format=md)