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.
is it totally impossible or not simply achieved?
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?
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.
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!
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.
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';
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.
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.
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…
