WordPress.org

Ready to get started?Download WordPress

Forums

[closed] Multiple WP sites from same DATA TABLES (not just DB) (11 posts)

  1. Rafael_Magnvs
    Member
    Posted 1 year ago #

    I have 5 WP websites that are installed under the same database. And, for three of them I would like to use the same exact TABLES. From my understanding, what determines which data table will be used is the active theme (set in wp_options table). Am I correct here? .

    If so, is it correct to assume that if I use the same theme on all three, the content would all come from the same data table? Further, which configuration determines the active template in the wp_options table, is it the Theme name set in the style.css?

    Context: These three website will use the same core functionality, in other words, same theme, but there will be significant layout differences and not all themes will offer all functionality. It is sort of lika A/B testing if you will..

    Any thoughts on the subject would be aprreciated.
    Thank you.

  2. esmi
    Forum Moderator
    Posted 1 year ago #

    Three sites cannot use the same tables because both the home url and the site url is also stored in those tables. As a result, you can only use one set of tables per site url.

  3. Rafael_Magnvs
    Member
    Posted 1 year ago #

    is it totally impossible or not simply achieved?

  4. Rafael_Magnvs
    Member
    Posted 1 year ago #

    What about this alternative?

    If the URLs are the only difference between the installs I could edit
    the config.php(1) files and add:

    define('WP_HOME','http://A.mysite.com'); define('WP_SITEURL','http://A.mysite.com');

    on the config.php(2) add:

    define('WP_HOME','http://B.mysite.com'); define('WP_SITEURL','http://B.mysite.com');

    Both installs will use the same database info only the URLs being different. If I define as described above, it should prevent the WP install from writing in the database because update_option is not used in the process.

    Does that make sense? or my understanding of WordPress is incorrect?

  5. bcworkz
    Member
    Posted 1 year ago #

    There are values still stored in the options table that are used, simply defining the constants is not enough. There could be a way to intercept options table queries and return needed values, but the idea of 3 installations randomly writing to the same tables sounds like a very bad idea.

    I would rather see a child theme that loads the appropriate theme templates and CSS based on the requested subdomain. All subdomains would actually go to the same, single installation.

  6. Rafael_Magnvs
    Member
    Posted 1 year ago #

    Hey bcworkz, thanks for the input, once again..

    Let me try to explain my situation better, to see if it makes any difference.

    1. I have mywebsite.com, a.mywebsite.com and b.mywebsite.com

    2. The all already share the same database. (different tables, except of wp_user and wp_usermeta)

    3. I intend to write information (posts, pages) on the main domain only.

    4. I want the a and b sub-domains to display the same information. The theme is essentially the same. It will only show the information in different formats. I do not need or want sub-domains to have writing capabilities per say. (so, if it's an option, I would be satisfied with the sub-domains having only reading permissions.

    5. I would like to do something similar to what I did when I shared the user database across the websites. How come it's not possible to define on the config.php file the tables the Installation uses for its posts? And why would that be so bad?

    What do you think?
    Thanks in advance!

  7. bcworkz
    Member
    Posted 1 year ago #

    You cannot just change the home and site url constants because there are functions that pull urls directly from the options table, get_site_url() for example. Why have constants then? I can't answer that. If you are determined to use this scheme, you could hook the 'option_{$option}' filters to ensure the value returned to various functions asking for the option values is correct for the situation.

    I'm not sure your word to not write to the DB from various subdomains is enough. You should go through and install measures to ensure it is not even possible, as there may be DB writes by the system we are unaware of. Perhaps by different DB users for each WP installation where only one has write privileges? I can't say if the inability to write will break WP or not.

    So I would say your scheme is maybe possible, but implementing it well will take some work. I still think having all subdomains routed to the same installation makes a lot more sense, especially since the only difference is the format of displaying information. This could be easily be accomplished with some custom templates. This fits within the operational intent of WP, whereas sharing tables does not. For the sake of unforeseen problems, it makes a lot more sense to not go outside the intent as much as possible.

  8. Rafael_Magnvs
    Member
    Posted 1 year ago #

    I think I found the solution I was looking for.
    After some digging around, I came across Support Thread from 3 years ago. You can click here to see that thread.

    I am currently using the 3.5.1 WordPress version. Anyways, I went to wp-includes/wp-db.php and did the following (as suggested in the post):

    1. On line 683, I found

    foreach ( $this->tables( 'global' ) as $table => $prefixed_table )
    				$this->$table = $prefixed_table;

    2. Below $this->$table = $prefixed_table; I added the table I wanted to share. (Below you have an example with alternatives to all possible default tables - you can pick and choose which ones to use):

    foreach ( $this->tables( 'global' ) as $table => $prefixed_table )
    	$this->$table = $prefixed_table;
    	$this->options = 'YOUR_PREFIX' . 'options';
    	$this->posts = 'wp_' . 'posts';
    	$this->categories = 'wp_' . 'categories';
    	$this->links = 'wp2_' . 'links';
    	$this->postmeta = 'wp_' . 'postmeta';
    	$this->terms = 'wp_' . 'terms';
    	$this->term_taxonomy = 'wp_' . 'term_taxonomy';
    	$this->term_relationships = 'wp_' . 'term_relationships';
  9. Rafael_Magnvs
    Member
    Posted 1 year ago #

    This is a "solution" is for different WP installs in different sub-domains stored in the same database.

    But keep in mind that I have just found this alternative and I cannot tell for sure if these hacks have any downsides.

    I will continue with the tests, if I find anything that causes problems I'll post it here.

  10. bcworkz
    Member
    Posted 1 year ago #

    I strongly urge you to find a solution that does not involve editing core WP files. At best, maintenance is troublesome, and could possibly lead to security risks. It appears a solution using hooks and filters is possible, so editing core files is simply lazy coding. You are free to do what you want to your own installation, but please do not suggest to others that such an approach is a sustainable solution.
    Best regards.

  11. Rafael_Magnvs
    Member
    Posted 1 year ago #

    Thanks bcworkz, for the input.
    As I said on the post above yours, I do not claim this solution to be sustainable. It was an alternative that I found from an older post and tried on a current version. I also said that I don't know if this alternatives have any downsides yet.

    I just believe people looking for something similar will be tech savvy enough to make a judgement call on whether or not to use the lazy approach described above...

Topic Closed

This topic has been closed to new replies.

About this Topic