Multiple wp_options tables to share content across installs
My application has >10
user_roles, each able to perform completely different tasks, provided with an custom backend and no access to
The extra functionality each
user_role gets to use is handled via multiple plugins. Each
user_role interacts on the same data (posts, taxonomies etc.)
The idea I had is to use a single installation per one or more
user_roles connected to a single database to share users, posts etc but with different plugins loaded, so simply a separate
The goal is to provide independent login areas(e.g subdomains, I don’t want partners to use the same login as customers), easier routing (different permalinks and rewrites for each role) and less time checking for permissions of logged in users on protected sections of the site. Also I could disable themes for the ‘backend-only’ roles and only load the plugins each role needs to perform their actions.
My guess is, that a nice side effect would be a significant speed boost since the main site for customers is powered by
woocommerce and I wouldn’t need to activate
woocommerce on other instances or vice versa… custom plugins would not be loaded in the installation powering the user/customer frontend.
I considered the multisite functionality but this wouldn’t be the right path, since each blog has it’s own posts table, which is not practical since I need to have all users use the same data.
WordPress provides these constants to set up a custom users table, to share users among multiple installs:
define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );
But it does not provide a method to define a custom options table, see this ticket https://core.trac.wordpress.org/ticket/7008
This thread provides a solution which is a bit of hacky but works fine in my initial test:
TL;DR: Modify wpdb-class by copying the functionality of
CUSTOM_USER_TABLE to use
Btw. he states, content of the second site would link to the first, which is just an estimate I guess… so no, it does not, it works completely fine.
My question now is, do you see any kind of problems I may face with this approach in general? (many installations, one database, same database tables and an individual options table or each install)
Would you suggest a different approach or would you stay with the default wordpress-way of doing things?
What would be a solution to keep the ‘hack’ of modifying wpdb.php persistent in case of core updates?
Any other drawbacks besides maintainability? (which I think I gain a lot of by doing this)
When this project was stared almost half of the requirements didn’t exist and wordpress+woocommerce was chosen due to simplicity. Using wordpress as a application framework is far more difficult and limiting, than I thought.
Thanks in advance for your help!
The question how to keep the modified version of wpdb in case of updates, or how to use custom table names besides CUSTOM_USER_TABLE was answered in a wordpress support ticket.
The solution is to extend the wpdb-class, alter the table names in the
tables function, save it as db.php to wp-content and use it as a drop-in. This way you can define custom names for all tables and avoid problems on updating core. (See: #33320)