WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 8 months 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:

Description

Hi,
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 2 years ago.
sunrise.php goes to wp-content
blog-user-tables.php (3.0 KB) - added by lightningspirit 2 years ago.
blog-user-tables.php goes to wp-content/mu-plugins

Download all attachments as: .zip

Change History (25)

comment:1 nacin3 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.

comment:2 fale3 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 ;)

comment:3 scribu3 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.

comment:4 fale3 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

comment:5 tmoorewp3 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.

comment:6 fale3 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

comment:7 PeteMall3 years ago

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

comment:8 lightningspirit2 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...

comment:9 scribu2 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.

comment:10 scribu2 years ago

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

comment:11 lightningspirit2 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!

comment:12 nacin2 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.

comment:13 scribu2 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 it.

Version 0, edited 2 years ago by scribu (next)

comment:14 lightningspirit2 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!

comment:15 scribu2 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.

comment:16 Ipstenu2 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.

comment:17 SergeyBiryukov2 years ago

  • Version changed from 3.4 to 3.0.1

Version field indicates when the feature request was initially suggested.

comment:18 lightningspirit2 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!

comment:19 lightningspirit2 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...)

Description:
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!

Issues:

  • 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...

Instalation:

  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! :)

lightningspirit2 years ago

sunrise.php goes to wp-content

lightningspirit2 years ago

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

comment:20 lightningspirit2 years ago

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

comment:21 scribu2 years ago

  • Keywords has-patch removed

Sorry, but that's not a patch.

comment:22 lightningspirit2 years ago

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

comment:23 nacin8 months ago

#25167 was marked as a duplicate.

Note: See TracTickets for help on using tickets.