Make WordPress Core

Opened 10 years ago

Closed 9 years ago

Last modified 3 weeks ago

#15467 closed feature request (wontfix)

Multisite with separate users table

Reported by: fale Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Multisite Keywords: close
Focuses: Cc:


I'm using WP with the network option since 3.0 has been released. I think that is very cool, but I think that the user management is not at a good level.
At the moment, every user must register to the first site and the admin should 'bring' them to the wanted site. Some plugins (I use Multisite User Management) have been created to try to resolve this problem.
My experience in wp-networks teach me that there are two ways to intend a network:

  • something like wordpress.com
  • a bounch of sites that are together only for administration purpose.

The actual implementation does not respond to any of the previous cases. In fact to be able to use wp-network for the first case, you have to install a plugin that brings your new users across any site of your network, and for the second purpose the actual implementation of wp-network has huge problems.

I think that the best way to resolve this, is to ask the user what he wants. During the creation of the network the system does ask the user if he prefers a sub-domain install rather than a sub-folder install. I think it should also ask the user if he prefers an installation with a single user db or a user db for each site.

I was thinking which was the best way to manage the two things: for the first case, I think, the actual way is very good (it only needs to create the new user on all sites instead of delegating this to the admin/plugin). For the second case, I think, the best way is to have an user db for each site, each one with different values (yes, a person could register himself on site 5 and appear only in the wp_5_users table). As soon as a user is made super-admin he is 'replicated' on each user table. When a new site is created, the user table of that website will be populated only by the super-admins.

I think this would make WP the best CMS/blogging platform ever seen :)

Attachments (2)

sunrise.php (4.5 KB) - added by lightningspirit 9 years ago.
sunrise.php goes to wp-content
blog-user-tables.php (3.0 KB) - added by lightningspirit 9 years ago.
blog-user-tables.php goes to wp-content/mu-plugins

Download all attachments as: .zip

Change History (29)

#1 @nacin
10 years ago

  • Keywords close added
  • Severity changed from major to normal

I covered this in IRC today. I mentioned that if you wanted to set up a network like this, then you would be better off switching table_prefixes in wp-config. That's pretty much exactly what you're looking for here.

If you want network plugins, then use mu-plugins. As long as you're using the same codebase, then the themes and plugins will be shared, with per-site settings.

#2 @fale
10 years ago

Probably was another guy, the one in IRC, since I don't join IRC since august ;).

I know is possible to create both kinds of networks (I have them up and running), but I'm saying that implement them directly in WP would make WP awesome for a lot more users ;)

#3 @scribu
10 years ago

  • Component changed from Users to Multisite
  • Summary changed from User managment on Wp-Networks to Multisite with separate users table

If we were to do this, the only common tables left would be wp_sites and wp_blogs.

I don't think the benefit of those tables justifies the amount of work needed to allow separate users tables.

#4 @fale
10 years ago

I think users are different from plugins and themes. Plugins and themes have sense to be installed only by a super-admin because there is new code, so possible bugs coming... but users are not likke this, imho

#5 @tmoorewp
10 years ago

In my experience from running MultiSite, there isn't any benefit to having separate tables for users. Blog admins of subsites can, with the right settings, add users to their blogs -- super admins aren't the only ones able to add users.

Having separate users tables would introduce too many issues (non-unique usernames and non-unique email addresses, for starters), which would make it much more difficult for a super admin to manage a network, I think.

#6 @fale
10 years ago

the problem is that, even if you delegate this to admins, there still is a work for admins/superadmins. In the other way, would be possible to leave all the work to wp/the user...

About the non-unique users... I don't see the problem...

Btw: imho, it can also be solved givin the user the impression that is registering on the site he wants, and not on another site

#7 @PeteMall
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#8 @lightningspirit
9 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 3.0.1 to 3.4

I think the problem is the user level.

In my experience the idea of having separate user tables is good for WP hosting in a single install, but not for a network like wordpress.com.

