Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.1. Create and pay for an order (I used the test gateway provided by uc_payment)
2. Go to the orders page and view the order. For example, admin/store/orders/9
3. Click "Payments", for example admin/store/orders/9/payments
You get this fatal:
Fatal error: Call to a member function label() on null in /Users/rfay/workspace/d8git/modules/ubercart/payment/uc_payment/src/Form/OrderPaymentsForm.php on line 92
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | ubercart.call_to_a_member-2788963-10.patch | 14.75 KB | rfay |
| |||
| #8 | 2788963-uc_payment-plugin-label.patch | 13.13 KB | longwave |
Comments
Comment #2
rfayOne little bit to add: I have #2695639-07: Zero price product generates error when checking out patching current dev.
Comment #3
TR CreditAttribution: TR commentedSeems to be a problem with the test gateway - I can't reproduce it with other payment methods / gateways.
We do have test cases for the OrderPaymentsForm, but it seems we only test with the 'check' payment method.
Comment #4
rfayIt does it on uc_stripe as well.
Comment #5
TR CreditAttribution: TR commentedMy vague theory is that the test gateway is neglecting to do something that is assumed of gateways and that it doesn't inherit a default something from the CreditCardPaymentMethodBase. This could be the case for your uc_stripe as well ...
I'll be looking into this ...
Comment #6
rfayI agree with your random theory :) Although I looked at the test gateway a bit, I mostly just inherited.
Comment #7
longwaveThis is a configuration machine name vs plugin ID issue. uc_payment_enter() stores $method, aka "the payment method ID" in the database, but this has not been fully updated from D7 and so it is not exactly clear whether this should be a config ID or a plugin ID. At the moment most places assume this is a config ID, but this is problematic from within plugin classes and plugin instances do not know their parent configuration ID. Instead I am leaning towards storing the plugin ID (and serialized configuration) here, as then we can recreate the plugin afterwards, if we need to, without needing the config entity at all - this may be useful for e.g. refunding payments later while allowing payment methods to be deleted.
#2789967: Receive_check creates an "other" payment if check method label is not exactly "check" is related.
Comment #8
longwaveWe can create the plugin with no configuration data, all we really need is the label so this should be enough for now.
Comment #10
rfayJust took a look and tried to do this one like the other ones were done. I think the 3 'Simpletest' uc_payment_enter() were just overlooked. Just changed those 3 from 'Simpletest' to 'other' for the method (in CartCheckoutTest::testCheckoutComplete())
Comment #11
rfayAlso, @longwave, your patch fixes the OP in manual testing. Thanks!
Comment #13
longwaveCommitted #10, thanks for finishing this off.
Comment #15
kruser CreditAttribution: kruser commented--deleted--