theinnographer

Hi there,

A quick follow up.

Upon further testing, I can confirm that the password sync between sites IS working just fine when the user updates their own password.

It seems both @donbeni and I were expecting it to happen when an admin updates a user’s password via their profile page.

So it seems that the plugin is doing exactly as it is designed to do, i.e. Fires “when a user resets their password. The expected result is the password being reset for the user on all registered remote sites accepting incoming Password actions.”

Is synching passwords upon profile updates something you would consider adding to the plugin Alexandre?

For our part, it was surprising that it doesn’t do this and leads to the user having multiple passwords when they / we don’t expect it.

Thanks again for the great plugin!

Alex.

Hi there,

I have this exact problem too. Fresh WordPress sites. All ping tests work great, including passwords. And yet the passwords don’t actually sync.

All other syncs work fine.

This used to work fine and I’m afraid I didn’t monitor this one closely enough to say when it stopped working.

Appreciate any help you can provide!

Alex.

One more thought, to support the request for adding the user and/or user role filters suggested above.

It’s quite possible to lock an administrator out of a remote site by mistake.

Sounds silly, I know. And sounds like something you have to be clumsy or stupid to do.

But consider the following example:

1. You set up role sync between sites with a role being synched, e.g. editor
2. You don’t setup to sync the administrator role between those sites, but you also don’t “merge with existing roles”
3. You add the editor role to an administrator

If that administrator also exists on any synched remote sites, then after the actions are fired they will only have role editor. And not the administrator role any longer!

This may be a fringe example and I know it’d be odd to add the editor role to administrator user, but something quite like this happened to us. And I believe we’ve been very careful and thoughtful.

I guess my points are that: 1) it might be better not to allow administrators to sync by default in any event; and 2) it’d be great to have the ability requested above to select which users / user roles are impacted – globally for all sync pairs, or on a case by case basis for each sync pair.

All that said, thank you again for this wonderful plugin Alexandre.

We really appreciate you providing it and hope our experiences and comments are helpful to you.

Sincerely,
Alex.

Hi there,

We’d really love to see this functionality added too. We only want the sync to happen for one user role.

Meanwhile, is this the right idea to implement what you’re suggesting above?

	add_action( 'wprus_before_firing_action', 'check_whether_user_sync_between_sites_should_proceed', 10, 2 );

	function check_whether_user_sync_between_sites_should_proceed( $endpoint, $url, $data ) {

		global $block_http_requests;

		$block_http_requests = true; 

		if( ... user role checks out ... ){

			$block_http_requests = false;
		
		}

		return;

	}

	add_filter( 'pre_http_request', 'short_circuit_http_request', 10, 3 );

	function short_circuit_http_request( $preempt, $parsed_args, $url ){
		
		global $block_http_requests;

		if ( ! $block_http_requests ) {

			return false; // i.e. Don't intervene so it can proceed as planned

		}

		// Otherwise, block the request:

		return new WP_Error( 'blocked', __( "HTTP request manually blocked due to disallowed user roles.", $this->plugin_name ) ); 

	}

	add_action( 'wprus_after_firing_action', 'reset_http_blocking_after_checking_whether_user_sync_between_sites_should_proceed', 10, 2 );

	function reset_http_blocking_after_checking_whether_user_sync_between_sites_should_proceed( $endpoint, $url, $data, $response ) {

		global $block_http_requests;

		$block_http_requests = false; 

	}

I ask because we’re getting an error when we update the user profile, so must have misunderstood something. … or it’s just too late at night as I write this 🙂

Would be grateful if you could let me know if anything jumps out at you.

Thank you!

Alex.

• This reply was modified 4 years, 6 months ago by theinnographer.
• This reply was modified 4 years, 6 months ago by theinnographer.
• This reply was modified 4 years, 6 months ago by theinnographer.

Thank you again @frogerme. Awesome.

And just to clarify for anyone else this might help. The site on the main domain wasn’t visible at www. before Cloudflare but was visible there after it. And the sync did work before Cloudflare, did not work with it, and did work again after it was deactivated.