I think it could be an checkbox option while installing the multisite: "Separate user table for each blog?"

If the admin turns it on it should:

  • create a separate wp_$blogID_users and wp_$blogID_usermeta tables for each blog to hold all the users that belongs to that blog.
  • create a central wp_users and wp_usermeta tables to hold network admins.

In this case, if the admin promote a blog user to manage the network it will replicate the user to wp_users.

The same thing happens if someone is trying to create a new user in the wp_$blogID_users but that user exists in wp_users, it will only replicate to wp_$blogID_users.

Also this is very good to host blogs that want themes like the ones in the AppThemes...

#9 @scribu
9 years ago

I think it could be an checkbox option while installing the multisite: "Separate user table for each blog?"

Hi lightningspirit, you might not know this but we're not particularly fond of checkboxes (http://wordpress.org/about/philosophy/#decisions), especially when they imply a fundamental architecture change.

#10 @scribu
9 years ago

Also, you didn't actually mention any tangible benefit that having separate user tables would bring.

#11 @lightningspirit
9 years ago

Hi scribu,

Thanks about the link, I almost forgot it! :)

What do you mean by "tangible benefit"?

As a developer and deployer of WordPress Mulsites network I found sometimes necessary to have two different user_tables because sometimes the blogs that run the same network are very specific. As an example:

  • A network of websites that run inside the same WordPress install for different clients and they have different users. The idea is to cut off the "sensation" that those websites are running in the same architecture.

My concern is about giving the admin this possibility, to separate exclusively those websites.

Maybe this is a matter for a plugin and not a functionality provided by the core, but maybe we can hack the core to provide those hooks for plugin to extend themselves.

I know there are some constants like CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE but my experience is that it is not enough...

May I propose some new code for the code to extend this possibility, if the community agrees?

Thank you!

#12 @nacin
9 years ago

Last year, I briefly took a crack at a plugin that tried to implement this. I never got much further than the design stage, but I was confident that enough hooks existed in core to do this. I suggest we again close this as wontfix.

#13 @scribu
9 years ago

The idea is to cut off the "sensation" that those websites are running in the same architecture.

You can do that pretty easily through a plugin:

  • remove the My Sites menu from the admin bar
  • use custom registration form, instead of the one on the main blog

and that's about all you need to do.

Last edited 9 years ago by scribu (previous) (diff)

#14 @lightningspirit
9 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

@nacin I will try to create a plugin for this functionality, I will informe you if I can get some news on this...

@scribu I understand your point, but deeply if a logged in user of the site A.com visits the website B.com (A and B in the same network but from two different clients) the user will be logged in, but withour permissions to visit the admin of that site. The problem is, if the user wants to register for site B.com, what happens? B.com responds that the user cannot register because they are already registered... don't you think this is confusing? :S

Okay, maybe I should use two complete different instalations for A and B, and maybe the purpose of the multisite is not in that direction. If this is answer I think we should write somewhere in the Codex to advise users about what "Multisite is not". But again, just for fun, I will try to plugin it and if I get success I announce it here. :)

Thank you both!

#15 @scribu
9 years ago

Indeed, multisite isn't meant for sites that are supposed to be completely independent. Feel free to modify the Codex to make it clearer.

I think I finally get why the ManageWP service sprang up.

#16 @Ipstenu
9 years ago

Two thoughts down Scribu's path

1) Make a check on your custom registration page 'if user && email already exists, just add them to site B. Else create new'

2) Make a 'hide admin bar' check in a mu-plugins. If the user isn't a member of THAT site, remove the admin bar. That would hide it so they wouldn't know they were a member.

#17 @SergeyBiryukov
9 years ago

  • Version changed from 3.4 to 3.0.1

Version field indicates when the feature request was initially suggested.

#18 @lightningspirit
9 years ago

@scribu Indeed, but I will try it just for test (and fun!)

@Ipstenu thank you, I think that's sufficient to do what I want!

#19 @lightningspirit
9 years ago

