Closed mmtr closed 1 year ago
cc @artpi in case he has any advice
Ok, this is weird. I cannot longer reproduce this, so I guess I was a problem on my sandbox (maybe I wasn't sandboxing everything correctly).
Reopening this since @blackjackkent started experiencing it too. To be honest, all the code I investigated seems correct, so I think the issue is only happening when there is some sandbox misconfiguration and likely is not going to affect final users.
But if we want to avoid this, one way is by completely removing the plan IDs from the Donations block attributes. Given that plans are automatically set/created without the user noticing it, we can actually do that as part or the dynamic block rendering.
That would mean that plan IDs won't be fetched as part of the block edit logic, instead we can fetch them during execution time as part of the dynamic block rendering (render callbacks are executed when visiting a post that contains the block).
Since that logic runs in the server, we should be able to check the account_disconnected
flag and if for any reason the flag exists but the Stripe connection is set, we can recreate the plans with the new Stripe account, making sure that the returned plans will work in the payment dialog.
I just had a customer report this in 25987821-hc
I encountered this same error message with the Premium Content block in 25938511-hc
They mentioned it was the first time they were connecting, however previously used the same Stripe account with Medium.
Got another in 26008195-hc
Another - 26008195-hc
Observed in a case where user first registered on WooCommerce Payments (that apparently creates a Stripe Express account), and then used the same credentials for Premium content block.
3519340-zd
@mmtr Is it possible to fix this for individual customers while we're waiting for the bug itself to be fixed? I don't understand the bit about deleting the old plan. What sort of plan? How does the user do this? I asked in #payments: p1607361090429500-slack-C02BEP610
@mmtr Is it possible to fix this for individual customers while we're waiting for the bug itself to be fixed? I don't understand the bit about deleting the old plan. What sort of plan? How does the user do this? I asked in #payments: p1607361090429500-slack-C02BEP610
They have to create a new payment plan in wordpress.com/earn/payments-plans/:site
(Tools > Earn > Manage payments > Collect payments > Manage plans > Payment plans): https://wordpress.com/support/wordpress-editor/blocks/payments/#managing-payment-plans
Once the plan has been created, they have to switch any existing Payments / Premium content block to the new plan by editing the posts containing such blocks: https://wordpress.com/support/wordpress-editor/blocks/payments/#payment-block-settings
Another one - 26398923-hc The user created a new plan and added it again to the payment block. But they are still seeing the same issue.
3593671-zen
Another report in 26335896-hc, suggested deleting plan and re-adding as a workaround.
Another report in 23452958-hc, the new plan workaround did not work for them.
Another report in 3698959-zd, with the Donation block
Another report for the Payments Block: 18504186-zen
Another report: 27662821-hc
Re-created the plan didn't do the trick. I'm going to do the workaround @yashitamittal11 provided on their follow-up: Creating a new Stripe account.
Another report for Payments block in 27711962-hc
Another report for Payments block in 17465695-hc I'll ask them to make a new payment option.
Another report for Payments block in 28150296-hc
With Donations block 21506261-hc
Another case with the donations block here: 3791649-zen
Another 3782418-zen with the Donations Block.
@mmtr @artpi are there any expectations that this will be fixed for the Donations block? Since it seems to be so easy to trigger this, it makes the block very fragile.
are there any expectations that this will be fixed for the Donations block?
No.
Neither me nor @mmtr are no longer able to work on this. My best suggestion is to post on autopay and maybe the payments teams have some capacity. They are the ones handling the backend for it now
Another one 28308521-HC Deleting the plan and re-adding a new plan fixed the issue for them.
are there any expectations that this will be fixed for the Donations block?
No.
Neither me nor @mmtr are no longer able to work on this. My best suggestion is to post on autopay and maybe the payments teams have some capacity. They are the ones handling the backend for it now
created autopay post here: pNPgK-5mN-p2
This can be worked around for the Payments and Premium Content blocks, since a user can delete the old plan and create a new one that won't have the account_disconnected flag. But for the Donations block this is rather problematic, since a user cannot manage donation-type plans, so Donations blocks published after the reconnection won't work either.
@mmtr: for the donations block, can the user delete the current block and then create a new one? Will a new plan be provisioned in the background, or does it check for the old donations plan again?
@mmtr: for the donations block, can the user delete the current block and then create a new one? Will a new plan be provisioned in the background, or does it check for the old donations plan again?
Unless this has changed since I worked on it, it'll get the previous generated plan. See https://github.com/Automattic/jetpack/blob/master/projects/plugins/jetpack/extensions/blocks/donations/fetch-default-products.js and the Memberships_Product::generate_default_products
method in the WP.com codebase (wp-content/lib/memberships/class.membership-product.php
).
Another case here: #3819056-zen
Another report: 27172626-hc
Another report in 16931649-hc
They moved the site to WordPress.com, from a self-hosted site, and donations block now show an error
We could not find this payment plan on ... site.
I started looking into the Donations block issue yesterday. A lot of this revolves around the backend, so I created Automattic/payments-shilling#243 to track the issue.
There is a manual workaround for Simple and Atomic sites that requires a sandbox that I'll leave here until a better fix is made. If any of the issues above are still valid, we could look into doing the following:
/wpcom/v2/sites/{site}/memberships/products
endpoint for plans type:donation
wp post delete {ID} --url={simple site address} --force
@kavyagokul: I've used the process above to delete the user's old donations plans. If they have a connected Stripe account, they should be able to follow the final step to re-add the donations block. Can you follow-up with them and let me know if they run into an issue?
@galakhyati @liviopv: I've used the process above to delete the user's old donations plans. They don't seem to have a connected Stripe account, but if they connect a new one, they should be able to follow the final step to re-add the donations block. Can you follow-up with them and let me know if they run into an issue?
@Nic-Sevic: I've used the process above to delete the user's old donations plans. If they have a connected Stripe account, they should be able to follow the final step to re-add the donations block. Can you follow-up with them and let me know if they run into an issue?
Followed up with user in this case and pending result: 3791649-zen
Followed up as per workaround in 3872470-zen
Following up with workaround #3916247-zen
Re-created the plan didn't do the trick. I'm going to do the workaround @yashitamittal11 provided on their follow-up: Creating a new Stripe account.
It didn't work on #3916247-zen too. Asked them to create new account too when they connected back on #29073845-hc
Hi @michaeldcain
Thanks for the workaround you mentioned above. Can you please do the same for this user?
3906702-zd-woothemes
Another one- #3918459-zen
Another one #29175192-hc
Another report #29186380-hc - I got the user to connect to a fresh Stripe account and this solved the issue in this instance.
@michaeldcain We have more reports above. Is there another workaround we could follow to take care of this in the meantime? Thank you!
Another report: 3943995-zd-woothemes
I asked the user to create new payment plan and create new Stripe account (it was a ticket so I provided them both options.)
Another report here for the Donations Block on an AT site: 29312878-hc Follow-up ticket: 3949561-zd-woothemes
@michaeldcain, any chance you could whack this one with your hammer as well? Thanks in advance.
Another report at 3943590-zd-woothemes It's for a simple site. I asked the user to create new payment plan and create new Stripe account, like in earlier reports. Pending result.
Hi @michaeldcain ,
Folllowing up on this comment, pending from 4 days ago.
Another report in #12603179-hc Follow up ticket: #3970578-zen
Follow up: #3972370-zen
When a user disconnects their Stripe account in
wordpress.com/earn/payments
, all plans are invalidated by setting a'account_disconnected' => true
flag in all of them (seeA8C\Billingdaddy\Api\Connected_Accounts::disconnect_connected_account
in the WP.com codebase).That ensures that any existing Earn block (Payments, Premium Content, Donations) don't go through the checkout process if a user tries to submit a payment. Instead we display a "Sales disabled" notice:
However, if that user decides to reconnect their Stripe account, the
account_disconnected
flag is not removed from the plans, so all Earn blocks previously published continue displaying the "Sales disabled" notice.This can be worked around for the Payments and Premium Content blocks, since a user can delete the old plan and create a new one that won't have the
account_disconnected
flag. But for the Donations block this is rather problematic, since a user cannot manage donation-type plans, so Donations blocks published after the reconnection won't work either.