November 30, 2023

WP Remote Users Sync Plugin

Synchronise WordPress Users across Multiple Sites.

If you run multiple websites and want to keep users separated, but synchronise them automatically and securely for specific user operations, then WP Remote Users Sync is the plugin to use.

Overview

This plugin adds the following major features to WordPress:

WP Remote Users Sync admin page: a settings page under “Settings > WP Remote Users Sync” to manage remote sites, security settings, import/export users, and view activity logs.
Remote Sites: manage an unlimited amount of connected sites with configuration for incoming and outgoing User Actions (Login, Logout, Create, Update, Delete, Password, Role and Metadata).
Security: WP Remote Users Sync is the only plugin available allowing users to be synchronised with true layers of security in place. All communications are OpenSSL AES-256-CBC encrypted, HMAC SHA256 signed, token-validated and IP-validated.
Import and Export Users: connected websites’ existing user base can be synchronised manually first thanks to the provided import/export tool.
Activity Logs: when enabled, all communications between connected sites are logged for admin review and troubleshooting.
Synchronise all user data: compatible out of the box with WooCommerce, Ultimate Membership, Theme My Login, Gravity Forms, and all user-related plugins as long as they rely on WordPress user metadata and manipulate users with the WordPress user functions.
Customizable: developers can add their own User Actions using action and filter hooks, and more – see the developers documentation.
Unlimited websites, unlimited features: there are no restrictions in the number of websites to connect together, and no premium version feature restrictions shenanigans – WP Remote Users Sync is fully-featured right out of the box.

Troubleshooting

Please read the plugin FAQ, there is a lot that may help you there!

WP Remote Users Sync is regularly updated for compatibility, and bug reports are welcome, preferably on Github. Pull Requests from developers following the WordPress Coding Standards (WordPress-Extra ruleset) are highly appreciated and will be credited upon merge.

In case the plugin has not been updated for a while, no panic: it simply means the compatibility flag has not been changed, and it very likely remains compatible with the latest version of WordPress. This is because it was designed with long-term compatibility in mind from the ground up.

Each bug report will be addressed in a timely manner if properly documented – previously unanswered general inquiries and issues reported on the WordPress forum may take significantly longer to receive a response (if any).

Only issues occurring with included plugin features mentioned in “Synchronise all user data”, core WordPress and default WordPress themes (incl. WooCommerce Storefront) will be considered.

Troubleshooting involving 3rd-party plugins or themes will not be addressed on the WordPress support forum.

Integrations

Although WP Remote Users Sync works out of the box with most combinations of WordPress plugins and themes, there are some edge cases necessitating integration, with code included in the core files of WP Remote Users Sync executing under certain conditions.

Integrations added to core are limited to popular plugins and themes: any extra code specific to a handful of installations require a separate custom plugin not shared with the community (created and maintained by a third-party developer).

A typical example necessitating custom integration includes plugins or themes relying on their own custom tables, directly updating the database with SQL queries instead of using WordPress built-in functions, destroying sessions with low-level functions instead of using the built-in WordPress method, etc.

If such need for plugin integration arises, website administrators MUST contact a third-party developer. The plugin author currently does not have the bandwidth to take on custom work for WPRUS.

Installation

This section describes how to install the plugin and get it working.

Upload the plugin files to the /wp-content/plugins/wprus directory, or install the plugin through the WordPress plugins screen directly for all websites to connect together
Activate the plugin through the ‘Plugins’ screen in WordPress on all websites to connect together
Edit plugin settings on each site – follow on-screen help if necessary

Screenshots

Remote Sites tab upon installation
Remote Sites tab with remote sites collapsed
Remote Sites tab with a remote site actions settings opened
Security tab - token, encryption, signature and IP settings
User Import/Export tab
Activity Logs tabs with example of communication activity to and from a remote site
Help tab

FAQ

How does it work?

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.

It’s not working!

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.

In Safari and iOS browsers, why do I see a “Processing…” message on Login, and why are users logged out everywhere on Logout?

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.

What happens to existing users after activating WP Remote Users Sync?

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, WP Remote Users Sync provides its own user import/export tool.

