deafwiggle

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

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

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

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

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

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

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

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

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

I have reproduced the problem exactly on a local development server (LAMP setup) which uses local domain names (not “localhost” or IPs).

Not sure if this makes any difference: both the shared hosting and my local development server are running the suhosin Apache module.

Anyone (else) have suggestions?

Cheers!
Dirk

Real hostname on a cPanel account at a shared hosting provider. You can see the actual site at:
wp.pagestep.com
Subsite at:
wp.pagestep.com/subsite

I have had no issues with independent WP sites on the same host (I’m getting more WP requests from new clients, so want to have a single WP install instead of having to deal with multiple WP sites every time an update comes out).

Thanks for your ongoing efforts, jkhongusc!

Cheers!
Dirk

Addendum: Hadn’t noticed this before, but if I log in as superadmin to the subsite by going to:
example.com/subsite/wp-login.php
it takes me to the Dashboard for the subsite:
example.com/subsite/wp-admin/

So, logging into subsites works properly for superadmin users, but not subsite users. ??

Thank you, jkhongusc.

I’ve done a complete re-install of everything:
– removed all DB tables
– removed all software
– uploaded freshly unzipped WP 3.6.1
– applied multisite process
– added one subsite
Nothing else.

.htaccess contents:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress

wp-config.php contents:

define('DB_NAME', 'db');
define('DB_USER', 'db');
define('DB_PASSWORD', 'dbpassword');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
// AUTH_KEY to NONCE_SALT were updated for this new install but
// left out of this post as it was messing up its display
$table_prefix  = '_';
define('WPLANG', '');
define('WP_DEBUG', true);
// multi-site insertions
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
if ( !defined('ABSPATH') )
  define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . 'wp-settings.php');

Set up subsite and verified that the subsite user has the Administrator role and has proper access to the subsite once logged in and URL is changed.

Problem continues. ??

Note: You mention that users with the Subscriber role get redirected to wp-admin/user/. I get this with a subsite user with the Administrator or Editor role, even though they have appropriate access once I manually update the URL from wp-admin/user/ to subsite/wp-admin/.

I’m convinced this has something to do with how WP manages redirection and that likely collides with something in .htaccess.

Cheers!
Dirk

PS I thought perhaps cookies were somehow involved, so cleared all cookies for this site, and get the same results.

I logged in as superadmin into the primary site, listed all sites, entered the Dashboard of the subsite, and subsite user has role of Administrator.

I logged out of the primary site and then logged in as user of subsite via example.com/subsite/wp-login.php, made the (problematic) URL update to example.com/subsite/wp-admin/, went to Users. User has the Administrator role.

I then re-logged in as superadmin, changed the subsite user’s role to Editor and get exactly the same results. It appears that a subsite user’s role is not the culprit. (I checked and the capabilities change appropriately for the subsite user when switching between Administrator and Editor roles, but the problematic URL change happens in either case.)

Cheers!
Dirk