feat(data-events): mailchimp connector

[miguelpeixe]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Implements the Mailchimp connector using Data Events, producing a result similar to what is achieved for ActiveCampaign with RAS.

Just like the AC implementation, this also requires a "master list", or a single audience, to send the data to. It will automatically fetch from the "Mailchimp for WooCommerce" plugin setting if it's not configured in the RAS setting mailchimp_audience_id.

The UI for configuring Mailchimp's master list should be built next, not in this PR.

The data transformation borrows the logic from WooCommerce_Connection, by moving the contact generation portion to a get_contact_from_order( $order ) method so it can be reused.

The same logic used for ActiveCampaign in Newspack\Newspack_Newsletters is not reproduced, meaning:

• No UTM integration
• NP_Product Name is removed. This value will change with every different purchase, it's not clear to me the purpose of treating it as a singular contact data. Perhaps we need a better strategy for this?

The contact is upserted as soon as registered, with status set to transactional if it's new (not yet subscribed), through a handler attached to the reader_registered action.

Purchase updates are sent through a handler at the donation_new action. The order data is transformed with WooCommerce_Connection::get_contact_from_order( $order );.

How to test the changes in this Pull Request:

1. Make sure you have the following constants:

define( 'NEWSPACK_AMP_PLUS_ENABLED', true );
define( 'NEWSPACK_EXPERIMENTAL_READER_ACTIVATION', true );
define( 'NEWSPACK_LOG_LEVEL', 2 );

2. Make sure you have Mailchimp connected and reader revenue configured with either Stripe or Newspack platform
3. Install the Mailchimp for WooCommerce plugin configure with the same account and set it to an audience (this is required only until we have our own UI for setting the master list)
4. Configure a Reader Registration prompt
5. In a fresh session, register a reader through the prompt without subscribing to newsletters
6. Wait until Executing action handlers for "reader_registered" is logged
7. Confirm the contact is created in Mailchimp with the status transactional and the following merge fields filled:
   1. NP_Account
   2. NP_Registration Page
   3. NP_Registration Method
8. Make a purchase and confirm the data from get_contact_from_order() is updated to the same contact
9. Through the "My Account" page subscribe to the newsletter and confirm the you're subscribed without any merge field data being altered/removed

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[miguelpeixe]

Requesting a review from @adekbadek because it uses a lot of his code on a different backend strategy to produce a similar result.

[leogermani]

I've tested everything just from a functional point of view, following the instructions, and everything worked just fine.

I also tested making a donation before registering and that did not sync (not sure it was expected to)

[miguelpeixe]

I also tested making a donation before registering and that did not sync (not sure it was expected to)

It will bail if a contact (registered user) is not available, but if a reader is created during (after) the donation is made we might need to tweak it on the WC integration side so that it becomes available at the hook.

[adekbadek]

Since @leogermani did functional testing, I've only looked at the code. The changes to class-woocommerce-connection.php look fine. Left one note about argument order – after this is fixed we're good to merge.

[adekbadek]

NP_Product Name is removed. This value will change with every different purchase, it's not clear to me the purpose of treating it as a singular contact data. Perhaps we need a better strategy for this?

This field (and a few others) are based on the assumption that a reader would buy a single product, which aligns with a membership-driven model. Newspack supports more models, but this specific integration was requested by a membership-focused third party.

[miguelpeixe]

This field (and a few others) are based on the assumption that a reader would buy a single product, which aligns with a membership-driven model.

In the interest of feature parity, 89e9566 implements the NP_Product Name support through the donation_subscription_new action, instead of every donation. In this case, every new recurring donation will trigger an update in MC's contact. WDYT?

It can be extended to also handle donation_subscription_cancelled, but I wonder about its use.

[miguelpeixe]

I also tested making a donation before registering and that did not sync (not sure it was expected to)

@leogermani I tried on both Stripe and Newspack platforms and an anonymous donation (fresh session) did sync without issues. Which platform were you using, can you provide more details?

[adekbadek]

NP_Product Name support through the donation_subscription_new action

Sounds good!

[matticbot]

🎉 This PR is included in version 1.103.0-alpha.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 1.104.0-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 1.105.0-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 1.105.0-hotfix-hpb-amp-optimisations.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 1.105.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