What security measures are in place?

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.

What is the impact on performances?

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.

How are user roles handled when a user is synchronised?

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

What about extra user information? (WooCommerce / Ultimate Member / other plugin adding user information)

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.

What about user passwords?

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.

What if the user to synchronise does not exist on the remote site?

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.

Can it be tested on localhost first?

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.

How to export users from this site and import them into a remote site?

WP Remote Users Sync provides its own user import/export tool.
With it, administrators can:

Export all users
Export users with specified roles
Export users with or without their roles
Export users with or without specified metadata
Export batches of users – for example, to export 500 users at a time, Max # is set to 500 and Offset to 0, 500, 1,000, 1,500, 2,000… and the export operation is repeated until there are no more users to export.
Import users into the remote site using the file(s) previously exported

Once downloaded, the files are automatically deleted. In case some files were not downloaded and remained on the server, the containing directory is also cleaned daily.
Exported files are not directly accessible by URL: only administrators can access them.
User passwords cannot be and are NOT exported.

Where to find more help?

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).

Changelog

2.0.3

Password handling third-party compatibility improvements – leverage per-request cache (non-persistent)

2.0.2

Better password handling (update, reset)
Make explicit which standards are ignored
Minor cleanup

2.0.1

Bugfix – Issue #76 thanks to @intlCEA on Github
Minor cleanup
WordPress tested up to: 6.4.1

2.0

Removed all wprus_template_* hooks ; added wprus_get_admin_template_name, wprus_get_admin_template_args, wprus_get_template_name, wprus_get_template_args, wprus_locate_template, wprus_locate_template_paths and wprus_locate_admin_template instead.
Added Multisite support
Code cleanup
Remote site URL check does not check the protocol anymore for convenience
Attempt at solving ‘); document.close(); issue on Safari browser – use of backticks, better error handling in browser console
Minor fixes – cron
Documentation update

1.2.14

Minor fixes with true nonces
WordPress tested up to: 6.4

1.2.13

Use wp_safe_remote_post instead of wp_remote_post

1.2.12

WordPress tested up to: 6.3
Optimise settings page – thx to @foloed on Github
Update variable filter IDs – php 8.x compat
Ping & log refresh ajax check – thx to István Márton from Wordfence
Drop paid custom code support from readme.txt
Refactor integration class & documentation
Minor fixes

1.2.11

Make sure the HTTP_USER_AGENT is set before testing it

1.2.9

WordPress tested up to: 5.8
Add support for IP range (CIDR) – thx to @honggyu420 on Github

1.2.8

WordPress tested up to: 5.8
Fix conflicts – change 'wp-includes/pluggable.php' load order

1.2.7

Fix settings cache issues – for real…
Fix log output
Fix permalinks patterns
Add wprus_fire_action_timeout filter hook
Login Action: optimise compatibility with third-pary plugins and themes
Delete Action: fix log output
Add silent redirection for async actions, with opt-in in Miscellaneous settings tab
IMPORTANT – DEVELOPERS: Replace all instances of remote_async_action with async_action, affecting method names ; action and filter hooks not affected, classes inheriting Wprus_Api_Abstract need refactor.
Refactor fire_async_actions method of Wprus_Api_Abstract (formerly fire_remote_async_actions)
Add wprus_action_data filter hook
Update documentation

1.2.6

Fix Object Cache compatibility
Optimize compatibility with Safari and iOS devices: use 303 redirects when reaching the login endpoint
Optimize compatibility with Safari and iOS devices: better logout
Refactor asynchroneous User Actions firing
Remove outdated Query Monitor integration
Remove wait.css, wait.min.css, wait.js, wait.min.js, wprus-wait.php
Add wprus-async-processing.php and wprus-async-processing-script.php
Update documentation

1.2.5

Add compatibility with Safari and iOS devices: do not rely on cross-domain third-party cookies manipulation, but use explicit redirections for Login, and destroy all sessions for Logout
Add template for explicit redirection processing screen
Add Miscellaneous settings with a section for Browser Support
Query Monitor integration
Update documentation

