Recently a customer decided to move his installation of Awesome Support to another instance of WordPress but wanted to make sure that customers could still log into both sites without having to re-register.  Here, in their own words is how they did it.

1. Create a new site that uses the old site’s users tables

1.1 Install the new site (Site B)

Install the new site using the SQL connection details from the existing site (Site A).  This ensures that the new site tables and the old site tables are in the same database, making the data easier to share among the two sites.  However, for the new site you must ensure you’re using a different table prefix. In this guide, we’ll use support_
During installation, you can create a new admin user for the new site.

1.2 Update Site B’s wp-config.php

Open the wp-config.php for Site B and add The following lines. You should replace wp_ with the table prefix used on Site A.

define('CUSTOM_USER_TABLE', 'wp_users');
define('CUSTOM_USER_META_TABLE', 'wp_usermeta');

On Site A’s wp-config.php locate the following lines and copy them on the wp-config.php of Site B, replacing what’s already there.
Note that both Site A and Site B will have hashes (different) where XXXX is shown below. You need to ensure that both sites have the same hashes.

define('AUTH_KEY', 'XXXX');
define('SECURE_AUTH_KEY', 'XXXX');
define('LOGGED_IN_KEY', 'XXXX');
define('NONCE_KEY', 'XXXX');
define('AUTH_SALT', 'XXXX');
define('SECURE_AUTH_SALT', 'XXXX');
define('LOGGED_IN_SALT', 'XXXX');
define('NONCE_SALT', 'XXXX');

Once this code block is saved on the file, the site will use the old tables to grant access.  All of the users on SITE A will not have access to SITE B.

2 Setting permissions

Each site has its own permissions. Those can be different form the other site and each user needs to have its permissions explicitly set on the usermeta table. This can be done programmatically or using admin

2.1 Set permissions programatically.

• You need to do this at least once, to give the main administrator access on the new site.
• Each user needs to have a record the usermeta table with meta_key “xxxx_capabilities” where xxxx is the prefix of the site.
• For our example, the users should have a record with meta_key “wp_capabilities” that will grant them access to Site A and another record with meta_key “support_capabilities” to gain access to Site B.
• To give access to an administrator on site B, you need to add a new record with meta_key “support_capabilities”. This can be done using the following query. Please replace XXXX with the ID of the adminstrator who should gain access:

  INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (XXXX, "support_capabilities", "a:1:{s:13:"administrator";b:1;}")
  

2.2 Set permissions using admin

You can navigate to the user details page of the user you’d like to change its role and update the role on the “Role” drop-down.  Please note that the roles you set on each site will not propagate on any other sites, so a user can be an Administrator on one site and a simple user on another.

3. Allow users to remain logged-in across both sites

This is only possible if both sites are subdomains of the same domain for example Site A could be www.domain.com and Site B could be support.domain.com.
To achieve this, you need to add the following code on the wp-config.php for both Site A and Site B.

define('COOKIEHASH', md5('domain.com') );
define('COOKIE_DOMAIN', 'domain.com');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');

The above code instructs the brower to store the cookies at the top domain (www is a subdomain).
Please note, you shouldn’t include a dot before domain.com. If you had .domain.com you’d probably run into issues.
You shouldn’t include any subfolders after the domain, so domain.com/folder would probably cause issues.

4. Allow user access to Awesome Support without adding support_capabilities for each one

As we explained before, each user needs to have a capability for the specific site in order to gain access. This can be problematic if you already have a large number of users, as you’d have to write a new record on wp_usermeta for each user.

4.1 Solution 1

You could achieve by creating a script that will add a support_capabilities record for each user currently on the database. You’d then need to keep this in sync and each time a new user registers on Site A, you somehow give them access to Site B.

4.2 Solution 2

If you’d rather not worry about keeping the permissions in sync, you can grant access to any logged-in user to create tickets and view their own tickets. To do this, you can place the following filter inside your theme’s functions.php:

// Allow all users to have the specified capabilities.
add_filter( 'user_has_cap', 'wpas_allow_all_to_create_ticket', 10, 3 );
function wpas_allow_all_to_create_ticket( $allcaps, $cap, $args ) {

// Create an array to set the capabilities ALL users should have
$allowedCapabilities = array (
'attach_files',
'close_ticket',
'create_ticket',
'reply_ticket',
'view_ticket',
'read'
);

// Loop through the must-have capabilities
foreach ($allowedCapabilities as $capability) {
// Check if we're asking about a must-have capability
if ( $capability == $args[0] ) {
// Add the missing capability
$allcaps[$cap[0]] = true;
}
}

return $allcaps;
}