Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+8 votes
in Q2A Core by

@Scott, @pupi1985, If q2a is hosted on main domain and then other instances of q2a installed on subdomains, similar to stackexchange.com multiple subdomain sites.

example:  q2asite.com main site, movies.q2asite.com, maths.q2asite.com, gaming.q2asite.com, science.q2asite.com subdomains etc.

Option1: Is it good idea to keep single db and then use solution mentioned in below answer


I guess this will make db very big. I dont know other disadvantage. how about speed of sites impacted?...

Option2: have separate db for each site and user base from main Q2A site db (q2asite.com)

What are advantages and disadvantage both option you see? is there any other better way.

also could you please provide solution for option2 here. It will help other.


Q2A version: 1.7.4
For reference: Second installation returns "Table 'qa_users' already exists": https://github.com/q2a/question2answer/issues/575

4 Answers

+4 votes
selected by
Best answer

Here is solution for multi-site.

- Install first Q2A site as normal on main domain myq2asite.com (first instance of q2a), set below parameters as below in qa-config.php

define('QA_MYSQL_TABLE_PREFIX', 'qa_mainsite_');
define('QA_MYSQL_USERS_PREFIX', 'qa_users');
define('QA_COOKIE_DOMAIN', '.myq2asite.com');

- second Q2A site(subdomain site2.myq2asite.com). (second instance of q2a).

qa-config.php and set the users prefix option to "qa_users" same as main site, modify below lines:
define('QA_MYSQL_TABLE_PREFIX', 'qa_site2'); //this line is different
define('QA_MYSQL_USERS_PREFIX', 'qa_users'); //this must be same as main site
define('QA_COOKIE_DOMAIN', '.myq2asite.com'); //this must be same as main site

Now run the installation on the second site. site2.myq2asite.com, it will ask to update tables, just do that.

create normal user account on myq2asite.com

Login to myq2asite.com, it should work for admin and all users on both site.

for avatars, see comments by sama55.

+4 votes

This is my personal impression (may be not a solution).

Basically, Q2A is software for making a relatively small communities, I think that it is not suitable for enterprise (huge scale) site. Especially when sharing user data with multiple sites, there are performance limitations. The reason is ... For huge sites, the load of the database must be distributed. There are several data (tables) to be distributed. The qa-blobs and qa-cache (uploaded data) and qa-users tables should be distributed most (These tables may be distributed to different web and database servers). For example, there is a drop-in called "HyperDB" in Wordpress. This drop-in seems to be effective for database replication, failover, load balancing. However, this drop-in may not be useful on truly huge sites.

@sama55, thank you. so far I have see Q2A single site with 13.5Million visits/month (http://pokemondb.net) according to similarweb.com but dont know what is the highest load it can handle. Also dont know what server config is used for http://pokemondb.net site and if they are facing any performance limitations. but Q2A can handle good traffic.

@Scott can comment on this.

Other site like stackoverflow etc can handle much large load....here is stat according to similarweb.com

Quora.com - 373.5 million
stackoverflow.com - 312 million
stackexchange.com 200 million
Answers.com - 58 million
pokemondb.net 13.5 million (Q2A site)
+6 votes

Unless I'm totally missing something, and without making any core hacks to try to modify the external user feature to be able to actually register users from Q2A, option 2 is not an option as it is not possible.

If you have a main domain with multiple sub-domains, I would expect the idea is that each sub-domain displays absolutely different questions (e.g.: the total Q/A/C displayed in the activity box would display a different number for each sub-domain). This means you will have to have different tables to store the posts (I'm using this table as an example but there are many more tables that you'll need to have exclusively for each site).

However, regarding user management you might want to store users separately for each site, which would mean you will have different user logins per site. Alternatively, you might want to have one login for a user that can be shared among all sites. Both options are possible in Q2A. The former means you'll have to setup different sites per domain (could be under the same database or not, which doesn't change performance at all) and the latter means you'll have many sites setup in the same database (which doesn't mean they will be using the same tables).

Expanding the idea of having shared users in the same database, this is achieved in a very simple way: you have to setup different sites that will all connect to the same database. Note each site will need to have a different posts table so each site will have to have their own table prefix so that they don't mix posts data between sites. However, the idea is to actually mix user data so, apart from changing the QA_MYSQL_TABLE_PREFIX it will be needed to change the QA_MYSQL_USERS_PREFIX. All sites will need to have the latter constant defined with the same value so that all sites access the same user data tables.

You're talking about advantages and disadvantages. However, I think the two approaches tackle so different issues that thinking if it is more or less performant should be beyond discussion, as there is only one option for each user management approach. Still, sharing the same users table will lock it more often. Depending on how big the sites are this might be an issue or not (I hardly believe someone here has a site that big for this to actually be noticed).

BTW, database size is something you shouldn't care at all. You should care more about row amount for each table. The more rows you have the more time you'll spend searching and the more time you will spend maintaining the index after modifying indexed data. Having all users from multiple sites in the same table will, of course, increase the amount of rows that it will store.

Right, that's what I meant in the first paragraph. In this case I believe you could have a separate Q2A site that would only handle the registrations so all sites would redirect the registration to that site and it should send back the user to the calling site. I'm not sure it is possible to do so without programming a bit (or making some DNS changes) because, at least, you'll have to block all access to the "user registration site" except for the registration and login sections.

I think my answer was considerably misunderstood :)

