I had an issue with this today on a large dataset, applied the patch and it resolved the issue for me in the short term till I can resolve the data issue.
c_archer → created an issue.
Patch #29 and #27 does not apply against version 4.0.0-alpha6
c_archer → created an issue.
I added a date range facet and a commerce price field with a range facet.
c_archer → created an issue.
c_archer → created an issue.
Added a patch on the other module
Created a MR to resolve the issue.
Have created a MR to resolve this.
c_archer → created an issue. See original summary → .
c_archer → created an issue.
c_archer → created an issue.
c_archer → created an issue.
Created a new MR for this which simplifies the logic.
Has anybody looked into this?
Has there been any progress with this?
Roman just tried applying your MR against the latest version and it does not apply
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.