Between yesterday and today I made a draft of what could be a plugin to achieve this functionality.

I think I did it! :)

NOTE: Use this method in test environments only! It is not stable enough (and I think it will never be...)

Those two files ( sunrise.php and blog-user-table.php ) can create separated user tables for each blog in a multisite instalation.
It lacks the possibility of creating users inside a blog, even if the netwok option is enabled, but I think it might be an issue related to capabilities.

It actually performs what it is expected: separate users for each blog!


  • one have to create the users manually in MySQL tables due to a capability issue that I wasn't able to seek.
  • Network panel just shows users from the global table (don't know if this is really an issue)

Those files could be the first steps to "recreate" this functionality with a plugin in WordPress I think...


  1. Install a WordPress 3.4 from the trunk - make sure it is used just as a test instance
  2. Create at least a blog in your multisite test install
  3. sunrise.php goes to wp-content/ directory
  4. blog-user-tables.php goes to wp-content/mu-plugins/ directory
  5. Put define('SUNRISE', true); in wp-config.php file
  6. Using SQL in a MySQL browser (like phpmyadmin) copy an existing or create a new user inside wp_2_users and wp_2_usermeta (change the generated SQL as necessary)
  7. Try to login with the new account in the new blog

Tested in a local instalation of a Multisite WordPress 3.4 (trunk).

No security tests made! Please, avoid to use it in production sites.

Have fun! :)

9 years ago

sunrise.php goes to wp-content

9 years ago

blog-user-tables.php goes to wp-content/mu-plugins

#20 @lightningspirit
9 years ago

  • Cc lightningspirit@… added
  • Keywords has-patch added

#21 @scribu
9 years ago

  • Keywords has-patch removed

Sorry, but that's not a patch.

#22 @lightningspirit
9 years ago

Sorry, I mistook the tag! Yes, defenitely is not a patch.

#23 @nacin
7 years ago

#25167 was marked as a duplicate.

#24 @Solinx
6 years ago

"Also, you didn't actually mention any tangible benefit that having separate user tables would bring."

As a small dev team we're looking to use a multi-site install to drastically simplify our maintenance efforts for several customers who are running on the exact same codebase. Our customers rightfully demand access to the DB in which their data is stored. Obviously we only want to give them access to their own data. This is particularly true for their user data. Aside from the ethical aspect there are privacy regulations to take into account.

We can use Multi DB to store most data in separate DBs, but this is not the case for User data.

Thanks for taking the initial steps.

Wouter van Dam

#25 @lukasdan
5 years ago

do anybody test it with WP 4.5?

Best regards,

#26 in reply to: ↑ description @anonymized_6443559
20 months ago

I'm actually quite disappointed in seeing that this didn't gain any traction. Here I am now 9 years later trying to do the same thing, for very much the same reasons managing multiple client sites in one "installation".

@nacin brings up one could simply define a different db prefix for each site to do this without even implementing multisite, and for the most part the claim that this is effectively the same is mostly true. There is one key difference I see, in the code by @lightningspirit there is one key feature that would not exist in simply switching db prefixes, that is a set of core "network admin" users that would have global access (ie for me and any staff I have) without having to add user accounts specific to each client site, IMO that would be quite useful and the tangible benefit that @scribu said is missing from this. Granted it may be a rarely useful benefit but for those of us who would use it that would be very helpful. I would have liked to see this be an option even if by a define statement in wp-config like "define("PERSITE_USERS", true);" or something. Or at least if a stable production ready plugin were available that would suffice too, but that's beyond my capabilities sadly.

Anyway thats my 2 cents on this but I think in the end its probably something best left to a plugin because its very much an edge-case, I just wish someone who has a better deeper knowledge of core and how to make this work in a secure manner would take this up for an official plugin that gets actively maintained.

#27 @maidot
3 weeks ago

This is actually a very needed functionality, which is not that hard to apply nowadays!

Note: See TracTickets for help on using tickets.