🇮🇱Israel @jsacksick

Note that no actions buttons are shown when the payment gateway isn't onsite, so no way to submit a payment for manual gateways etc...

Not yet, in about 2 weeks from now, for DrupalCon Vienna.

How is that a bug report? We won't be renaming the PaymentMethodAddForm class as this would be a breaking change for implementations extending it or using it.

This is more like a base class / example class used in test payment gateway plugins and used by the commerce_payment_example module.

Payment gateways typically define their own Payment method forms.

Merged! Thanks @tbkot!

jsacksick → created an issue. See original summary → .

Is this saying that each minor Drupal release, i.e. 3.1.0 and 3.2.0 (the current releases on the project page) are actually commerce major releases or are they just minor releases and the next major release will be 4.0.0? I guess the thing that isn't clear to me is if there is a straightforward upgrade pathway from 3.1.0 to 3.2.0.

Minor releases, and the next major release will be 4.0.0.

I also think it might be worthwhile putting that link or the like on the project page as this change will possibly confuse others too.

true, will add that.

So I don't get it, you need this to be fixed on a 2.x install? Or are you still experiencing this with 3.x? With the latest version?

Hm... I think you need to ensure the store has a tax registration set in the United states.

Hm... I think this is a duplicate of 🐛 Buy X Get Y promotion creates orphaned order items with NULL order_id when using Calculated Formatter Active .
This was fixed in 3.2.0.

This probably should be a Commerce License issue.

License::presave() has the following code.

        $activation_time = \Drupal::service('datetime.time')->getRequestTime();

        if (empty($this->getGrantedTime())) {
          // The license has not previously been granted, and is therefore being
          // activated for the first time. Set the 'granted' timestamp.
          $this->setGrantedTime($activation_time);
        }

If the license state is active and no granted time is explicitly set, the granted time is set to the current time.

Perhaps you should explicitly set the granted time?

This was documented: https://www.centarro.io/blog/revisiting-semantic-versioning-drupal-commerce

Works as expected, thank you for this! Merged!

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

But as I wrote, I'm not sure if this can be reliably detected and how fast that would be.

Yes, I agree with that... We could rely on $order->hasTranslationChanges() perhaps? But this wouldn't account for order item changes. Order items are saved by the order refresh in case they have changed.

Also FYI, one recent improvement to the order refresh was setting the order item original before calling hasTranslationChanges() to avoid reloading order items from the DB.

Regarding:

Improve the refresh itself: #3416998: Stop unsetting the order ID reference from the order refresh

I have this patch applied on a project, but the tests aren't completing, they seem to be hanging forever... So I never actually merged the change due to that.

Also... One last thing, if the cart expiration is turned on, carts will be deleted after a certain time. On various of my projects, carts are expired every 24 hours.

1. Is it possible for a cart order without order items to be reused? The fact that I have 9 of them seems to say no. But I'm not sure about this. If save, we could consider to delete an order if it's in draft and the last order item is deleted from it?

Of course, the fact that you have 9 of them is probably due to the fact that you've started orders as anonymous, then logged in, the cart was assigned to your user, and then did that multiple times. That would be my guess.

2. Should the query/logic in \Drupal\commerce_cart\CartProvider::loadCartData() account for orders with no items? At least the default cart block also explicitly ignores orders without items

I don't think so, as that would mean creating another cart order instead of reusing the one without order items?

Can we reliably detect if a refresh actually changed the order state? Because if so, and if not explicitly requested, then we could skip the save.

A refresh isn't normally supposed to change the order state? The order refresh refreshes prices, and invoke order processors .Unless an order processor somehow changed the state (which shouldn't be the case, I don't really think this is supposed to happen.

Regarding the order refresh happening too often, are you aware of the order type setting? You can reduce the order refresh frequency, also configure it to refresh orders belonging to the current user.

Let's merge this, this looks good to me! Thanks for reporting back.

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

Fixed in dev, thanks for the contribution.

jsacksick → created an issue.

Committed, thank you!

Thanks! Merged

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

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

