Related to SLP Project issue: Cullgroup fatal error viewing dashboard (or logging in)#66
System log error.
[Tue Jan 20 16:44:46.077513 2026] [core:error] [pid 59] [client 127.0.0.1:47176] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.
Summary
Turns out the user has a “+” in their account name. This has been the case since they first signed up. It appears as though they’ve not tried to login over the past few years until last month, around the time support learned they could not switch to the”cullgroup” account.
The Fix
Update the Apache rewrite rules for WordPress, .htaccess which changes how Apache parses URLs. The default setup provided by WordPress does not manage the corner case of special characters in a multisite user account such as “+” properly.
This patch requires extensive testing of the application to make sure it does not impact deployment.
ChatGPT Analysis
This turns out to be the correct analysis , which led to a update to the .htaccess file to address the issue.
That access log is the smoking gun: Apache is not applying the multisite “strip the site prefix” rewrite for paths that contain a +.
Why that matters
Notice everything after your first request is being requested under the tenant prefix:
• /webadmin+pete_at_cullgroup_dot_com/wp-admin/ → 404
• /webadmin+pete_at_cullgroup_dot_com/wp-includes/... → 404
• /webadmin+pete_at_cullgroup_dot_com/wp-content/... → 404
In WordPress multisite (subdirectory mode), it’s normal for URLs to look like /site-slug/wp-admin/... and /site-slug/wp-includes/... but Apache must rewrite those to the real directories (/wp-admin, /wp-includes, /wp-content) using the standard multisite rules.
The default multisite rule only matches site prefixes made of [_0-9a-zA-Z-] — and your site prefix contains a + (webadmin+pete...). So the rule doesn’t match, the prefix is never stripped, and Apache genuinely can’t find a directory named /webadmin+pete_at.../wp-admin, so you get the “Oops! That page can’t be found.” front-end output plus a pile of 404s for assets.
That also explains why your other site (/temmie53573_at_fanclub_dot_pm/...) continues to work: no + in the path, so it matches the rewrite regex.
⸻
Fix: allow + in the multisite rewrite rule
In your Apache rewrite config (usually the WordPress .htaccess in the web root, or an equivalent vhost snippet in the container), find the multisite block that looks like this:
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-(content|admin|includes).*$ wp-$2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-admin/.*\.php)$ $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes)/.*)$ $2 [L]
Change the character class to include + (put it at the end of the class so it’s treated literally):
RewriteRule ^([_0-9a-zA-Z-+]+/)?wp-(content|admin|includes).*$ wp-$2 [L]
RewriteRule ^([_0-9a-zA-Z-+]+/)?(wp-admin/.*\.php)$ $2 [L]
RewriteRule ^([_0-9a-zA-Z-+]+/)?(wp-(content|admin|includes)/.*)$ $2 [L]
Then reload Apache in the container.
Quick sanity check after the change
Re-hit these and they should return 200 (or 302 for login redirect), not 404:
• https://local.storelocatorplus.com/webadmin+pete_at_cullgroup_dot_com/wp-admin/
• https://local.storelocatorplus.com/webadmin+pete_at_cullgroup_dot_com/wp-includes/css/admin-bar.min.css?ver=6.4.2
⸻
Why network admin “sort of” still works
Your log shows requests referencing https://local.storelocatorplus.com/wp-admin/network/ — that URL has no tenant prefix, so it bypasses the broken prefix-stripping rewrite entirely.
⸻
If you tell me whether your local docker is using an .htaccess file or a vhost conf (sometimes multisite rewrites are baked into the vhost), I’ll point to the exact file/location SLP SaaS typically uses in the container.