1.2.4

Fix “SameSite” cookie attribute when doing cross-site login
Fix settings cache issues
Minor refactor of Wprus_Api_Abstract

1.2.3

Include logger class earlier
Fix save button text
Fix duplicate “Settings save.” notice
Minor UI fixes

1.2.2

Move settings page under “Settings > WP Remote Users Sync”
Add link to settings on installed plugins page
Add $key parameter to wprus_option filter
Change template name from main-setting-page.php to main-settings-page.php
Fix minified scripts inclusion
Removed unused URL parameter from the API
Fix flushing of rewrite rules
Set priority of all init action hooks to PHP_INT_MIN - 10 to maximize compatibility with third-party plugins
Refactor integrations
Remove wprus_integration filter ; add wprus_integration action instead.
Add wprus_init action.
Update FAQ and help
WordPress Tested up to: 5.5

1.2.1

Even more verbose log in case of communication error
Fix minor typos
Update help page
Update readme.txt
WordPress Tested up to: 5.4.2

1.2

Trigger Update action on role add, set, and remove instead of only user update
Add wprus_before_init_notification_hooks and wprus_after_init_notification_hooks action hooks
Fix Delete action log message
Fix Wprus_Crypto class inclusion (no direct access)
Add integration logic ; future additions to integrations made upon donation
Add integration – WooCommerce ; login on remote sites as well when creating an account at checkout time (depending on User Actions settings). Many thanks to the generous patron who decided to remain anonymous.
Add wprus_integration filter
Data is encoded with JSON_UNESCAPED_UNICODE flag to support a wider range of characters (Chinese, Greek, etc)
Better error message handling in case of syntax error in payload
Full documentation of the Wprus_Api_Abstract class for developers of custom User Actions
Update documentation

1.1.12

Add wprus_is_authorized_remote filter

1.1.11

WordPress tested up to: 5.4.1
Update FAQ

1.1.10

Add full Chinese translation (Thank you @倡萌 from https://www.wpdaxue.com/)

1.1.9

Adjust hook calls

1.1.8

Adjust language domain path to take into account plugins/wp-remote-users-sync/languages

1.1.7

Fix: make all interface strings translatable (hopefully for real)

1.1.6

Fix: make all interface strings translatable
Fix: various language domains issues
Adjust log messages

1.1.5

Integration – make sure third-party plugins calling wp_redirect() or wp_safe_redirect() without calling exit afterwards do not interfere with asynchronous actions ; exit should be called after these 2 functions unless there is a documented good reason not to, but some plugins (like Gravity Forms User Registration Add-On) or themes may not follow the WordPress best practices.
Add missing Logout action logs
Update Async actions logs
Refactor resetting Async actions

1.1.4

Bugfix – do not save the token for async actions: these tokens are invalidated immediately after use (nonce) and saving them triggers an Unauthorized access (invalid token) error for subsequent sync actions.

1.1.3

Integration – rely on get_option( 'home' ) instead of home_url to get the homepage URL to avoid conflicts with plugins (in particular translation plugins) and themes filtering the value.
Order meta by meta_key
WordPress Tested up to: 5.4

1.1.2

IP whitelist: sanitize the option by trimming each line of whitespaces (improve configuration error tolerance)
Refactor IP check

1.1.1

Fix metabox compatibility on plugin main settings page
Fix minor warning and cosmetic issues
Improve log entries and alert error messages

1.1

Fix plugin settings link in admin notice (for real -_-‘)
Fallback to single-use token (true nonce) instead of IP address validation for asynchronous actions (login & logout by default): REMOTE_ADDR from the client cannot be trusted to match if the websites to link are on 2 different networks, but a single-use token is as secure as it gets, with a slight performance trade off ; REMOTE_ADDR validation is kept for synchronous actions
Add missing Logout success log trace
Update documentation

1.0.3

Fix plugin settings link in admin notice

1.0.2

Fix css lib path

1.0.1

Make sure all options are deleted upon plugin uninstall
Adjust template names
Minor fixes and refactor
Add 14 action and 16 filter hooks
Add developers documentation

1.0

First version