I am sad now. I simply need to add a small handling fee, but it is not to be taxed. I did this in commerce 1.x with rules as I recall

You can either write your own order processor than runs after the tax order processor. Or alter the order processor defined by this module so the Fee is applied post tax calculation.

That means all fees won't be taxed though.

You actually can't, that's a known issue, the Commerce tax logic has the following code:

        // Now determine the tax amount, taking into account other adjustments.
        $adjusted_total_price = $order_item->getAdjustedTotalPrice(['promotion', 'fee']);

It's taking into account fees. I think there is an open Commerce issue for that (to allow determining if an adjustment should be taxable or not).

@tbkot: Instead of hardcoding the component, shouldn't we use a regular form mode? So the widget settings can be tweaked?

Thank you, merged!

Shipping is taxed differently, commerce_product_tax just tells the commerce_tax module which rate it should resolve for a given product, that's all.

Patch had the wrong diff...

Attaching a static patch.

Patch in #8 does fix the entity definition issue, but now stores can't be disabled as the checkbox is required to save the entity.

Weird, I really remember testing that locally after writing the update hook because I suspected this would happen.
Let's go with setDefaultValue(), when I was manually checking the differences with the debugger, see the screenshot from #4. The difference seemed to be the "not null" value.

Anyway, attaching a new patch that uninstalls the content_translation_status field if present. And the update hook now only calls setDefaultValue(TRUE).

So we might need to uninstall the "content_translation_status" field.

We have this code in commerce_shipping:

  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();

  foreach (['content_translation_created', 'content_translation_changed'] as $field_name) {
    if ($field_storage_definition = $definition_update_manager->getFieldStorageDefinition($field_name, 'commerce_shipping_method')) {
      $definition_update_manager->uninstallFieldStorageDefinition($field_storage_definition);
    }
  }

We need to do to the same I think for "content_translation_status".

jsacksick → created an issue.

D7 is EOL, closing this.

D7 is EOL, closing this.

D7 is EOL, closing this.

D7 is EOL, closing this.

D7 is EOL, closing this.

D7 is EOL, closing this.

\Drupal\commerce_price\CurrencyFormatter passes the locale to the Commerce Guys INTL currency formatter from the constructor:

  /**
   * Constructs a new CurrencyFormatter object.
   *
   * @param \CommerceGuys\Intl\NumberFormat\NumberFormatRepositoryInterface $number_format_repository
   *   The number format repository.
   * @param \Drupal\commerce_price\Repository\CurrencyRepositoryInterface $currency_repository
   *   The currency repository.
   * @param \Drupal\commerce\CurrentLocaleInterface $current_locale
   *   The current locale.
   */
  public function __construct(NumberFormatRepositoryInterface $number_format_repository, CurrencyRepositoryInterface $currency_repository, CurrentLocaleInterface $current_locale) {
    $default_options = [
      'locale' => $current_locale->getLocale()->getLocaleCode(),
      // Show prices as-is. All digits (storage max is 6), non-rounded.
      'maximum_fraction_digits' => 6,
      'rounding_mode' => 'none',
    ];

    parent::__construct($number_format_repository, $currency_repository, $default_options);
  }

You should double check what is your current locale.
Also, you could potentially swap the CurrencyFormatter with your own and hardcode the passed locale to the desired one.

Support requests aren't answered from Drupal.org per the issue queue guidelines. Also, this is related to one of your custom fields so we cannot really provide assistance here.

Since this is likely due to your custom setup, it is hard for us to provide support here. Also, it has been more than 4 years, so I'm guessing this is no longer relevant. Feel free to reopen in case you're able to provide reproducible steps and more information about the bug.

I know this has been created a while ago... Are you invoking capturePayment() yourself? If so, entities are always passed by reference in PHP, so the original payment entity passed to capturePayment() should reflect the changes after its invoked no? Also yeah, because of BC, we can't really change this.

I just tried that and couldn't apply the same coupon code more than once.
Anything particular about your setup? Or was this fixed since this was reported?

