🇵🇱Poland @Patryk Padus

https://www.drupal.org/u/jsacksick → can you check it? This can require to replace whole API and fixes for old one as well as XML method will require to be removed

Patryk Padus → created an issue.

@DamienMcKenna do you need help? Are you into this issue? It block whole Commerce deployment as now is don't have one production grade shipping method integration

Maintainer suggest only to swap library and maintaining will be provided n future : https://github.com/abantecart/ups-php/issues/7#issuecomment-1832083838

I ask about difference: https://github.com/abantecart/ups-php/issues/7
We should only replace API as issue is critical and required to be solved in fastest manner to have 1 from 2 available shipping integration provider

As stated "changes immediately" are needed and is crtical. We have now same issue as well.
Is there any news about that?
What i see is there XML used: https://git.drupalcode.org/project/commerce_ups/-/blob/8.x-3.x/src/UPSRa...

As stated composer: https://git.drupalcode.org/project/commerce_ups/-/blame/8.x-3.x/composer...
This library don't support oAuth and is abandom: https://github.com/gabrielbull/php-ups-api/issues/370

There is new library needed to be incorporate:
https://github.com/abantecart/ups-php

It's now only one to be incorporate to existing package and set as v4 version to difference for change of API provider

Patryk Padus → created an issue.

It is when there plugin create situation of not unique SKU
This should resolve to block saving in that situation

Patryk Padus → created an issue.

Patryk Padus → created an issue.

Patryk Padus → created an issue.

@jsacksick

How should we signal that?

It should break on start of script - version of PHP CLI isn't proper one and nothing inform about that. That will do less harm and is DX better that looking there.
Somewhere like "doInitializeHook" should contain simple "if PHP_VERSION" for CLI that is minimal to have proper boot or fail before anything is init. I only provide proper testing case for this issue that can be easily replicated and people sometime will find this issue in future (when you need PHP 10 and you get PHP CLI 8 same issue will emerge.

Thx @shalini_jha for commit and fork ! Need only someone to test and review if solution is proper

Path not apply on branch 9.x (latest I test is 9.5.1)

Drupal 9.x give issue:
Drupal\Core\Entity\EntityStorageException: No entity bundle was specified in Drupal\Core\Entity\ContentEntityStorageBase->createWithSampleValues() (line 230 w .../public_html/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php).

If bundle isn't exist then get error. Bundle removed in Commerce when attribute removed from list but not from LayoutBuilder

Patryk Padus → created an issue.

Yes. Actual. WSOD get when removing attributes but they are references in Layout Builder somehow

Patryk Padus → created an issue.

Fixed issue with pricing on pull request - https://github.com/krystalcode/drupal8-commerce-option/pull/13. Will be easier to add it into 8.x module where I can contribute fixes and help maintain. Module need some documentation too.
This publication will resolve this issue and on proper place will be fixes and isuess provided

Order item fields

Yes, you have right in one way to do it - the proper one i core.
"Until the user clicks the Add to Cart button, there is no order and there is no order item." <- there is product price and that we need change base on product options

What I see is simpler way for now in this steps:
1) alter form adding ajax callback : " https://www.drupal.org/docs/drupal-apis/javascript-api/ajax-forms → "
This way we get any change or fields into our controller.
(This I Don't know how)
2) Update price base on field and value
I create sample module to do it on Query and Page Refresh and work as designed
https://github.com/Art-Decor/commerce_pricing_options (some start but manage by front parameters, your module use resolver in better way)
Need to use Resolver on ajax call.
3) Force refresh variation template
JS call that variation is change even if not. Only to re-load template
(I do full page refresh but price is properly calculate and added to product base pricing)

This way we use composition on form to add capabilities by module (no need core changes) and have now calculation base on order item field value.

Product variations

"large number of variations" - milions aren't even possible to be properly handled by Commerce and Drupal due to some issue in optimization. That's why it isn't possible right now. That's why I'am here as was too shock how much it will needed.

Product options

I checking this and this is solution that need you to add as "you" on module in dev branch:
https://github.com/krystalcode/drupal8-commerce-option
We tested it and work as good as needed. Issues that are connected to it (but impotant and small one to fix):
- no ajax on changing attributes (feature is override add to cart with ajax capabilities but for now it work without)
- need option visible as duplicate to properly working when adding to cart
- pricing is added on second product when only first one should get updated (that's only one critical to be fixed - two products with customization aren't separated when price is added ;/)
- product options is cloned to order data? - my understand is that using proper commerce api we have it save as clone and not reference (older order won't change data after removing product options). That should be working in module properly, only asking.
- public it on module page with 7.x as 8.x? as dev branch but like to add fixes and work on it. More people will help maintain

Over that - module you provide is what we looking and plenty people too so don't hesitate and public as you (on " https://www.drupal.org/project/commerce_option → ") , we are glad to test it and help maintain it.

Issue is discuss there that is releated to this : https://www.drupal.org/project/commerce/issues/2897226#comment-15277336 ✨ Allow order item fields to modify the product price on ajax Active

"I don't know how people are managing to price if they have 10 attributes with different prices where you could use simple formula +x USD per attribute"
I don't know too.
If there is 5 variation and 10 optional attributes then how I can show them for client and have different price base on selected values in optional attributes?

Releated to this issue on 7.x: https://www.drupal.org/project/commerce/issues/1541886#comment-12263155 →

@krystalcode Can you only check if this is in context of this module? Do you know how I can achieve this? Need little guide :)

