Dobri
2013-10-18 14:56:05 UTC
Hi all,
I'm dealing with a problem that I'm trying to resolve in the most elegant way possible. I work for an educational institution which has about 200 sites on a WordPress multisite installation. They want to rip out some of the content from their public domain and put it in an Intranet that's restricted in access from only campus. So they decided to create a separate WordPress multisite installation. Now, I'm trying to figure out how to have users on the two sites sync up without running into permissions issues. We have about 150 users and we constantly add and remove them so it's impractical to keep two sets of users.
TLDR: Two multisite installations, need to have the same user accounts.
Here are two solutions I was considering:
1. Have the second multisite installation read/write to the users and usermeta tables of the first one, kicking up blog_id to 2^32+1 (so it's halfway through the range of blog_id)
That way, I hope, usermeta will not have any permissions conflicts because at that point the two wordpress multisite installations become one in terms of user permissions, just with a huge hole in the ids
TLDR 1: second multisite read/writes to wp_users and wp_usermeta. blog_id for wp_blogs on second installation is bumped up to avoid collisions.
2. Have the second multisite installation READ ONLY from the users table, keeping its own usermeta table and then have a service that runs at midnight for usermeta maintenance (copy over first/last name, etc. from main installation and clean up if user was deleted, make sure to not touch permissions on second site except for the case when a user is removed, etc.). This solution seems safer but users cannot be created/deleted from the secondary installation and users will not be able to change their password (and other things stored in wp_users) on the secondary site.
TLDR 2: second multisite only reads wp_users and maintains its own wp_usermeta.
Which one do you think seems like the better option? Do you have any other suggestions that might work better? Thank you!
~Dobri
I'm dealing with a problem that I'm trying to resolve in the most elegant way possible. I work for an educational institution which has about 200 sites on a WordPress multisite installation. They want to rip out some of the content from their public domain and put it in an Intranet that's restricted in access from only campus. So they decided to create a separate WordPress multisite installation. Now, I'm trying to figure out how to have users on the two sites sync up without running into permissions issues. We have about 150 users and we constantly add and remove them so it's impractical to keep two sets of users.
TLDR: Two multisite installations, need to have the same user accounts.
Here are two solutions I was considering:
1. Have the second multisite installation read/write to the users and usermeta tables of the first one, kicking up blog_id to 2^32+1 (so it's halfway through the range of blog_id)
That way, I hope, usermeta will not have any permissions conflicts because at that point the two wordpress multisite installations become one in terms of user permissions, just with a huge hole in the ids
TLDR 1: second multisite read/writes to wp_users and wp_usermeta. blog_id for wp_blogs on second installation is bumped up to avoid collisions.
2. Have the second multisite installation READ ONLY from the users table, keeping its own usermeta table and then have a service that runs at midnight for usermeta maintenance (copy over first/last name, etc. from main installation and clean up if user was deleted, make sure to not touch permissions on second site except for the case when a user is removed, etc.). This solution seems safer but users cannot be created/deleted from the secondary installation and users will not be able to change their password (and other things stored in wp_users) on the secondary site.
TLDR 2: second multisite only reads wp_users and maintains its own wp_usermeta.
Which one do you think seems like the better option? Do you have any other suggestions that might work better? Thank you!
~Dobri