c_archer → created an issue.
Patch in #263 works as expected
Patch in #220 no longer applies against facet version 2.0.9
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
Can confirm the MR resolves the issue.
Just tried this patch and it does not apply against 5.0.x-dev@dev
Tested the MR and it does add the password fields to the user edit page. Would it not be better to redirect the user to the user/change-password page?
Is this not the same as: https://www.drupal.org/project/change_pwd_page/issues/3372510 🐛 Module breaks core's password reset form Needs review
Just tried this patch and it does not appear to work.
It would be great to get this feature into the module as it would be very useful. I have just tried the patch in #18 and it works great!
Looks like this is a duplicate issue of https://www.drupal.org/project/taxonomy_menu_ui/issues/2995584 ✨ Add token support Closed: won't fix should have spotted this first.
c_archer → created an issue.
c_archer → created an issue.
Thats great!
Also worth noting even if we're not saving its still registers in the db
Thanks for the response, agreed we should at least display a prompt for this feature not been supported. Then this ticket can be put into backlog for when one of us has time to implement.
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
Ah thats good news! Yeah I think it would be good to have a new order state for carts which have failed payments like Pending or at least in the cart view have a field which states failed payment or possibly more useful checkout flow state (Order info/Review/Payment) etc.
c_archer → created an issue.
Do you get any errors in the watchdog when products are synced. It looks like the module has some logic (https://git.drupalcode.org/project/commerce_printful/-/blob/2.0.x/src/Se...) to handle multiple images per variation.
I don't have any products with multiple images so not hit this issue, if I get time I'll try and test but will not have time this week
Has any progress been made with this?
Tested the MR and confirm it works as expected.
Has the Conversions API support been implemented for the Drupal 7 and D10 version of the modules?
Roman this looks like a good start, I can see one blocker on the pr. If "Use per store settings" is checked its not clear to the user that they don't have to enter settings per each store. For example:
User has:
EU SS account
UK SS account
On the site they have these stores:
EU Store
UK Store
US Store
US store and UK store both use the UK SS account and the EU Store uses the EU SS Account. Does the user have the enter the UK SS account details twice?
Final comment could we change "Use per store settings" label to "Shipstation Account per store" or something similar?
Yeah I think your right, I'll close this issue for now.
Thanks Roman, your latest patch fails as the first part of it has already been released. Updated to take this into account.
VBO could be used in this instance but it would be nice if it was there out of the box to make managing these easier.
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
The latest patch fails against the 2.0.1 version of the module
Sadly this still seems like an issue, we'll try and provide more info soon
I can't see any reference in the API docs to us needing to send a phone number? https://developer.elavon.com/products/opayo/v1/submit-transactions-from-...
c_archer → created an issue.
c_archer → created an issue.
Thats great let me know when its released will this release resolve the phone number issue too?
Would it be better to use https://www.drupal.org/project/telephone_international_widget →
I have updated the default Flat Rate Per Item plugin to include a new base rate option. I have also checked that if exisitng shipping methods with the plugin are created these do not break.
Is there a plan to get a release for the module?
c_archer → changed the visibility of the branch 3419316-module-is-blocking to hidden.
c_archer → created an issue.
If the user is a guest, we can still grab from their profile as they will enter this either as shipping or billing profile and then we send that to sage reducing the need to enter it twice or three times in the current case.
Patch worked for me.
This worked for me and solved my issue of shipping prices not been calculated. Patch works well.
So in validateTelephoneNumber we're checking for billing address but at the time the user clicks submit and we try and find the phone number the profile info has not been copied.
c_archer → created an issue.
Can this info not be grabbed from the profile and skip these fields all together
This is due the config assume the payment gateway has been named sagepay_opayo
public function getSagepayConfiguration(OrderInterface $order = null): array {
$gateway_configuration = [];
// Get the payment gateway configuration.
if ($sagepay_opayo_configuration = \Drupal::config('commerce_payment.commerce_payment_gateway.sagepay_opayo')) {c_archer → created an issue.
This does seem to have resolved the issue.
Patch works great, are we able to get it released?
c_archer → created an issue.
For example this is the promotion.
In this instance is should be £5.75 for shipping:
In this example it should be £8.32:
c_archer → created an issue.
Any update on this, as cleaning up the order in mailchimp is not a solution as a customer could add two of the same products to their cart.
Have tried the patch and it resolves the issue.
Patch on #60 currently fails against latest commerce release 2.37.0
c_archer → created an issue.
Marking this as closed as it was an issue with: https://www.drupal.org/project/yoast_seo/issues/3404287#comment-15400536 📌 Exclude analytics_core from JS preprocessing to reduce PHP memory footprint when using JavaScript aggregation RTBC
Any update on this?
c_archer → created an issue.
c_archer → created an issue.
Have you been able to replicate this locally as I have been able to on test mode. But no more debugging has been able to be find.
c_archer → created an issue.
Can confirm the patch applies against 2.1.0-beta1
It looks like this issue was due to not having the shipping set up correctly. Should we add a check for this or at least flag the order will fail if no shipping method setup?
Ah good spot! The patch works as expected.
Patch is great, can we get this merged.
This is the output of the log, I can replicate locally in test mode too:
[Sat, 12/23/2023 - 19:16] [Debug] [commerce_opayo_pi] [client: 172.23.0.6, testuser] OpayoPiPaymentGateway::requestMerchantSessionKey: Before merchant session key request, mode: test
[Sat, 12/23/2023 - 19:16] [Debug] [commerce_opayo_pi] [client: 172.23.0.6, testuser] OpayoPiPaymentGateway::requestMerchantSessionKey: Successful merchant session key response, mode: test
[Sat, 12/23/2023 - 19:16] [Info] [commerce_opayo_pi] [client: 172.23.0.6, testuser] OpayoPiPaymentGateway::requestMerchantSessionKey: new merchant session key: SESSION_KEY (expiry: 2023-12-23T19:23:34.937Z), mode: test
[Sat, 12/23/2023 - 19:16] [Debug] [commerce_opayo_pi] [client: 172.23.0.6, testuser] OpayoPiPaymentGateway::getNewMerchantSessionKey: sequence nr: 9 for session key: SESSION_KEY (expiry: 2023-12-23T19:23:34.937Z) for order 45 (uid: UID), mode: test
I think your right that JS error is the wrong rabbit hole.
To replicate this I'm on the order_information using a live connection.
I enter card details and click Continue to review
On clicking the screen just reloads the same page and I do not get the review pane as expected.
In the drupal logs I see OpayoPiPaymentGateway::getNewMerchantSessionKey:… and OpayoPiPaymentGateway::requestMerchantSessionKey: new…
I'm using Use custom Commerce form - more customer-friendly checkout experierce but higher PCI compliance (SAQ-A-EP) burden. (default) and have not checked 3D Secure challenge inside iFrame this makes no difference in the console I see no errors or red flags.
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
I used the
Use Opayo Drop-In form - easier PCI compliance (SAQ-A) but less customer friendly checkout experience.
I've had some people say they can't complete as its asking them for a phone number even tho they entered one.
The step we can't get past is first pane where you enter your payment details
This seems to work for the form integration but can't test the direct one due to this bug https://www.drupal.org/project/commerce_opayo_pi/issues/3410544 🐛 Can't get to review screen with direct intergration Active
c_archer → created an issue.
This seems to have been caused by an update in the module which was missing some update hooks. Have uninstalled and re-installed module to resolve for now.
c_archer → created an issue.
Yes this now works lets mark this as closed.
c_archer → created an issue.