bigtomato

Lucien, thanks for the patch, but I don’t think it’s quite fixed yet. We installed the 5.3.4.1 patch on a dev server with Strict error reporting and an MU monitor checking for correct blog switching. It appears that the switch_blog hook is being called with too few arguments.

The error:

PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function {closure}(), 1 passed

Upon tracing, we confirmed the call originates from:
wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php(804): switch_to_blog()

It appears that do_action(‘switch_blog’, …) is being fired without the second $prev_blog_id argument, which is expected by WordPress core and any listener using the documented signature.

To fix, please ensure any use of:

do_action(‘switch_blog’, $blog_id); // ❌
…is updated to:

do_action(‘switch_blog’, $new_blog_id, $prev_blog_id); // ✅

We’ve mitigated the issue by hardening our MU monitoring plugin to use a default for the second argument, but this should be addressed upstream to avoid breaking other well-behaved listeners.

By the way, we’ve only ever had this plugin Network Activated, never site by site, so you might want to check that again. We use the subdomain Multisite structure. Let us know if you need our error logs or test case.

Thanks again for addressing this so quickly.

Happened to us as well. Seemed like such a minor update that we did not test it first. Won’t do that again. We had 250+ websites redirecting to the root site, and dozens of upset clients calling and emailing until we deactivated the plugin. Something in the update caused WordPress to redirect everything back to the root. In the response headers X-Redirect-By was set to WordPress, and the Location was set to the multisite root domain url. Deactivating the plugin and clearing the server cache fixed the issue.

• This reply was modified 1 year, 1 month ago by bigtomato.

That’s your problem – your http_host header can’t be detected.

From chatgpt:

In a single-site configuration, WordPress doesn’t rely on HTTP_HOST and other array keys to the same extent as it does in a multisite setup. Here’s why the issue is specific to multisite mode:

1. Multisite’s Dependency on HTTP_HOST for Domain Mapping:
   • In a single-site setup, WordPress primarily uses the siteurl and home options from the database to determine the site’s URL. It doesn’t need to dynamically map multiple domains or subdomains, so HTTP_HOST is not as critical.
   • In a multisite environment, HTTP_HOST is crucial because WordPress uses it to identify the correct subsite based on the incoming request’s hostname. Without this information, it can’t map the request to the correct subsite, leading to PHP warnings and failed requests.
2. Increased Complexity of Multisite Network Configurations:
   • Multisite setups introduce more complex routing rules that require PHP to access and interpret incoming headers to route users to the right subsite or subdirectory. The configuration of ms-settings.php and other WordPress core files relies heavily on HTTP_HOST, REQUEST_URI, and sometimes HTTPS headers to function correctly.
   • When these headers are missing or not populated correctly, the multisite configuration cannot route requests properly, resulting in 502 errors.
3. Canonical Redirects and URL Rewriting:
   • Multisite networks need to handle canonical URLs to enforce consistent URLs across the network, which is managed in canonical.php. These canonical redirects rely on HTTP_HOST, REQUEST_URI, and scheme headers to determine the correct URL structure.
   • Without these headers, canonical.php cannot correctly form URLs, triggering undefined array key warnings and causing the server to drop requests, which often leads to a 502 error.
4. Server Configuration Requirements for Multisite:
   • Multisite often requires specific web server configurations or proxy settings to handle and pass headers properly, particularly in environments using load balancers or reverse proxies (common in GCP). In a single-site setup, these specific configurations are usually not as necessary.
   • If your server or load balancer configuration doesn’t account for the multisite requirements (such as forwarding headers like Host and X-Forwarded-Host), the environment won’t work as expected when switching to multisite.
5. Dynamic Path and Domain Resolution:
   • Multisite mode introduces dynamic path or subdomain resolution, meaning WordPress can serve multiple sites from a single install. For that, it heavily relies on ms-settings.php, which parses these headers to determine the current site context. If these headers are unavailable, multisite cannot function, but single-site mode can continue since it doesn’t need this resolution logic.

In summary, the multisite setup introduces dependencies on server and network configurations that are unnecessary in a single-site setup. When these configurations are missing or incomplete, multisite-specific files like ms-settings.php and canonical.php generate errors, leading to 502 failures that wouldn’t appear in a single-site environment.

Possible solution:

GCP environments often use proxy layers or load balancers, which may need specific settings to handle headers correctly.
Solution: In GCP Console, confirm that X-Forwarded-Host, X-Forwarded-Proto, and Host headers are properly forwarded. You may need to set up your web server to recognize and correctly handle these headers.

Is this an existing WordPress install that you are trying to convert to Multisite? Or a new Multisite install? Can you share the URL?

Is this server error still happening?

I tried to load the site. I received the following:Error: Server ErrorThe server encountered a temporary error and could not complete your request.Please try again in 30 seconds.

I am unclear on how you could introduce a WordPress bug if you cannot load your site. Would you paste in the data from your debug.log?

Could you verify whether or not you see the front end of the site? Can you log into the backend?

But agreed, since it’s on Google Cloud it might be something specific to that configuration.

We are having the same issue and it appears to be related to The Events Calendar 6.7.0 admin area restyle: https://theeventscalendar.com/blog/the-events-calendar-admin-settings-get-a-design-makeover/?utm_source=activecampaign-tec&utm_medium=email&utm_campaign=newsletter&utm_id=815

Maybe there is an unclosed tag in the update?

Here’s a screenshot showing what it looks like: https://paste.pics/f81d836763ec3368f3ea90a95605a6b1

Rolling back to TEC 6.6.4.2 and TEC Pro 7.03 fixed the issue.

Thank you.

• This reply was modified 1 year, 7 months ago by bigtomato.