feat: limit subscription purchase for user with network membership

[leogermani]

Follow instructions at #122

[adekbadek]

Can't test successfully – the subscription is still purchasable on the node site. Tracing the code, I see that it relies on the newspack_network_membership_plans option being set on the node site. In my setup, this option is only added on the hub site.

[leogermani]

Can't test successfully – the subscription is still purchasable on the node site. Tracing the code, I see that it relies on the newspack_network_membership_plans option being set on the node site. In my setup, this option is only added on the hub site.

Maybe you tried to buy before the new plan was pulled to the Node?

I updated the testing instructions with more details to make sure the info about all Memberhip Plans are populated before you try to buy. It's basically what was tested on #124

[adekbadek]

Ah, I see. I misread the instructions for #124 and thought the newspack_network_membership_plans option is expected on the node site only.

After updating the membership plan on the node and synchronizing the events, the newspack_network_membership_plans option is present on both sites. But this is problematic, because it means a manual migration would be needed after these changes are deployed – the network-synced plans on all sites would have to be fake-updated to trigger the newspack_network_membership_plans events.

Can the migration (populating newspack_network_membership_plans option) be done automatically?

[adekbadek]

Note: handling of non-logged in users should also be added (with email-lookup), similar to Automattic/newspack-blocks#1816.

[leogermani]

After updating the membership plan on the node and synchronizing the events, the newspack_network_membership_plans option is present on both sites. But this is problematic, because it means a manual migration would be needed after these changes are deployed – the network-synced plans on all sites would have to be fake-updated to trigger the newspack_network_membership_plans events.

Yes, a backfill of membership plans and also all the woo data will be necessary. The backfillers added here should address them all. But yes, it is a step we'll need to go through.

Maybe we can work on that idea to have a central backfiller command, from the Hub, that will remotely reach each node.. this would save some steps.

But in any case, I'm happy to test and run it all

[leogermani]

@adekbadek here's an idea

We bring back 4acd965, leaving the current approach alive.

We cherry pick only the addition of the user meta from here

And then we merge and release.

Then we'll have the current implementation preserved, and we'll start to propagate the new events (but not really use them yet)

Then we have a full release cycle to run all the backfillers without any rush.

Then in the next release we merge the new functionalities that rely on these new events.

wdyt?

[adekbadek]

That seems pretty complicated. Alternatively, can a site trigger an update to newspack_network_membership_plans option if it's empty? This would ensure that it's always there. Even with the backfill, the option might be deleted later by accident.

[leogermani]

Closing in favor of #137