Editable fields - they aren't supported and the data isn't save into cart
Product Builder - as a fields that don't change anything, only add option to separate list of fields into separate entity. Removing it will remove crucial information on order entry.
Customizable products - they exist on 7.x , we should downgrade to have same function as mentioned in term of fields etc.
Pricing can be handled only when having variant - no other option is available. There is more than 3M variants in this scenario

What in one line will this add to module and whole range on new solutions:
✅ Pricing rule base customer customizable product (native commerce order items field)

Yes. I take example from this: https://fineartamerica.com/featured/soft-blue-gradient-cubes-elisabeth-f...
As you can see:
- one single product
- field type change fields
- fields can be 1 to 6
- pricing change on options

Having variation in one product won't be possible.
I fix Product Builder but ths or native fields for customization (/admin/commerce/config/order-item-types/default/edit/fields) isn't consider into pricing.

We only see this as major obstacle and clear that this type of custom field (I can write ajax to send it into controller if that something out of scope for this module) should be adjustable by this module. Other Customization aren't available as 7.x have that feature

I will add example pic where field "TEST FRAME OPTION AS VIRTUAL WITHOUT SKU" don't have any engine to adjust pricing when we clearly need that. ( https://www.drupal.org/files/issues/2023-10-13/Zrzut%20ekranu%202023-10-... → )

@rszrama great! Thanks :D That was fast

After some mentor and guidance we can help maintain it for behalf of client as part of working solution

Patryk Padus → created an issue.

Patryk Padus → created an issue.

Yes. This error is on production version : https://www.drupal.org/project/physical/issues/3345698 📌 Align with the commerceguys/intl changes Fixed

Production version have this issue right now:
Fatal error: Declaration of CommerceGuys\Intl\Formatter\NumberFormatter::format($number, array $options = []) must be compatible with Drupal\physical\NumberFormatterInterface::format(string $number, array $options = []): string in .../public_html/vendor/commerceguys/intl/src/Formatter/NumberFormatter.php on line 68

Installing recommended dev will fix it

Issue is by using CLI php on version 7.4 and not 8.1
My FPM is different and use 8.1 and CLI was configured on 7.4

This error will be constantly. Better way is to signal that CLI version mismatch
I think is critic as this block Drush fully from operating ;/

Readme is about Stripe Payment Element but they are right now on dev branch. Will be deploy of stable version with that? We don't have right now enabled what on screen is visible

@drugan but you reference issue that is resolved. Is there some changes need?

Possible temporary actions:
- Disabling module, adding variation and enabling won't bring error.
- Don't use multiple type (work fine on on type)

This is only one issue that block new stable version in my opinion when verified that issue is in dev branch from maintiner

Screen showing how must be configured for this issue to be visible.
Path of screen where configuration was taken: /admin/commerce/config/product-variation-types

Patryk Padus → created an issue.

There is another connection:
- Add field (I use Commerce module)
- Add new reference to this field in "View" -> "Advanced" -> "Reference"
- Try to remove field, it won't remove it from View and won't list it as blocked by usage.
- Get WSOD where view is used with referenced to non-exist field

When re-adding issue gone and when removed issue back so this issue caused by UI and user so critical state is correct

It's critical. Block page when editing template

@gabykule
Solution is to update core drupal as patch fix weight of dependencies in aggregation engine
https://www.drupal.org/project/gutenberg/issues/3348997 🐛 Gutenberg does not load with css and js aggregation enabled Closed: works as designed
Pleas verify if that help in this scenario as well

Yey, I found solution for this issue and confirm it can be close for good
I updated from 9.5.9 to 9.5.10 and the issue was gone.
It is related to: https://www.drupal.org/project/drupal/issues/3222107 🐛 Library order asset weights do not work properly when a large number of javascript files is loaded between two jQuery UI libraries Fixed

Pleas - after update you need to clear cache.

@szeidler
The https://www.drupal.org/project/drupal/issues/2990907 🐛 JsOptimizer preg_replace gives null as return Needs work is not the case. Tested patch on drupal/core (9.5.9) and issue remaining
Have same console log in panel.
Element `gutenberg-loading` is over top menu what is issue by itself ;/

Patch need to updated. Right now it won't apply in current version of module on dev branch

Patryk Padus → created an issue.

