Multisite sub-site login

Disabling suhosin (in simulation mode via .htaccess, removing its entry in php.ini and removing the suhosin.so module) made no difference. ??

This is my very last guess. I would like you to edit this file, first back it up
1) cd <wp base>
2) cp wp-login.php wp-login.php.bak
3) edit line 643 of wp-login.php
Original:

if ( is_multisite() && !get_active_blog_for_user($user->ID) && !is_super_admin( $user->ID ) )
        $redirect_to = user_admin_url();

To:

if ( is_multisite() && !get_active_blog_for_user($user->ID) && !is_super_admin( $user->ID ) )
        $redirect_to2 = user_admin_url();

Then try to log in as the subsite admin. My guess is that when you log in as the subsite admin you are redirected to what user_admin_url() returns which is /wp-admin/user/ IMO, you should not be passing that condition.

Hmmm. Thank you for pointing me in the right direction, jkhongusc. I’m going to look into this a bit further and see if there’s a better solution than by-passing WP’s redirect here. I’ll update here when I’m done.

Cheers!
Dirk

IMO, try the 1 line change (actually 1 character) to see if it works. You can undo the change afterwards.

I wanted to see if that line was causing your redirect problems. Once you identify where the redirect is coming from, I can help you identify why. I think is_multisite() and is_super_admin() is working, but get_active_blog_for_user() is not returning anything. My guess is that might have to do with the way you create the user and assign the user’s role.

There appears to be a bug in WP multisite new subsite creation. When I create a subsite, it creates the user I specify, adds them as a user (Administrator) to the subsite, and when I try to log in as that user, it takes me to wp-admin/user/.

I then added another user (Editor or Administrator) to that subsite and logged in as that new user. WP now takes me (correctly) to subsite/wp-admin/.

I added some debugging code to wp-login.php to verify this. Just before the line:
if ( ( empty( $redirect_to ) || $redirect_to == 'wp-admin/' || $redirect_to == admin_url() ) ) {
(at about line 639) I inserted:

var_dump(get_blogs_of_user($user->ID));
exit;

When I log in as the initial subsite user, this shows an empty array. If I log in as the extra subsite user, it shows an array with info on the subsite.

Work-around appears to be to create an extra user for each subsite and assign them an appropriate role (in my case, this would typically be Editor).

Odd.

Hopefully this will be fixed in WP 3.7. If it isn’t, I may file a bug report.

Thank you everyone for helping.

Cheers!
Dirk

Whoops! Posted my last reply before I saw your response, jkhongusc. You’re right. get_active_blog_for_user() calls the same get_blogs_of_user() I used in my debug lines. I don’t think there’s anything wrong with either of those functions, but rather, something in new site creation is not attributing the subsite to the user it creates at the time the subsite is created – even though everything else within WP appears to be OK.

Thanks again!

Cheers!
Dirk

I’ve been trying to reproduce the work-around for this issue. It seems I may have spoken out of turn. Several times I’ve re-installed WP, enabled multisite, created a subsite, added another subsite admin. No matter how I create anything (subsite or additional subsite admins), WP still takes me to wp-admin/user/ instead of subsite/wp-admin/.

The call to get_active_blog_for_user() in wp-login.php still indicates that both users (the one created at subsite creation and the added subsite admin) are not associated with the subsite (according to get_active_blog_for_user() anyway). The odd thing is that WP still allows either the subsite user or added subsite admin to actually admin the site – but only after having to manually change the URL (or visit the site while logged in and selecting Site Admin).

Anyone with ideas?

Dirk

Note: My systems do not exhibit the problems you are reporting. Either your system or your WP installation/configuration must be introducing some element of error.

If I were debugging this I would drop in print statements into the offending function. I believe the problem stems from get_blogs_of_user() which is in /wp-includes/user.php. I would insert multiple print statements into get_blogs_of_user() to see how where it returns the empty array. I “tail” my apache error file and use this print statement in my WP code:

error_log("reached point #1",0);
<WP code>
error_log("reached point #2",0);
<etc>

Once I pinpoint the exact area in the code that is the problem, I drop even more error_log messages, usually outputing variable values.

Here is exactly what I would do:
1) backup <wp base>/wp-includes/user.php
2) edit /wp-includes/user.php and add the print statements into get_blogs_of_user()
3) create a test php file – here is one especially for you (<wp-base>/mytestfile.php):

<?php
require( dirname(__FILE__) . '/wp-load.php' );

$user = wp_get_current_user();
echo "you are currently logged in as: ".$user->user_login."<BR>\n";
$blog = get_active_blog_for_user($user->ID);
if ($blog) {
echo "your active blog : ".$blog->blog_id."<BR>\n";
echo "your active blog : ".$blog->domain."<BR>\n";
}
var_dump(get_blogs_of_user($user->ID));
?>

4) login as the subsite admin
5) access the mytestfile.php via browser. My output looks like this:

