@vmarchuk
The scenario you describe is not specific to the queue implementation, it seems. Can you provide details if it is?
The OOTB behavior for Event::PAYMENT_INTENT_SUCCEEDED handles payments in the 'authorization' or 'new' state, specifically,
if ($payment->getState()->getId() === 'authorization') {
// logic here
}
if ($payment->getState()->getId() === 'authorization') {
// logic here
}
This code could be changed to a switch statement, to log the case you describe e.g.
switch ($payment->getState()->getId()) {
case 'authorization':
// logic here
break;
case 'new':
// logic here
break;
default:
// skip logic here
}
Let's handle that in a separate issue, though, since it isn't specific to queue.
This appears to be a duplicate of ✨ Allow iframe CSS to be altered before it is encoded Fixed .
TomTech → changed the visibility of the branch 3422479-implement-support-for to hidden.
Hi @zohera
Changing the priority on this. Please review the list of priority options → .
Also, changing this to a support request, unless a bug is identified.
Based on the screenshot, the first thing that should be remedied is that the environment is NOT https. Payment gateways will NOT typically load/execute in a non-secure environment.
The payloads returned by the latest version of the API are different. (They can potentially be different in every API version change, which presents a challenge to move to a new version, without causing break changes to anyone doing custom webhook processing.)
At a minimum, the Event::CHARGE_REFUNDED code fails with the latest payload and would need to be updated. (See:
🐛
The charge.refunded webhook fails, response structure differs from the expected one
Fixed
, which did a retrieve to ensure we had the expected (older) payload, which had more data in it.) We would need to modify the refund code to use some faulting and/or additional retrieves to get the additional details needed.
We'll also need to communicate the version change, as any existing implementations with custom webhook processing will most likely break with the change in version. Would probably be better to make the version change in a new major release, rather than in a minor update.
Small commit pushed to use appropriate FileStorage class.
TomTech → changed the visibility of the branch 3424966-processing-webhooks-in to hidden.
I've run the pipeline on the proposed MR.
The PHPUnit tests are failing because of the defer.
It also introduces a phpcs test failure.
At a minimum, we should NOT defer on the checkout pages that require the stripe scripts, e.g. checkout pages with the payment_information and/or review panes.
The test failures are likely because of the deferral.
One possible middle ground would be to NOT defer/async on checkout pages to ensure current behavior, and defer/async on all other pages, since that is more of a "nice to have".
Closing as a duplicate of 📌 Attach Stripe.js using the defer attribute Needs review . There is more discussion there, including a proposed (albeit failing) MR.
Thanks, all!
Note: the last patch handles some, but not all 3ds2 issues.
Additional work is included in the MR that was created and merged in.
Merged!
Merged. Thanks, all!
A new 2.0.x branch has been created and an alpha release has been tagged for REST.
Closing out this ticket, as the initial development is in place. Expect to see a few items come up as further testing is done. (But, would be happy if there aren't any!) Unit tests would be a good addition, as this module is pretty light in that regard.
Changing the target version to 2.0.x for REST implementation.
Hi @tonytheferg !
The primary API needed is the "Rates and Transit Times API".
I'm still working on the re-roll, which addresses additional issues and edge cases, including having a fallback for the rate request type.
IRT the password issue, please see: 🐛 When updating the configuration form your password gets wiped. Closed: duplicate .
Merged, thanks!
Merged!
I concur with @mikelutz that we need more phpunit tests.
We do need to get a final 1.x release out, though.
We've started a 2.x branch for the move from SOAP to the REST APIs, and will focus on adding tests in that branch.
Seems reasonable to allow hundredths, and also to drop the minimum.
We can also remove the size attribute, since it doesn't apply to number input controls.
The module currently installs into D9. It is possible that this was an issue with a previous beta, but does not appear to be a current issue.
If you are still not able to install, please advise!
The issue stems from the PluginSelectWidget in commerce core.
When a plugin edit configuration form is initially loaded, the configuration is properly passed to the plugin before the form process begins. (This is in the PluginSelectWidget ->formElement() method.)
When the form is posted back, though, the configuration was not being passed to the plugin.
A fix has been committed in [#33021571] that resolves this. This should be in the next commerce release.
If you need it before then, you can apply the diff from that MR as a patch.
Closing this out as (Duplicate), since the fix is in commerce core.
TomTech → made their first commit to this issue’s fork.
Hi @tonytheferg!
Appreciate the feedback!
Working on re-rolling the MR given D10 compatibility (and other changes related to the test suite) have been merged in.
Also adding in more validation and messaging.
Expect to tag this as a new version release, given that SOAP -> REST is not a straight swap out.
Things to note:
- Your SOAP credentials will NOT work with REST. You'll need to go to developer.fedex.com, and create a REST API project, to get new credentials.
- IRT meter, this property is not used in the REST API, hence the removal.
Since SOAP based support is ending in a couple months, Closing this in favor of 📌 Migrate to WhatArmy/FedexRest Active .
This was resolved in another issue, 📌 Drupal 10 Compatibility Needs review .
This was resolved in another issue, 📌 Drupal 10 Compatibility Needs review .
Thanks for identifying this and making the fix!
For context, this regression was introduced because PHPStan flagged the query as missing the accessCheck(), which became a required call in D10. See: https://www.drupal.org/node/3201242 →
The normal fix is to add $query->accessCheck();, as this is the default behavior in versions prior to D10.
In this particular case, ->accessCheck(FALSE); was being invoked earlier in the code, but through a chained call, which PhpStan did not identify.
I should have caught that when making the D10 compatibility/PhpStan fix.