🇭🇷Croatia @valic

Updating request to reflect ownership

Is there any update on this? It is now 4 weeks from original issue?

The failing tests are already standard on 2.x, which runs fine on 2.0.x. Merging

{"sessionId":"cecc7406bb7c7e18fd184307c749d8f8","status":10,"value":{"message":"stale element reference: stale element not found in the current frame\n (Session info: chrome-headless-shell=123.0.6312.58)\n (Driver info: chromedriver=123.0.6312.58 (6b4b19e9dfbb93aa414dc045bd445287977d8d7a-refs/branch-heads/6312_46@{#3}),platform=Linux 6.1.153-175.280.amzn2023.x86_64 x86_64)"}}

valic → created an issue.

the D10 release
https://www.drupal.org/project/commerce_unleashed/releases/1.0.x-dev →

Hi,

I haven't got any response from David on any of channels where I did contacted him

Today is 14 days from comment #6

no, it says I am not authorized to run them

Linking for reference the issue from which unit test failure originated.

And closing as fixed, the tests on 3.x are passing now

Linking for reference the issue from which the unit test failure occured

Proposing to replace

 export PROJECT_TYPE=$(sed -n -e 's/^[[:space:]]*type:[[:space:]]*//p' $INFO_YML | head -1 | tr '[:upper:]' '[:lower:]' | tr -d '"' | tr -d "'")

export PROJECT_TYPE=$(sed -n -e 's/^[[:space:]]*type:[[:space:]]*//p' $INFO_YML | head -1 | tr '[:upper:]' '[:lower:]' | sed 's/[^a-zA-Z0-9]//g')