you are currently logged in as: jkhong
your active blog : 1
your active blog : www.domain.com
array(2) { [1]=> object(stdClass) <removed rest>

I’m a PHP developer, but I’m not (yet) familiar with the WP environment/paradigm. Your pointers to where problems may lie are very helpful, jkhongusc; thank you.

A few notes:
– I’ll watch apache’s logs on my development server. I’ve now set up custom access and error logs for just my local WP sub-domain. I’ve also enabled PHP’s error log.
– The two environments I’m using are nearly identical LAMP setups. There is nothing unusual about either of them except perhaps the use of suhosin (which has been determined to not be the cause of this problem). Specifically, my local development LAMP setup is a basic install on Ubuntu 12.04LTS (64-bit), with only curl, gd, PEAR, and suhosin as added modules (I added suhosin only to ensure my development environment mirrors my live environment reasonably closely). PHP reports all errors and, as far as I can tell, I’m not getting any PHP errors in any of the processes involved. (I’ll ensure WP is not suppressing errors as well, and see what happens.)
– I am familiar with how to debug PHP code and have narrowed the issue down to WP’s get_blogs_of_user() (by entering debug statements in wp-login.php at about line 639):

var_dump(get_blogs_of_user($user->ID));
exit;

In my environment, users added by WP when adding a subsite as well as users added manually to a subsite all produce an empty result (even though those same users can admin the subsite according to roles I’m assigning to them). This does seem to indicate something awry in get_blogs_of_user(). I was thinking that perhaps user creation is not creating/setting some field in the DB that is used selectively by different functions (i.e. multisite login looks for a specific field that simple menu selection or page selection doesn’t).

I’ll try your suggestions about debugging wp-includes/user.php as well as maybe tracing (via debugging code) how new users are created, and report back.

PS I’m a bit busy with another project so this may take a day or two.

Thank you again for all your help, jkhongusc. Very much appreciated.

Cheers!
Dirk

jkhongusc – STOP TELLING PEOPLE TO EDIT CORE

You are causing long term HARM to them, and the community. You may be thinkging it’s the fastest way to debug, and I’m here to tell you it’s the fastest way to SCREW UP your site.

Stop it. EVEN THOUGH you’re showing them how to debug WP, which is great, your advice of late has been ‘Need to fix? Edit core!’ and that is horrible advice. PLEASE tell them that these edits are TEMPORARY.

WordPress 3.7 will include auto-update. If you make these edits, they will be removed magically, and everyone will be upset, and I will cheerfully tell them it’s your fault for suggesting it in the first place. Get it? Good.

Now to the problem at hand. @deafwiggle – is your table prefix really just this?

$table_prefix = '_';

It should be $table_prefix = 'wp_'; or something. Just an underscore can cause problems.

Also, on your totally clean install, are you ABSOLUTELY sure you have no plugins installed? nothing in mu-plugins? Nothing in the wp-content folder as a drop in?

Mika, I’m well aware that – except temporarily for debugging purposes – editing core is not advisable.

Yes, my table prefix is just “_” – but it’s only that because WP no longer allows it to be empty. I’ll try things again with “wp_” and see if that resolves anything.

And yes, every re-install was fresh from a zipped (actually tar’d) file, .htaccess and wp-config.php re-done, etc. No plugins (except whatever WP itself might install/activate). Literally, the steps with each install are:
1) drop all tables from DB
2) untar WP into dev server directory
3) edit wp-config.php to use DB and “_” table prefix (I’ll leave the table prefix alone on my next attempt)
4) run WP install
5) edit wp-config.php to enable multisite
6) log in to admin and set up networking
7) edit .htaccess and wp-config.php according to instructions
8) add subsite
9) add additional subsite user

Aside: I did a quick search and found that table names starting with an underscore may cause issues (I couldn’t find anything definitive – except suggestions that table names should be quoted if they contain special characters). I’ll post back when I’ve tried this.

Second aside: I do not understand why WP now requires something in the table prefix. It didn’t used to, and using a table prefix should be at the discretion of the developer/implementer; it should not be forced. In my case, my WP network will comprise the only sites on a hosting account’s DB, and does not need a prefix. Using one only clutters things unnecessarily.

Thanks for suggesting this, Mika.

Cheers!
Dirk

Mika,

Leaving the $table_prefix value at ‘wp_’ solved this problem. Thank you!

PS I still have an issue with WP requiring anything to be in this prefix, but that’s for a different time. ??

Cheers!
Dirk

Awesome, glad it was an easy fix =)

IMO the prefix is a security feature. It is best to use something unique as the prefix. I would not recommend using ‘wp_’

PS I still have an issue with WP requiring anything to be in this prefix, but that’s for a different time. ??

There is a technical reasons for this, and it’s Multisite.

I will note that your prefix is not a security issue though, since any attacker worth their salt will be using WP functions to call the DB (no one goes after wp_ directly anymore).

Pretty much all CMS ask you to use a prefix ??

I also do some multisite Drupal development and it does not require table prefixes. (I won’t discuss my own multisite framework. ?? )

Cautioning WP developers to be careful with table naming (table prefix selection?) would make more sense than requiring an arbitrarily selected table prefix, and not have any warnings about not using special characters.

As far as security is concerned, all the table naming conventions you care to apply/implement are of no use whatsoever; careful password selection for both hosting and DB is.

Again, thank you Mika and jkhongusc for all your help. I’m also glad it was an “easy” (though, in my opinion, unnecessary) fix. ??

PS It appears that WP has problems with table names starting with special characters only in some areas. I may go through WP core and see if there are table references that are not quoting table names – which would seem to be the only reason for WP having difficulty with table names starting with a special character. (No Mika, I won’t implement hacked core code on my production sites; I’d be submitting patch suggestions to WP developers instead – including suggesting making the table prefix optional – as it used to be.)

Cheers!
Dirk