-
Notifications
You must be signed in to change notification settings - Fork 215
[DO NOT MERGE] Removing legacy payment method classes #4787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Are we planning to do a similar cleanup for the frontend code (to remove is_upe_enabled distinction) in a separate PR?
daledupreez
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some initial comments from inspection, and I will move to test this later this morning. That said, it feels like it might be worth splitting this PR up a bit so we can tackle more specific and focused testing.
| * @var string | ||
| */ | ||
| private $legacy_sepa_gateway_id = WC_Gateway_Stripe_Sepa::ID; | ||
| private $legacy_sepa_gateway_id = 'stripe_sepa'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might it be worth using a new constant for this rather than having 'stripe_sepa' everywhere?
It also feels like it could be worth pushing just that change into a dedicated PR, as that would be easy to inspect and review, and we could get it shipped with minimal risk. That would also reduce the size of this PR by quite a few files.
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
@malithsen yes. I have some other branches to push related to code cleaning up. I will open other PRs in the next couple of weeks
@daledupreez I tried to make this PR focused on just removing the payment method classes, to avoid it getting too big or risky. Which parts do you think would be better to move to another PR? |
|
For splitting the PR, I was thinking it might make sense to change the references to |
|
Oh right. I created the other PR here: #4802 |
daledupreez
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I would love to remove all of this code, I am really worried about unforeseen consequences of removing so much code without looking deeply into some of the nuances of what we're changing and/or removing.
| } | ||
|
|
||
| // Bail if no Stripe payment method is enabled. | ||
| if ( 'no' === $this->enabled && empty( WC_Stripe_Helper::get_legacy_enabled_payment_methods() ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: should we be queuing these scripts for any pages when UPE is enabled?
| * @deprecated 9.6.0 The customization of individual payment methods is now deprecated. | ||
| * @deprecated 10.2.0 This method will be removed in future versions. | ||
| */ | ||
| public static function get_legacy_individual_payment_method_settings() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: It feels like it would be worth splitting this out into a dedicated PR so we can correctly capture the removal in a changelog entry. I almost missed that these two functions had been removed.
| * | ||
| * @since 4.0.0 | ||
| */ | ||
| class WC_Gateway_Stripe_Alipay extends WC_Stripe_Payment_Gateway { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These classes were not marked as deprecated. Just to be good citizens, I think we should deprecate them before removing them, as merchants may be referencing them in custom code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. New PR is here #4839
|
|
||
| const STRIPE_ID = WC_Stripe_Payment_Methods::ALIPAY; | ||
|
|
||
| const LPM_GATEWAY_CLASS = WC_Gateway_Stripe_Alipay::class; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As with the class removals, I think we should deprecate these constants first, as they are public and could be in use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. New PR here #4838
| protected function enable_upe( $settings ) { | ||
| $settings['upe_checkout_experience_accepted_payments'] = []; | ||
|
|
||
| $payment_gateways = WC_Stripe_Helper::get_legacy_payment_methods(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we safely remove this logic? What will happen to merchants upgrading from older versions where UPE was not enabled yet?
| ]; | ||
| } | ||
|
|
||
| public function test_turning_on_upe_enables_the_correct_upe_methods_based_on_which_legacy_payment_methods_were_enabled() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we still need the underlying logic for upgrades?
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Changes proposed in this Pull Request:
In this simple cleanup PR, I am removing all the legacy checkout payment method classes, as we are no longer using them.
Testing instructions
Code review. Check if the tests are still passing. Perform some basic smoke testing and confirm no regression was introduced.
Changelog entry
Changelog Entry Comment
Comment
Post merge