Not sure do have any `type` which have something else than letters (even numbers probably aren't there)

Update the problem description

Wrong thoughts :D closing

valic → created an issue.

The unit test failure is strange.

Did run locally entire CI, and it's visible that geoip is not copied over to
/builds/project/geoip/web/modules

but to

/builds/project/geoip/web/module s/

Maybe I did drink too many beers today, but unit tests are passing at my local without any problems.

So assuming this is some quirk of Drupal infra, and whilst this goes to 3.x branch which created I have felling tomorrow will merge.

We can resolve it before having 3.1.x release

tagged new release, tnx
https://www.drupal.org/project/commerce_currency_resolver/releases/2.0.1 →

Annoying with the JS test, random failures.

But they are passing so will merge. but against 2.x, than 2.0.x and tag a release

{"sessionId":"041ae45357533bb671bb767caa911d82","status":10,"value":{"message":"stale element reference: stale element not found in the current frame\n  (Session info: chrome-headless-shell=123.0.6312.58)\n  (Driver info: chromedriver=123.0.6312.58 (6b4b19e9dfbb93aa414dc045bd445287977d8d7a-refs/branch-heads/6312_46@{#3}),platform=Linux 5.10.242-239.961.amzn2.x86_64 x86_64)"}}

I did want to not support D10 intentionally but could not time the release with 3.2 exactly, so probably people had made an upgrade to 3.2 with D10

And you did invest effort already, so why not :-D

Closing as outdated

Please refer to documentation of 2.x version

https://git.drupalcode.org/project/commerce_currency_resolver/-/blob/2.x...

With 2.0 as far or resolving for now think the feature set is done.

If someone sponsors this, I can work on that, until than no time for it (and no reason, I use VCL on all of my projects to achieve that)

You can now use both cookie an geo resolving with new 2.0.0. version.

Note that cookie resolver is executed before geo resolver.

If there is no cookie, the next resolver would be fired is geo
You need to enable on 2.0.0. version the new submodules - cookie and geoip or smartip

Same answer as for https://www.drupal.org/project/commerce_currency_resolver/issues/3193566 ✨ Allow the use of location with the currency block selector. Fixed

You can now use both cookie an geo resolving with new 2.0.0. version.

Note that cookie resolver is executed before geo resolver.

If there is no cookie, the next resolver would be fired is geo
You need to enable on 2.0.0. version the new submodules - cookie and geoip or smartip

Out of scope unfortunately , the 2.x version released. But don't have time for this rather specific scenario.

Suggesting maybe pushing prices via JS, and via JS alter bef exposed slider output to show desired currency

I think you need to write own price field formatted to account for your scenario and display all prices in all currencies.

Alternatively if you use exchanger for automatic conversion, maybe you can use formatter from there
https://git.drupalcode.org/project/commerce_exchanger/-/blob/2.0.x/src/P...

Please try new 2.0.0 release and reopen new issues if problem persists

Please try new 2.x version.

Should have more specific constraints when order is able to be refreshed

You can now use both cookie an geo resolving with new 2.0.0. version.

Note that cookie resolver is executed before geo resolver.

If there is no cookie, the next resolver would be fired is geo
You need to enable on 2.0.0. version the new submodules - cookie and geoip or smartip

Is this still an issue? Seems rather specific, why it would resolver change currency of order on payment page?
Do you have some custom code?

Or it's done maybe via webhooks intent update? If that is the case, now with 2.x version it should not update

Tnx.

Will close it now. From version 2.x we do only set condition amount per currency, and everything else leave to core.

https://git.drupalcode.org/project/commerce_currency_resolver/-/blob/2.x...

Commerce Core introduced currency resolvers now from version 3.2
Same concept as for current store, etc..

You can see examples in new 2.0.0 release of this module as well
https://www.drupal.org/project/commerce_currency_resolver/issues/3242245 ✨ Alternative resolving methods Active

This does not have anything with this module judging by this message

For example, if I add three products and click the Add button, it automatically displays a message saying there's only one item, and the cart always returns to one item.

Is this still relevant?

btw. you can try new release which is more recent
https://www.drupal.org/project/commerce_currency_resolver/releases/2.0.0 →

Tnx, but will mark as fixed.

The new 2.x branch does not have that interface anymore.

And 8.x support soon to be dropped

You can do it via form alter.

And note that disabled currencies are not loaded in the block

/**
 * Implements hook_form_FORM_ID_alter().
 */
function your_module_form_commerce_currency_resolver_cookie_select_form_alter(&$form, FormStateInterface $form_state, $form_id): void {
  $options = $form['currency']['#options'];

  foreach ($options as $currency_code => $currency_name) {
    if ($currency_code === 'EUR') {
      unset ($options[$currency_code]);
    }
  }

  $form['currency']['#options'] = $options;
  $form['currency']['#default_value'] = Drupal::service('commerce_price.current_currency')->getCurrency()->getCurrencyCode();
}

In original 8.x version we did intentionally skipped conversion trough CLI because it caused more problems.

In new version 2.x there is no such limitation, so please try with new.

At the end if you can't get what you want, I suggesting writing price resolver for that case

Tnx. We don't use anymore default country concept or default currency to fallback on from version 2.x

So closing this one as outdated

Use form alter

/**
 * Implements hook_form_FORM_ID_alter().
 */
function your_module_form_commerce_currency_resolver_cookie_select_form_alter(&$form, FormStateInterface $form_state, $form_id): void {
  $options = $form['currency']['#options'];

  foreach ($options as $currency_code => $currency_name) {
    $options[$currency_code] = $currency_code;
  }

  $form['currency']['#options'] = $options;
  $form['currency']['#default_value'] = Drupal::service('commerce_price.current_currency')->getCurrency()->getCurrencyCode();
}

Will mark this as obsolete.

8.x is not anymore supported. Please try with new 2.x version

https://www.drupal.org/project/commerce_currency_resolver/releases/2.0.0 →

Please see new 2.0 version and try with that one https://www.drupal.org/project/commerce_currency_resolver/releases/2.0.0 →

Now with version 2.0 exchanger is not required anymore.

Please refer to the release and change record
https://www.drupal.org/project/commerce_currency_resolver/releases/2.0.0 →

All the tests are green.

Made a change record draft as well

Hi,

Tnx.

Attached the mail sent to David month ago and slack convo few days back. So it did pass a month from the initial mail

I am OK with maintainer-ship for this project. (no need for ownership)

Valentino

valic → created an issue.

valic → created an issue.

valic → created an issue.

Tnx

Tnx.

I did update as well validation on \Drupal\commerce_exchanger\ExchangerManager::setLatest if someone is doing direct updates, that we adhere to some structure with `.` as delimiter.

And in addition added states logic on form, that manual value can be entered without needed to check it first, than save, than edit

valic → made their first commit to this issue’s fork.

valic → created an issue.

valic → created an issue.

Made direct commit, could not found the @thony1199 commit anywhere

Added checkbox under Marketplace to enable fulfillment preview. The output is stored under $shipment->setData
Added even subscriber to be able to alter the payload.

valic → created an issue.

The initial dev version is out. 2 years later :-D

Now I really need this integration

https://www.drupal.org/project/commerce_revolut/releases/1.0.x-dev →

valic → made their first commit to this issue’s fork.

I don't see it as needed, from perspective of per example commerce_currency_resolver, I did now wrote three resolvers with different weights, so they can be used even simultaneously, etc: cookie resolver first, if there is no cookie, geo resolver goes next, etc..

Don't have need to interact with getResolvers()

1. Yes, it's not used anymore currently, so there is no changes in any of existing API-s.
2. Expanding context maybe have a sense, but it would introduce BC for that part. For majority of the shops probably which are single currency it does not benefit them, only multi currency which again is granulated how it's implemented

I am OK to RTBM this.

I did test with couple of my resolver, language, etc, it works great

Example of resolving per user language

You need than install commerce_exchanger version 2

There is releasewhich supports Commerce 3 https://www.drupal.org/project/commerce_currency_resolver/releases/8.x-1.80 →

8.x-1.61 is pretty old release, can you try with never version

valic → created an issue.