Based on your comment, it is not clear for you that different sites for different topics requires different posts tables so it is not possible to have one single Q2A instance.

This "Idea is to setup different subdomains which will be targeted for diff topics" somehow contradicts "if there are two sites then they may share QA on both". One Q2A instance means all questions will be shared among all sub-domains and you won't really have different sites (but rather categories at most). Many Q2A instances means each sub-domain will have their own set of questions and won't be accessed by other Q2A instances.

"I liked the option1" => There are no options. There are just very different scenarios (including the awkward external users scenario):

if you want separate questions per site then
    use many different Q2A instances
    if you want separate users per site then
        use different users table
    else (users are shared among sites)
        if you want a third party to handle your users then
            if you want Q2A to be that third party itself then
                use single sign on (external users feature) setting up a Q2A instance only used for registration (awkward scenario)
                use single sign on with whatever your third party user provider is (e.g.: WordPress)
        else (users are handled by Q2A)
            share the same users table (this is a simple approach!)
    use one Q2A instance and use categories

I'm going to claim a patent for that algorithm.

"I liked the option1 to have single db for user from main domain" => If by option one you mean having separate questions, sharing users among the different Q2A instances handled by Q2A itself then there is also no such a thing as a "main domain". You just have the sites. You could have a webpage as the domain root or a www. or whatever but that won't have anything to do with Q2A as you'll have Q2A instances per sub-domain.

"if user click on favorite questions on diff subdomain, hope it will populate diff sites his favorite questions in his account" => No, it won't there are different posts tables per instance. Each instance access there own post table. Favoriting a post requires knowing that post. An instance does not know the posts of another instance so each favorited question won't be visible among different sites.

"What if cloud db is setup" => Then the cloud DB will get locked more frequently :)

"what is the user count when I should start worrying about this?" => Will depend on your server (CPU, memory, bandwidth) and the usage you're expecting from the site. I definitely wouldn't worry about this unless you're planning to have a million views per hour. Although this is very subjective and depends on so many factors that you should give it a try and share your experience with the rest (note how very few people complain about performance and the ones that do are most likely in free/cheap hosting plans).

"if SSO is possible with Q2A then could you please provide solution here." => It's on the site: http://docs.question2answer.org/install/single-sign-on/

"Does it mean only users table will be accessed from diff server with no other tables in that db?" Yes and no. The most standard way of SSO would be to have a third party (different than Q2A) to handle the users. However, you could use Q2A as the third party itself, as I explained before.
@pupi1985, sorry for the confusion. I got it now. thanks again for patiently explaining all permutations. Looks like it is better to setup wordpress for users and then install diff instances of q2a on subdomains.

I liked your logical algorithm :) ....nice explanation.
@pupi I don't think you'd need a specific "registration-only" site. You can have one main Q2A site which serves as the user base for all the other sites, and that site can still have questions on it.
@Scott That's correct. The thing is that the instance will be different than the rest as the rest will be using external users while that one won't. Features supported by external users are less than the ones that don't. So that site will have actually more features than the rest (for example, favouriting users). I'd rather have all sites equal to ease administration and to avoid users wondering why they can favorite users in the Movies site and not in the Gardening site
+3 votes

Here is experiment I did for this.

  1. Installed first Q2A site as normal on main domain myq2asite.com (first instance of q2a), set below parameters as

define('QA_MYSQL_TABLE_PREFIX', 'qa_');
define('QA_MYSQL_USERS_PREFIX', 'qa_');

  1. Copied files for second Q2A site(subdomain movies.myq2asite.com). (second instance of q2a).
  2. Edited qa-config.php and set the users prefix option to "qa2" modified these two lines:
    define('QA_MYSQL_TABLE_PREFIX', 'qa2_');
    define('QA_MYSQL_USERS_PREFIX', 'qa_');
  3. Now run the installation on the second site.
  4. created normal user account on myq2asite.com
  5. Login to myq2asite.com as a normal user, it works fine.
  6. Went to movies.myq2asite.com but it is again asking for username and password. so sessions are not shared between two sites.
  7. same way, I login as a normal user to movies.myq2asite.com and it works fine, then went to myq2asite.com and it is asking for username and password.

any idea how to fix this session issue?

Remember you're following the approach where posts are split over many Q2A instances and each instance does not know about the posts of other instances. So points are in a per-site basis. You're just sharing users. If you want to have the points shared between different "topics" use a single Q2A instance with categories
@pupi1985, got it. Thank you! appreciate your help.
I recommend to read QA_BLOBS_DIRECTORY comment in qa-config.php carefully.

Note than if multiple Q2A sites are using QA_MYSQL_USERS_PREFIX to share users, they must also have the same value for QA_BLOBS_DIRECTORY. If there are already some BLOBs stored in the database from previous uploads, click the 'Move BLOBs to disk' button in the 'Stats' section of the admin panel to move them to disk.

Problem occurrence condition:
This issue occurs when you allow users to upload avatar.

Operation and phenomena:
Avatars uploaded on one site can not be accessed from other sites.

Avatar is stored in the database (or file system) of the uploaded site. Other sites try to show avatar from own databases (or file system).

1. Enable QA_BLOBS_DIRECTORY on all sites.
2. Unify the location of QA_BLOBS_DIRECTORY at all sites.

My advice.
@sama55 thank you. I will enable that and test sites again.