Oh yeas,

I fix too by using that type of code:

  public function getTokenValue($token, ResultRow $values, ViewExecutable $view) {
    $token_info = $this->getTokenArgument($token);

if(isset($token_info['id'])){
    $id = $token_info['id'];
}
$token_type = NULL;
if(isset($token_info['id'])){
    $token_type = $token_info['type'];
}

    // Collect all of the values that we intend to use as arguments of our
    // single query.
    switch ($token_type) {
      case 'raw_fields':
        $value = NULL;
        if (isset($view->field[$id])) {
          $value = $view->field[$id]->getValue($values);
        }
        break;
      case 'fields':
        $value = (string) $view->field[$id]->last_render;
        break;
      case 'raw_arguments':
        $value = $view->args[array_flip(array_keys($view->argument))[$id]];
        break;
      case 'arguments':
        $value = $view->argument[$id]->getTitle();
        break;
      default:
        $value = Html::escape(trim($token, '\'"'));
    }

    return $value;
  }

So I apply what @nitin_lama propose and is working now great :)

I use this that work in today version:

      case 'raw_fields':
        $value = NULL;
        if (isset($view->field[$id])) {
          $value = $view->field[$id]->getValue($values);
        }
        break;

Added patch file from diff of @sakthi_dev

Disable JS aggregation for now. It is cause by: https://www.drupal.org/project/gutenberg/issues/3348997 🐛 Gutenberg does not load with css and js aggregation enabled Closed: works as designed

After refresh page the "Finish" show up. Only ajax is issue there
Like this : https://snipboard.io/IabKB1.jpg

@jsacksick I added some better description.
SKU is updated, field "Finish" not as it not exist in default variation or prior to added field.

Solution is in template:
Field after rendering in template work correct - require that all variations have fill up all new added field.
When they don't have filled up then jQuery not updating new field as response have data but selector don't find node

Patryk Padus → created an issue.

Patryk Padus → created an issue.

Patryk Padus → created an issue.

This is major problem in few different area for us.
First, it will add new element in Checkout Flow to have separate it and manage with some limitations of order (address before methods)
Second, we like to have methods as separate page where payment and shipping is as two list in one step. Right now it isn't a option.
Third, recalculation will require some work.
Four is fallback for existing implementations
Lastly to get back from Drupal 7 feature like in this example of checkout: https://wydawnictwowam.pl/

Method of @rhovland is not accepted in long run.
How from theme i can adjust panels to my needs?

My two cents. I'am VUE advocat and this is list of why I prefer VUE over other libraries:
- Fully support web component library which is goal to be decoupled from decision of what library can be used: https://custom-elements-everywhere.com/
- Compatible with JSX, React, Ember and other. No name collapse, no fuss about mixing thinks if somebody like.
- Inline template - huge benefit in term of admin panel where less people change somethink
- Vuex is working and is properly connected and mature.
- Vuex, vue router and some other libraries are supported by same core team
- Performance gain as more declarative approach to template.
- Lock down features - hooks are from 2.x but less feature will be added. Core team propose to build extension rather than bloat vue. Treeshakeable to even less bargain in every pull. Huge mind change in term of what other advertise.
- Mature framework now with decoupled core and added Typescript checking for whole solution
- Better quality as they start earlier and learn from React/Angular ("steal best thinks" xD). Core team understand other libraries and built on experience other failures. Think about next iteration of React
- No big company stand for license (Facebook change react license and that will be catastrophic, learn from history - https://www.freecodecamp.org/news/facebook-just-changed-the-license-on-r...)
- Proper, full documentation with DX on mind
- Tests, Typescript and fully polished framework to ci/cd approach. Focused to bring more tests and polish everyday.
- Component approach is more "template" than "utility" but component can be wired in Drupal easily and clean.
- Designed for incremental adoption
- Accessibility aware in core, docs and outside (Docs: https://github.com/vuejs/vuejs.org/issues/974, https://vue-a11y.com/)
- Static site can be generate and this library is friendly for solutions like that - example: Nuxt. So this can be used as SSR site.
- PWA friendly
- Webpack friendly - key aspect for many people
- Extension to Debug data in browser
- XState compatible and easy to use - proper adapter exist. This is usefull to design state of every screen and transitions.
- Hooks is introduced to better wire components together as mixins are less featured. In 3.x as part of it.
- Native solution exist - https://vue-native.io/

There is caveats:
- React ecosystem is bigger but not mature. More bugs can be introduced. Other framework have smaller ecosystem but polished.
- As a Component approach is forcing some way to code. It is little more opinionate than React where you can do in any way you like.
- React and other libraries are battle tested as small like vue will have his first time to be introduced in such a big framework and scale. What we mean is real number of different problem. Facebook tested it in heavy way and this is first think that anybody is look for it. Vue take part of solution to their core so it's not big difference.
- Community is young, less professional in term of what is inside in core packages.