Sync shipping address

[dstrojny]

We have an option for collecting shipping address, but it doesn't sync with the WordPress user profile. We should consider adding it in.

[dstrojny]

I'm going to close this, because I think we could better solve this problem by providing a nice export of members in the Memberful dashboard.

[skl]

@dstrojny I don't suppose you'd still consider this? We'd like this to synchronise with WordPress as we have a WooCommerce shop which separately stores Billing/Shipping address and at the moment Memberful also stores a shipping address and obviously they're getting out of sync. Right now if we run the Memberful export, we don't see any of the WordPress shipping addresses.

[dstrojny]

Sure! We can definitely reconsider this.

[skl]

I have this working with a custom plugin and child theme for a WooCommerce site I work with. My approach was:

Memberful --> WordPress/WooCommerce

• Create WP webhook listener for order.purchased, member_signup and member_updated Memberful events
• Use Memberful_User_Mapping_Repository::find_user_member_is_mapped_to() method to lookup WordPress user account based on incoming Memberful ID in the webhook payload
• wp_update_user() for user_email, first_name and last_name WordPress fields
• update_user_meta() for shipping address and billing phone number fields (there's no meta key for shipping_phone, only billing_phone)

WordPress/WooCommerce --> Memberful

• Attach action hook to "woocommerce_after_save_address_validation" which is used to intercept the WooCommerce database update (after WooCommerce $_POST data validation)
• If $load_address is "billing" then POST the following GraphQL mutation query: { memberUpdate(id: $mfID, phoneNumber: "$phone") {member{id}} } to update the phone number of the user only (Memberful only has a single address entry)
• Else if $load_address is "shipping" then extend the above mutation query to include address.street, address.city etc
• Then, in both cases, sleep for 3 seconds to allow for webhook to fire and update the WP DB, and issue the following function calls to complete the user's form save (whilst not double-saving to the WP DB):

// Intercept database save by forcing a redirect to prevent further processing by WooCommerce,
// emulate normal behaviour so user is none the wiser.
wc_add_notice( __( 'Address changed successfully.', 'woocommerce' ) );
do_action( 'woocommerce_customer_save_address', $user_id, $load_address );
wp_safe_redirect( wc_get_endpoint_url( 'edit-address', '', wc_get_page_permalink( 'myaccount' ) ) );
exit;

I suppose you could take out the sleep and just return instead of the DB save intercept, which would hand over control back to the WooCommerce form processor. But there is a slight discrepancy as there are more WooCommerce meta fields than there are Memberful address fields (e.g. shipping_company, shipping_address_2).

The behaviour is transparent to the user (except it takes a few seconds longer to save the address) and doesn't require custom WooCommerce templates for the address editing pages.

The custom WooCommerce templates may be required in order to change the account-editing links to Memberful account links (which will bring up the Memberful Overlay automatically) e.g. sign in/out and password reset.

It should be noted that I initially tried the approach of adding a WordPress filter to the "update_user_metadata" hook but this quickly led to circular updates between the WordPress DB and the Webhook essentially calling each other.

One case the above hasn't been tested for is if the user edits their address on the checkout page during checkout. It's a start though.

[dstrojny]

Cool! Thanks for sharing the solution you have in place 👍

[skl]

After thinking this through I've swapped out sleep() for return so that WooCommerce can complete the DB update as normal. This way there's no delay for the user. However to keep the data consistent I had to add delete_user_meta() on the webhook listener to delete "shipping_address_2" and "shipping_company" WP meta fields as I just concatenate these into Memberful's address.street field in the mutation query.

Doing it this way makes the bi-direction sync asynchronous without any apparent slowdown (by also setting blocking => false on the wp_remote_post() calls to the Memberful API).