Considering this as outdated since there hasn't been a new report since october 2022. Also, a bug that cannot be consistently reproduced is very hard to fix.

I believe this is a duplicate of 🐛 Skip Order Refresh on draft anonymous orders on CLI Fixed .

jsacksick → created an issue.

jsacksick → changed the visibility of the branch 3326441-paymentmethodpermissionprovider-error-in to hidden.

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

hm... Could you provide an extended backtrace? This should help identifying what's causing this. Right now it is hard to assist with such little information.

Hm... I'm not experiencing this... Is this happening on a vanilla install? If so, could you provide reproducible steps and reopen?

Closing this as I'm not really sure what was actually reported and there was no response to my comment from 2023.

Ok so I asked ChatGPT which says the following :):

So why are you getting /product/123;?v=12346;?

👉 It’s most likely due to trailing commas in the replaceState call:

window.history.replaceState(
{},
document.title,
`${window.location.pathname}?${params.toString()}`, // <-- this comma
);

In JavaScript, trailing commas in function arguments are allowed in modern engines, but some minifiers, transpilers, or older browsers can mis-handle them. If that happens, the argument list can be parsed incorrectly, and you can get garbage like ; injected into the resulting URL string.

Going to remove the comma and commit, hoping we finally identified what's causing the issue.

What is your suggested fix? Likely not a "bug" but more like a documentation issue? Or perhaps we should not hide the order types if there is only one? Or not make it required if there's a single order type?

I believe this was addressed by 📌 Add Adjustment Total Field Formatter Active .

D7 is EOL, therefore marking this as "won't fix".

This is more like a support request which aren't answered from this queue per the issue queue guidelines.

With that said, you should be able to extend the core login checkout pane programatically and override the isVisible() method to account for your custom logic.

D7 is EOL, therefore closing this.

Looks like this was answered long ago, closing this.

I'm going to mark this as "won't fix" as we're trying to move away from the IEF module (which still doesn't have a stable release).

We're getting closer to that thanks to the new order items widget introduced in 📌 Define an OrderItems widget leveraging our Inline Form plugins Active .

Yes, definitely a core issue, marking this as won't fix as we can't actually do anything about that.

There are templates you're free to alter based on the price formatter used.

This would be more like a support request which aren't answered from this queue.
I also don't think we could provide a quick answer here, as this would require knowledge of your setup etc.

hm... This isn't a bug, this is the default checkout completion message which can easily be changed by changing the checkout pane settings.

D7 is EOL, so closing this.

Likely too late to change this... Would be to afraid to break existing sites relying on the current behavior somehow.

This is likely outdated and may have to do with your setup. Not so much we can do from the Commerce side of things as this cannot be reproduced on a clean install.

Should we not extend the title widget instead? Add settings to be able to choose a different field rather than defining a completely new widget that duplicates most of the existing logic?

This is likely due to custom code or a contrib code perhaps? If this was a widespread issue, we would have gotten more similar reports. Besides this report is probably outdated by now.

You have several ways of extending this. EIther by swapping the Inline form plugin, or by swapping the payment information pane and override the buildBillingProfileForm() method. Considering this hasn't been widely requested, I believe these solutions should be good enough.

D7 is EOL and is no longer maintained, closing this.

Commerce 1.x supported order revisions, we actually didn't implement order revisions due to the numerous issues encounted with revisions back then.
Additionally, for sites with a large amount of orders, revisions are overkill and causes the DB storage to grow exponentially... So we've decided internally not to support revisions.

Hm... This isn't how it looks for me in my test install.. Also the display can be tweaked as mentioned, so not really sure there is anything actionable here.

Commerce order doesn't really do anything in particular with tokens, besides providing additional ones. Alos not sure this is still relevant after 5 years.

With the amount of information provided in the report, I'm not really able to help further. Could you provide more details? Is this still relevant after 3 years?

3 years have passed since, guessing you're not longer expecting an update. Besides, support requests aren't answered from this queue per the issue queue guidelines.

D7 is EOL, closing this.