At last!  Persistence paid off.

The culprit was this line in my wp-config.php:

define( ‘NOBLOGREDIRECT’, ‘http://www.qbgarage.com‘ );

Basically, that performs a redirect when someone attempts to visit a URL that doesn’t exist.  Perhaps SPF is doing something to generate the URL’s for the forum?  That’s why the main forum page loads, but access to the forums triggers the redirect. 

The problem is that this is very useful to direct users to the home page of the main site when they try to access a SITE that does not exist, but it creates a problem because of the impact it has on the main site.  Therefore, the workaround is to create a script (something like myscript.php) and put it in the wp-content/mu-plugins folder.  That way it gets executed like a network activated plugin.  The script should contain:

<?php
remove_action( ‘template_redirect’, ‘maybe_redirect_404’ );
?>

Hopefully, that will help the next person that wrestles with multisite.

good hard work.  Yes, we add url rewrite rules to the wp list… remember all forum content appears on a single wp page…  so the appearance of many forum pages is just url rewrite magic…

but it does not generally do redirects (there are some instances where a redirect exists, but not via 404 status)…  I wonder… is your permalink for you wp consistent with the forum as far as trailing slash?  if not could cause 302 redirect but that should be harmless, just a waste…

Yes, both show a trailing slash.  I am sure it is your URL rewrite magic that caused multisite to get confused.  I should have thought of that earlier when it was only happening on the main site.  It just took so long to wade through all of the other differences, like plugins, that are the usual culprits.  I’m glad it is working now and can get on to more testing.

Thanks for your steady help.

no worries. glad to have someone putting it through the wringers. Not sure why multisite would be confused, though must admit never used or heard of that define you used…

Confused might not have been the best choice of words.

This is from the settings page of the network admin:

If registration is disabled, please set NOBLOGREDIRECT inwp-config.php to a URL you will redirect visitors to if they visit a non-existent site.

Without that setting, a visitor to a non-existent site either sees a strange message of:

Greetings Site Administrator! You are currently allowing “none” registrations. To change or disable registration go to your Options page.

Registration has been disabled.

if you disabled registration or they are taken to a sign-up page based on your registration settings.  Many network admins consider that less than ideal behavior, which is why there is the NOBLOGREDIRECT directive.  How that directive gets implemented is where the confusion comes from.  Even ignoring SPF, adding that directive alone without the small script in mu-plugins wipes out 404 errors on the main site, because they get directed to the home page.

confused because the logic that detects this does not make a lot of sense (looking at wp code)…

two ways it can do it… 

first requires you to not be on a valid network site…  in this case, with the define, you go to the main site, without it you would go to the signup page…  so if it was this one, regardless of the NOBLOGREDIRECT setting, you would redirect to the wrong page…  so dont think its this case…

second requires 404 redirect that you were referring to…  on this one, you have to be on the main site and get a 404 status…  but there should not be any 404s going on here… it checks the 404 status in the wp query…  on my test site, I see no 404 headers going by, which there shouldnt be… and the 404 flag in the wp query is not set…  so this should not be happening either…

and turning that define on has no effect on seeing the forum on my multisite test site…  so something else still at work to be generating a false 404 on your server…

that said, glad you found the workaround for it…

I don’t think it was generating a 404 on my server either.  There may be a difference between subdomain and subfolder installs.  I almost always use subdomains, so I’d have to investigate.

If/when you have time, maybe see on a subdomain install if you add that, install SPF on the main blog, what happens after you edit the WP page.  Remember, the problem only rears its head if you edit the WP page. If I set up SPF and never touch the WP page, with the directive included, SPF works fine.

All I can say is that turning off the directive allowed SPF to work after editing and re-editing the WP page, and turning on the directive with my small script also worked.

back to the users error… able to see it now on your test site…

but for the record, you stated essentially no plugins…  but you do know that even deactivated plugins are loaded by WP, right? at least the main plugin file (how else can it display the plugin info?)…  so yes, deactivated plugins can still cause conflicts and definitely consume memory and resources…

not saying thats the issue here, just making sure you understood that…

dang, so I guess WP multisite removes the plugin editor even for network admins??? argh… 

Was hoping to add some debug code… it looks like we are generating an error message and trying to output it to the screen which is causing the problem…

researching further…

DOH! forgot about a new ‘feature’ we added in the admin… an error log…  need to remember to get folks to look in there… forum – toolbox – error log…

anyways, it gives a bit more info about what is going on when you add the user:

file:
line:
function: sp_create_member_data
error: Duplicate entry ‘9’ for key 1

INSERT INTO wp_sfmembers (user_id, display_name, admin, moderator, avatar, signature, posts, lastvisit, checktime, newposts, admin_options, user_options, feedkey) VALUES (9, ‘somebody’, 0, 0, ‘a:1:{s:8:”uploaded”;s:0:””;}’, ”, -1, ‘2011-09-10 04:56:01’, ‘2011-09-10 04:56:01’, ”, ”, ‘a:4:{s:10:”hidestatus”;i:0;s:8:”timezone”;i:0;s:6:”editor”;i:1;s:8:”namesync”;i:1;}’, ‘3004a607-1d60-468d-8dd2-ac689a4f1906’)

so the user already exists???  most odd…  and I do not see this on my multisite test site…  and its the fact of generating this error in this case and trying to display to the screen which is causing the headers already sent error… so, yeah, we have to deal with that…

but not sure where this error is coming from…  Its almost as if our user creation routine is getting called twice… and its just hooked into the wp create user hook…

Is there any chance that you give us FTP access to this site so we can add some debug and trace code to follow it back?

On plugins.  Yes, I stated essentially no plugins, but that was for a different site than the 1 I gave you access to.  I was testing the redirect issue on that other site, and then tested the user creation issue there as well.  When it displayed the error, I was easier for me just to set up your access on that site, since it didn’t seem to be plugin-related.

I’m not sure I agree with your statements on deactivated plugins, but I’ll have an open mind and listen.  On the admin side, yes, WP has to get the plugin info on deactivated plugins, but in my tests, I haven’t seen deactivated plugins consume memory and resources.  As for conflicts, I don’t think deactivated plugins can cause conflicts.  Deactivating plugins is one of those standard debugging techniques for identifying a plugin conflict, so it wouldn’t be so widely recommended if even a deactivated plugin could still cause a conflict.  I’d love to get more info on those issues or clarification on what you meant.

I PM’d you with FTP access.  Hope you get it sorted it out.  I’m sweating bullets here not being able to add users to test sites.

okay, cool, will take a look today…

and my only real point on deactivted plugins is that wp still has to read them into memory and scan for the header info. That takes time and memory.  and errors in the plugin could cause issues… absolutely agree on deactivating for purpose of testing conflicts…

from a system perspective, removing plugins you are not using still makes the most sense…

okay, I can now make this happen locally and think I understand what is going on… will work a fix later today…

thanks for the access!

Bill Murray, just committed some changes for this… If you can grab the latest from svn or a nightly later tonight, you should be good to go.  would appreciate some feedback once you get the latest (and not from the wp updater)

I updated 2 networks from the SVN, tested, and both seem fine.

When I first went to the Forum menu choice, instead of seeing the usual long list of entries, I saw 1: to upgrade SPF.  I ran the upgrade, then repeated the steps that previously triggered the error, and simply got back the usual message that the user had been created.  Mind you, I didn’t test other user creation scenarios, but I’ll try to do that when time permits.

Glad you were able to track it down.

I’ll leave the access around for a bit in case something else comes up that needs debugging.  I’m in no particular hurry to remove it, but I can add it back easily enough at any time.

sounds good…  yeah, the wp docs are wrong about some of the multisite hooks…  so we were catching two of them for new user creation even though wp says one of them wouldnt be triggered in the case you were doing… not a big deal to recognize once I knew the wp docs were wrong…

thanks for the patience and access to site…