WP Remote Users Sync

WP Remote Users Sync “listens” to changes related to WordPress users, and fires outgoing “actions” to registered remote sites. The registered remote sites with WP Remote Users Sync installed then catch incoming actions and react accordingly. There is no “Master Website”: each site is working independently, firing and receiving actions depending on each site’s configuration.

Before opening a new issue on Github or contacting the author, please check the following:

• The URLs used in settings of WP Remote Users Sync exactly match the URL in your WordPress settings: the protocol ( https vs. https ) and the subdomain (www vs. non-www) must be the same across the board. It is also worth checking the home option in the wp_options table of the WordPress databases, because in some cases the content of Settings > General > WordPress Address (URL) gets abusively overwritten by plugins or themes.
• Visit the permalinks page of each connected site (Settings > Permalinks)
• Activate and check the logs on both local and remote sites when testing (WP Remote Users Sync > Activity Logs > Enable Logs) ; try to find any discrepancies and adjust the settings
• Make sure the feature you have issue with is NOT triggered by a third-party package (plugin or theme). If it is (for instance, data is not synced when updating a user from the front end, but works fine in the admin area), please contact the developer of the third-party package and ask them to follow best practices by triggering the appropriate actions like WordPress core does in the admin area when a user is updated.
• Read the Resolved threads of the support forum – your issue might have already been addressed there

Only then should you open a support thread, with as much information as possible, including logs (with critical information obfuscated if necessary). Also please note this plugin is provided for free to the community and being maintained during the author’s free time: unless there is a prior arrangement with deadlines and financial compensation, the author will work on it at their own discretion. Insisting to contact the author multiple times via multiple channels in a short amount of time will simply result in the response being delayed further or even completely ignored.

Because these browsers prevent cross-domain third-party cookie manipulation by default, explicit redirections to log in users and destroying all the user sessions when logging out are necessary. With this method, only first-party cookies are manipulated. This is akin to logging in Youtube with a Google account.

Please note that the Login User Action takes a significantly longer time to process when using explicit redirections, particularly if many remote sites are connected.

Login and Logout User Actions need to output some code in the browser to have an effect on the remote website because of the cookies used for authentication.

What this means in practice is that if your theme or a third-party plugin allows users to login/logout without page reload, WP Remote Users Sync cannot output its code on the page, and without extra change to your website code base, the synchronisation can only happen after the page where the user logged in or logged out is actually reloaded.

Please also note that unless “Force Login Redirects & Logout Everywhere” is active, or if “Force Disable Login Redirects & Logout Everywhere” options is active in the “Browser Support” section of the “Miscellaneous” tab, Login and Logout User Actions will not work in browsers preventing cross-domain third-party cookie manipulation when the connected websites are on different domains.

Existing users remain untouched, until an enabled incoming action is received from a remote site. Users existing on one site and not the other will not be synchronised unless the user is actually updated AND both Create and Update actions are enabled on the site where the user does not exist. For existing user databases in need of immediate synchronisation, administrators should use a third-party user import and export tool to transfer users between sites.

WP Remote Users Sync is designed for mutually trusted WordPress installations. All connected sites share the same encryption and signature credentials, establishing trust across the group rather than identifying individual sites independently.

Per-site action settings control synchronization behavior, not access permissions. All connected sites must therefore be equally trusted.

Multiple layers of security are in place to protect the privacy, integrity and authenticity of communications between connected sites:

• OpenSSL encryption – All communications are encrypted using the AES-256-CBC algorithm with a randomly generated Initialisation Vector to ensure their confidentiality
• HMAC signature – All communications are signed with a hash using the SHA256 algorithm to ensure their integrity
• Authentication tokens – All communications rely on an authentication token valid only for a limited period of time, and asynchronous actions (Login & Logout by default) use a single-use token (true nonce).
• IP verification – IP addresses are verified using the REMOTE_ADDR server environment variable, which cannot be faked (unless the servers or the network infrastructure are already highly compromised, in which case there are bigger issues to worry about).

Despite these strong security measures, administrators use this plugin at their own risk ; the author will not be held liable for any damages resulting from the use of WP Remote Users Sync.

WP Remote Users Sync needs to communicate with the remote sites to actually synchronise users. This means the impact on performances depends on the response time between the connected websites.

Performance degradations are mitigated by the fact that Action Tokens (blocking request) are saved for a period of time, and by the fact that actions are fired ONLY when an operation has been performed on users (not on every page load). Asynchronous actions (Login & Logout by default) are the most costly: the operations themselves are not blocking, but their Action Tokens have to be renewed beforehand each time: true nonces, single-use tokens, are necessary for security reasons when firing actions from the browser. Asynchronous actions are also potentially more susceptible to failure in case of network issues, such as if the page load is interrupted or the enqueued script call failed in the browser ; this is a necessary trade-off as these actions require authentication cookie manipulations. Overall, performances should be marginally impacted.

The main takeaway is this:

• The more websites are connected, the bigger the relatively negative impact on performances.
• The worse the connection between the remote sites is, the bigger the relatively negative impact on performances.

Roles can be synchronised when the Create and Update actions are fired, with the Role action enabled, and matching transferred and accepted role settings.

Extra user information can be synchronised too out of the box as long as they are stored in the user metadata. For example, it means all the address and profile information in WooCommerce can be synchronised, but not the orders status or subscription status.

Passwords are automatically synchronised as long as the Password action is enabled (outgoing and incoming respectively). Communications are encrypted, signed, token-validated and IP-validated to make the process as secure as possible. Passwords are NEVER communicated or stored in plain text. WP Remote User Sync integrates with any plugin updating passwords provided they do so respecting WordPress standards.

If the incoming Create action is enabled along with the incoming Update action, the user will be synchronised on the remote website upon user update. If other actions for this user are fired before that (Login, Logout, Delete, Password, Metadata), nothing will happen, and an action failure log entry will be recorded if the “Enable Logs” box is checked.

Yes – as long as the websites can reach each other, WP Remote User Sync will work. This means that two websites in localhost (behind virtual hosts, for example) can communicate. However, if one of the websites is on localhost and the other is not, token exchange cannot happen and the websites will not be able to communicate.

More help can be found on the WordPress support forum for general inquiries and on Github for advanced troubleshooting.

Help is provided for previously unanswered general enquiries and bug fixes only: feature requests, extra integration or conflict resolution with third-party themes or plugins, and specific setup troubleshooting requests will not be addressed (Website administrators must contact a third-party developer).