Title: mpemburn's Replies | WordPress.org --- # mpemburn [ ](https://wordpress.org/support/users/mpemburn/) * [Profile](https://wordpress.org/support/users/mpemburn/) * [Topics Started](https://wordpress.org/support/users/mpemburn/topics/) * [Replies Created](https://wordpress.org/support/users/mpemburn/replies/) * [Reviews Written](https://wordpress.org/support/users/mpemburn/reviews/) * [Topics Replied To](https://wordpress.org/support/users/mpemburn/replied-to/) * [Engagements](https://wordpress.org/support/users/mpemburn/engagements/) * [Favorites](https://wordpress.org/support/users/mpemburn/favorites/) Search replies: ## Forum Replies Created Viewing 15 replies - 1 through 15 (of 32 total) 1 [2](https://wordpress.org/support/users/mpemburn/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/mpemburn/replies/page/3/?output_format=md) [→](https://wordpress.org/support/users/mpemburn/replies/page/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Constant Contact Forms] Redirect to a different page on error](https://wordpress.org/support/topic/redirect-to-a-different-page-on-error/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [1 year, 5 months ago](https://wordpress.org/support/topic/redirect-to-a-different-page-on-error/#post-18357894) * In case there is no built in way to do this, I played around with some jQuery that will do what I want—at least for my simple form that just adds an email to the Constant Contact list. I added this using the WPCode plugin. * ```wp-block-code (function($) { $(document).ready(function() { let ccAlert = $('p[role="alert"]'); let ccPlease = $('span.ctct-field-error'); // See if an error message exists if (ccAlert.is('*')) { // Save the Constant Contact error messages sessionStorage.setItem('errorMessage', ccAlert.prop('outerHTML')); sessionStorage.setItem('errorPlease', ccPlease.prop('outerHTML')); // Go back to the original page (instead of the RedirectURL) window.history.back(); // Scroll down to the ccAlert element. $([document.documentElement, document.body]).animate({ scrollTop: ccAlert.offset().top }, 500); } $(window).bind("pageshow", function(event) { let ccAlert = $('p[role="alert"]'); let ccField = $('p.ctct-form-field-email'); // Check for the saved messages if (event.originalEvent.persisted && ccAlert.length !== 1) { // Recreate the look of the page ccField.prepend(sessionStorage.getItem('errorMessage')); $('input[type="email"]').addClass('ctct-invalid') ccField.append(sessionStorage.getItem('errorPlease')); sessionStorage.clear(); } }); });})(jQuery); ``` - This reply was modified 1 year, 5 months ago by [mpemburn](https://wordpress.org/support/users/mpemburn/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Constant Contact Forms] Redirect to a different page on error](https://wordpress.org/support/topic/redirect-to-a-different-page-on-error/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [1 year, 5 months ago](https://wordpress.org/support/topic/redirect-to-a-different-page-on-error/#post-18357882) * Hi Michael, * Yes, that’s correct. * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Hook to get user data](https://wordpress.org/support/topic/hook-to-get-user-data/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years ago](https://wordpress.org/support/topic/hook-to-get-user-data/#post-17925058) * Hi Paul, * Thanks! After more testing, I discovered that my methodology was flawed. I was using a plugin that switches between users, and that doesn’t fire the WP `parse_request` hook that you use call the `Authorization->restrict_access()` method. It does work with a new login, however, so whatever problem I’m having is not with Authorizer per se. * Regards, * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Numerous set_default_options() calls cause site to crash](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 1 month ago](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/#post-17863429) * Hi Paul, Thank you! I’ve installed 3.8.5 on our test instance, and it looks good so far. I’ve asked my team to give it a workout, and I’ll be monitoring New Relic to make sure no further spikes show up.I really appreciate your help with this! Through our travails with server crashes over these past few weeks, you are the only plugin vendor out of a handful to respond quickly and appropriately.Best regards,Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Numerous set_default_options() calls cause site to crash](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 1 month ago](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/#post-17861418) * Hi Paul, * Thanks, that works. I realized that I’ve used the same technique for one of my own plugins. Sad to relate, we discovered another couple of problems with Authorizer this morning. These showed up when we attempted to create a new subsite and got fatal errors. The first of these was in class-options.php on line 45.`if ( ! array_key_exists( $option, $auth_settings ) ) { return null;}…threw the error“ Fatal error: Uncaught TypeError: array_key_exists(): Argument #2 ($array) must be of type array, bool given”. I changed it to this:if ( ! is_array( $auth_settings) || ! array_key_exists( $option, $auth_settings ) ) { return null;} * The second issue was in class-authorization on line 817. `$auth_settings_access_users_approved = array_merge( $options->get( 'access_users_approved', Helper::_SINGLE\_CONTEXT_), $options->get( 'access_users_approved', Helper::_NETWORK\_CONTEXT _));…threw the error: “PHP Fatal error: Uncaught TypeError: array_merge(): Argument #1 must be of type array, bool given”. I changed it to this:$single = $options->get( ' access_users_approved', Helper::_SINGLE\_CONTEXT _);$network = $options->get(' access_users_approved', Helper::_NETWORK\_CONTEXT _);if ( is_array( $single )&& is_array( $network ) ) {_ _ _// Get all site users and all multisite users. $auth\_settings\_access\_users\_approved = array\_merge( $options->get( 'access\ _users\_approved', Helper::SINGLE\_CONTEXT ), $options->get( 'access\_users\_approved', Helper::NETWORK\_CONTEXT ) );}You may have a better way of doing this. If you could squeeze this into you next release, I’d be most grateful.Mark - This reply was modified 2 years, 1 month ago by [mpemburn](https://wordpress.org/support/users/mpemburn/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Numerous set_default_options() calls cause site to crash](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 1 month ago](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/#post-17854768) * Thank you! * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Numerous set_default_options() calls cause site to crash](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 1 month ago](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/#post-17854743) * Hi Paul, * I believe I’ve found the root of the problem, and it’s very much tied to the fact the we use networks on the Clark University website. The networks organize the subsites into groups for “departments”, “offices”, “schools”, etc. * The problem occurs in **Updates::auth_update_check()** method when it checks for the value of **auth_version** for the root subsite.  In simple multisites, this would be “1”, and it would pull the value from the wp_options table.  This is currently 20230222, so the code that tests whether updates are needed fails, and processing fall through to the end of the method without taking any action. * In some cases, however, the **auth_version** check sees the root site as “3” or “5”—the IDs of the “offices” and “departments” network—and returns null, since** auth_version** isn’t set in **wp_3_options** or **wp_5_options**.  Now, the code thinks that updates are needed, and it runs every one of the 20 blocks of code that test for **$update_if_older_than**.  Most of this are harmless as far as we’re concerned, but the one that follows **$update_if_older_than = 20221101** contains a foreach that loops over every subsite and runs the **Options::set_default_options()** method for each one.  This is where the CPU usage goes through the roof and we get slow performance or, in the worst cases, crashes with fatal errors. The fix for this is pretty simple, and I don’t think that it will adversely affect the plugin for others. If you add the following after line 34 of **class-update.php**, it will run the code properly for the root subsite, but bail for ones that don’t return a date value for **auth_version**:`if (empty($auth_version)) { return false;}Can I request that you incorporate this into your next release of Authorizer? Regards,Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Numerous set_default_options() calls cause site to crash](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 1 month ago](https://wordpress.org/support/topic/numerous-set_default_options-calls-cause-site-to-crash/#post-17851508) * Hi Paul, The HTTP 500 errors were happening on all pages, front end and back. The response time is the overall page loading time, and I track it by watching the New Relic dashboard for the site. I wanted to show you a screenshot of New Relic that illustrates what I mean but there doesn’t seem to be a way here. When I added the “return false;” to the set_default_options method, the average page load times dropped from around 7 seconds to less than a second. * This is from the New Relic “slowest transactions” list from one of our worst times: #Authorizer\Options::set_default_optionsExecution count: 969Duration 16.16 secondsI can only present the evidence that’s available to me, and it seems to point at this specific method call as the culprit. Let’s work together to figure this out. I’d be happy to do a Zoom call with you if that works best. * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Administrator users revert to Subscriber](https://wordpress.org/support/topic/administrator-users-revert-to-subscriber/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 3 months ago](https://wordpress.org/support/topic/administrator-users-revert-to-subscriber/#post-17757415) * Hi Paul * I had a meeting this morning with a coworker who told me that this behavior is expected, and was dealt with (before my time) by writing a plugin that pulls in Active Directory roles for the user, then creates a custom “Content Administrator” role for them. I did not have this installed on the new site. Seems I was barking up the wrong tree, but thanks for taking the time! * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Administrator users revert to Subscriber](https://wordpress.org/support/topic/administrator-users-revert-to-subscriber/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 3 months ago](https://wordpress.org/support/topic/administrator-users-revert-to-subscriber/#post-17753855) * Hi Paul, * Since the website is new, we have only used it with version 3.8.1. I had a copy of 3.7.1 hanging around so I installed it on the test site. Unfortunately, it’s still zapping the Administrator role. * Details: this is a multisite, but only has one subsite at the moment. I assigned the role from the subsite’s user page, but have also done so with wp-cli: `wp user add-role myuser administrator`. In addition, I added the role in the Authorizer“ Approved Users” list.  * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Administrator users revert to Subscriber](https://wordpress.org/support/topic/administrator-users-revert-to-subscriber/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 3 months ago](https://wordpress.org/support/topic/administrator-users-revert-to-subscriber/#post-17752207) * Hi Paul, * Yes, we’re on version 3.8.1. * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Authorizer seems to be slowing us down](https://wordpress.org/support/topic/authorizer-seems-to-be-slowing-us-down/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 5 months ago](https://wordpress.org/support/topic/authorizer-seems-to-be-slowing-us-down/#post-17494241) * Hi Paul, * I just updated our test site to 3.7.1 and tested with “wp option get auth_version”. It’s still showing 20230222—shouldn’t this have changed to 2024[something]? * Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Authorizer seems to be slowing us down](https://wordpress.org/support/topic/authorizer-seems-to-be-slowing-us-down/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 5 months ago](https://wordpress.org/support/topic/authorizer-seems-to-be-slowing-us-down/#post-17485645) * Thanks! It’s on 20230222. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Authorizer] Authorizer seems to be slowing us down](https://wordpress.org/support/topic/authorizer-seems-to-be-slowing-us-down/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 5 months ago](https://wordpress.org/support/topic/authorizer-seems-to-be-slowing-us-down/#post-17485041) * Hi Paul, * Thanks. We haven’t moved to the current version of Authorizer, so no db migrations have been necessary since the last update. As far as I know, we haven’t experienced any database timeouts. I’ll try updating to 3.7.1 next week to see if that fixes the problem.Mark * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[UserFeedback - Create Interactive Feedback Form, User Surveys, and Polls in Seconds] Shortcode loads on page but does not contain survey](https://wordpress.org/support/topic/shortcode-loads-on-page-but-does-not-contain-survey/) * Thread Starter [mpemburn](https://wordpress.org/support/users/mpemburn/) * (@mpemburn) * [2 years, 8 months ago](https://wordpress.org/support/topic/shortcode-loads-on-page-but-does-not-contain-survey/#post-17263527) * Thanks [@devmich](https://wordpress.org/support/users/devmich/)—that was what I needed to know! Viewing 15 replies - 1 through 15 (of 32 total) 1 [2](https://wordpress.org/support/users/mpemburn/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/mpemburn/replies/page/3/?output_format=md) [→](https://wordpress.org/support/users/mpemburn/replies/page/2/?output_format=md)