isReusable() method called on wrong class

Created on 20 September 2024, 7 months ago

Problem/Motivation

StripePaymentElement.php calls a method isReusable() a number of times on \Drupal\commerce_payment\Plugin\Commerce\PaymentMethodType\CreditCard, but that method is not defined in the PaymentMethodType hierarchy, it's defined in \Drupal\commerce_payment\Entity\PaymentMethodInterface. CreditCard is not an instance of PaymentMethodInterface and does not have the method defined.

Steps to reproduce

unclear - we found this error in the logs. But if you look in the code, it repeatedly calls the method on the payment method type and not on the payment method.

Proposed resolution

fix the function calls

πŸ› Bug report
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States BenStallings

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @BenStallings
  • πŸ‡ΊπŸ‡ΈUnited States BenStallings
  • πŸ‡ΊπŸ‡ΈUnited States BenStallings
  • πŸ‡ΊπŸ‡ΈUnited States BenStallings

    OK, never mind, this seems to be a problem with old data left over from before an upgrade. A card that has been entered recently receives payment method type "stripe_card" and can be reused, no problem. The problem is if you try to reuse a card with payment method type "credit_card," because that type (from commerce_payment module) does not define the isReusable() method.

    If you are experiencing this problem, run the following:
    `drush sqlq 'UPDATE commerce_payment_method SET type="stripe_card" WHERE type="credit_card"'`

    That should fix it. It would be nice to have fixed this in an update hook when the module updated, but that proverbial ship has sailed.

  • πŸ‡ΊπŸ‡ΈUnited States BenStallings

    I stand corrected, just changing the type in the database is not enough, you also have to populate all of the tables with their non-stripe equivalents:

    insert into commerce_payment_method__stripe_card_exp_month select cem.* from commerce_payment_method m join commerce_payment_method__card_exp_month cem on cem.entity_id = method_id left join commerce_payment_method__stripe_card_exp_month scem on scem.entity_id = m.method_id where stripe_card_exp_month_value is null;
    insert into commerce_payment_method__stripe_card_exp_year select cey.* from commerce_payment_method m join commerce_payment_method__card_exp_year cey on cey.entity_id = method_id left join commerce_payment_method__stripe_card_exp_year scey on scey.entity_id = m.method_id where stripe_card_exp_year_value is null;
    insert into commerce_payment_method__stripe_card_number select cn.* from commerce_payment_method m join commerce_payment_method__card_number cn on cn.entity_id = method_id left join commerce_payment_method__stripe_card_number scn on scn.entity_id = m.method_id where stripe_card_number_value is null;
    insert into commerce_payment_method__stripe_card_type select ct.* from commerce_payment_method m join commerce_payment_method__card_type ct on ct.entity_id = method_id left join commerce_payment_method__stripe_card_type sct on sct.entity_id = m.method_id where stripe_card_type_value is null;
    

    and then clear the cache.

  • πŸ‡ΊπŸ‡ΈUnited States torgosPizza Portland, OR

    In my opinion since this is an issue in a -dev version it's not too late to add this into an update hook. It seems pretty important.

  • πŸ‡ΊπŸ‡ΈUnited States TomTech

    There is already a revision that handles this: commerce_stripe_update_8103.

  • πŸ‡ΊπŸ‡ΈUnited States TomTech

    Be careful with an update statement like the one in comment #4, as that will update ALL payment methods, some of which might not be stripe, and should remain as "credit_card"...and as noted in #5, there are more statements that need to be executed. (All of which occur in commerce_stripe_update_8103.

    If you need to re-migrate any of this data, this update hook would likely be what you should model your update off of.

Production build 0.71.5 2024