🇭🇷Croatia @valic

New setting form to specify default color values

valic → created an issue.

valic → created an issue.

valic → created an issue.

@JeroenT can you open MR agains 3.0.x branch. tnx

valic → created an issue.

valic → created an issue.

valic → created an issue.

Tests are passing. PHPCS is ok. We will deal with cspell and one phpstan notice in next version (requires a cache tag change which I am no willing to do for this release

valic → created an issue.

Hi,

Tnx. That was fast! Everything works.

Valentino

valic → created an issue.

valic → created an issue.

1. Dismiss text (or icon, etc) needs to be wrapped in class "dismiss" under main promo bar CSS id "#promo-bar-{id}"

JS then attaches an event to it, and it's handled by JS. Storing in local storage list of dismissed promo bar id's

Example of default template
https://git.drupalcode.org/project/commerce_promo_bar/-/blob/1.0.x/templ...

and JS which handles all of that
https://git.drupalcode.org/project/commerce_promo_bar/-/blob/1.0.x/js/pr...

You can remove them from display at `/admin/commerce/config/promo_bar/form-display`

But note that the default value would be stored, so you need to adjust the template an remove color manipulation.

Added a new option so that the promo bar can be dismissed.

With JS we can manipulate visibility and removal

valic → created an issue.

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

Not sure though that Wallet would be a good name for it

Or we could declare `wallet` payment method in Commerce Core with additional field for wallet type (google pay, apple pay, etc..)

Now when I look at added code, ApplePay and GooglePay payment method definitions are credit cards, just with different (branded) labels.

With Wallet payment method type we would not need definitions across contribs. And with additional field, we can still see the provider of payment

<?php

namespace Drupal\commerce_payment\Plugin\Commerce\PaymentMethodType;

use Drupal\commerce_payment\Entity\PaymentMethodInterface;
use Drupal\entity\BundleFieldDefinition;

/**
 * Provides the generic wallet payment.
 *
 * @CommercePaymentMethodType(
 *   id = "wallet",
 *   label = @Translation("Wallet"),
 * )
 */
class Wallet extends CreditCard {

  /**
   * {@inheritdoc}
   */
  public function buildLabel(PaymentMethodInterface $payment_method) {
    $args = [
      '@card_number' => $payment_method->card_number->value,
    ];
    return $this->t('Google Pay ending in @card_number', $args);
  }

  /**
   * {@inheritdoc}
   */
  public function buildFieldDefinitions() {
    $fields = parent::buildFieldDefinitions();
    $fields['wallet_type'] = BundleFieldDefinition::create('list_string')
      ->setLabel($this->t('Wallet provided'))
      ->setDescription($this->t('The wallet provider type.'))
      ->setRequired(TRUE)
      ->setSetting('allowed_values_function', ['\Drupal\commerce_payment\Wallet', 'getTypeLabels']);

    return $fields;
  }

}

valic → created an issue.

Adding a patch with renaming methods with the prefix braintree_

Did not commit in MR, because maybe some folks ran a patch from the URL above, which would crash because of the plugin name change.

For anyone who would need to migrate apple_pay and google_pay payment methods to use new plugin names, you can update them like this

  $payment_method_tables = [
    'commerce_payment_method',
    'commerce_payment_method__card_exp_month',
    'commerce_payment_method__card_exp_year',
    'commerce_payment_method__card_number',
    'commerce_payment_method__card_type',
  ];

  foreach ($payment_method_tables as $payment_method_table) {
    $property = $payment_method_table === 'commerce_payment_method' ? 'type' : 'bundle';
    \Drupal::database()->update($payment_method_table)->fields([$property => 'braintree_apple_pay'])->condition($property, 'apple_pay')->execute();
    \Drupal::database()->update($payment_method_table)->fields([$property => 'braintree_google_pay'])->condition($property, 'google_pay')->execute();
  }

Does that mean once we add apple_pay and google_pay in Commerce core, those from Braintree would stay defined as braintree_apple_pay, , not as apple_pay method even if it is?

@chrisscrumping the last patch is always at the same URL when Gitlab is used. It is up to date with 8.x branch

https://git.drupalcode.org/project/commerce_braintree/-/merge_requests/4...
(plain diff URL next to merge request link above)

The logic is correct. The refresh_once is used for specific services that only publish once a day new exchange rates.

So you can at the plugin level specify (force) that it's only running once a day.

An example is ECB plugin \Drupal\commerce_exchanger\Plugin\Commerce\ExchangerProvider\EuropeanCentralBankExchanger

which in definition have set this property to TRUE

/**
 * Provides EuropeanCentralBank.
 *
 * @CommerceExchangerProvider(
 *   id = "ecb",
 *   label = "European Central Bank",
 *   display_label = "European Central Bank",
 *   base_currency = "EUR",
 *   refresh_once = TRUE,
 * )
 */

So for ECB, you can't run import more than once a day.

By default this value is FALSE - which means if the plugin does not specify it, you are allowed to set on the configuration page how often cron runs are needed

Tnx, merged

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

Tnx

Version 8.x is not getting any more updates. It's left only for easier transition from D9 to D10

Version 8.x is not going to be supported in Drupal 11

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

Will close this as outdated. If you want to use APILayer, I suggest that you create an exchanger plugin as a separate Drupal contrib module.

It should be straightforward because it's very similar to fixer.io.

Additional documentation for the plugin system can be found here https://git.drupalcode.org/project/commerce_exchanger/-/tree/2.0.x?ref_t...

#2 is no longer applicable, from version 2 we don't use any more Drupal configuration to store exchange rates.

Now it's dedicated database table `commerce_exchanger_latest_rates`

See 3366705 🐛 Latest exchange rates shouldn't be saved in config Fixed

You can use https://git.drupalcode.org/project/commerce_exchanger/-/blob/2.0.x/src/E... for storing and retrieving data.

updated, (the failing tests are coding standards for payment definition)

Fixed within 3444692 📌 PHP 8.2 compatibility / Enable gitlab CI Fixed

valic → created an issue.

@khiminrm added method to check if integration is enabled, it's used on both places now.

tnx

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

valic → created an issue.

So the shipping address zone is based on shipment, and billing on order entity type.

We should switch it to be order based - as is Shipping address condition

@thakurnishant_06 you missed the second commit https://git.drupalcode.org/project/commerce_zones/-/commit/4b1d4ce067cdc...

where I did rename the file properly.

The tests are running normally https://git.drupalcode.org/project/commerce_zones/-/pipelines

Tnx

updated to be able run GitlabCI before merging it

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

valic → changed the visibility of the branch 3421140-migrate-to-gitlabci to active.

valic → changed the visibility of the branch 3421140-migrate-to-gitlabci to hidden.

valic → changed the visibility of the branch 3421140-migrate-to-gitlabci to hidden.

valic → created an issue.

tnx

Not applicable anymore

Should we fallback to "Unknown" instead of empty string better?

I applied the patch and tested it on the Croatian / English admin language, and it works.
Marking as RTBM.

Landing from a related issue, I hit a problem with tax and a new adjustment type.

I'm unsure if #5 and depending on weight vs. adding taxable is a more considerable change.

But as I see it, both are BC, because we would need to change how the price is collected prior to applying taxes
$adjusted_total_price = $order_item->getAdjustedTotalPrice(['promotion', 'fee']);

#5 with weight could be a more straightforward approach. Still, I am unsure if contrib modules are considered tax when declaring the weight of adjustment (I did not think of taxes when creating the adjustment type with weight 10).

Adding taxable property seems as more self-documented approach.

valic → created an issue.

I fixed a couple of issues and left only handling stock during order placement or completion, as is in the core.

Based on these events, we update as well parent bundles.

But stock integration need to be updated more, created follow up https://www.drupal.org/project/commerce_variation_bundle/issues/3406899 📌 Rethink dynamic bundle local stock Active

valic → created an issue.

Additional rework of stock handling needed.

valic → created an issue.

If the title is larger than 255, we use default Commerce Core behavior

valic → changed the visibility of the branch 3406853-automatic-title-for to active.

valic → changed the visibility of the branch 3406853-automatic-title-for to hidden.

valic → changed the visibility of the branch 3406853-automatic-title-for to hidden.

valic → changed the visibility of the branch 3406853-automatic-title-for to active.

valic → changed the visibility of the branch 3406853-automatic-title-for to hidden.

valic → created an issue.

tnx, committed

@jscksick Yes, the most relevant comment would be #125 https://www.drupal.org/project/commerce/issues/2810723#comment-13832755 ✨ Allow order types to have no carts Needs work
where are the changes occurred

All changes have been moved to the commerce_checkout module, and back then we still had added to cart message which is not configurable

now it's needed to swap that, and should be separated

Expanded upon existing code to add settings form to be configurable to which roles are tracked, which product variation types are tracked, and if prices affected by coupons should be tracked. (as well as returned the previous version of price checking because had some duplicate entries)

Because I only need to track anonymous users, I did not expand further on other implementation details - calling proper user context on all places for non-anonymous users.

The settings form currently looks like this and the following settings are;
- user role - which user role to track
- variation types - which variation type to exclude (as in my case, I have bundles)
- option to turn on tracking prices affected by coupons

valic → created an issue.