🇺🇸United States @AaronBauman

Great, thank you for the fix!

Please create a MR and I will merge it.

What kind of tests do you want to see for this @joevagyok?

aaronbauman → created an issue.

Thanks, that change makes sense to me and should address my use case.

Not sure how or why variationTypes and variationType contained different values previously, but this should fix it.

Still relevant in Commerce 3

Here's the patch I'm using.
I assume maintainers are not gonna want to roll this in, so I won't bother with an MR.
But it's working for me.

OK, i traced the culprit to commerce_product_update_10301, which according to docblock :

/**
 * Moves 'variationType' setting to the 'variationTypes'.
 */

Problem was that my "variationType" was set to "default", but "variationTypes" was set to "shippable" (and shippable only).

So, after updating, "variationType" is gone, and variationTypes is "default" and "shippable" - not what i want!
And since it's a simple inline entity form, I guess it just uses the first value, which is not correct.

Not sure how this was resolved previously, but turning "default" off again solved it.

Opened MR 468 with patch from #2

Here's the patch.

aaronbauman → created an issue.

aaronbauman → created an issue.

Opened MR 467 with same patch from #3

Here's a patch.
Uses exact same approach as patch from 🐛 SplObjectStorage::contains(): Argument #1 ($object) must be of type object, null given Fixed

Here's a stack dump.

In my case, the invocation of CurrentCountry originates from a route rebuild of a views data export display that includes a price field.

TypeError: SplObjectStorage::contains(): Argument #1 ($object) must be of type object, null given in ~/web/modules/contrib/commerce/src/CurrentCountry.php on line 45 #0 ~/web/modules/contrib/commerce/src/CurrentCountry.php(45): SplObjectStorage->contains(NULL)
#1 ~/web/modules/contrib/commerce/src/Resolver/DefaultLocaleResolver.php(37): Drupal\commerce\CurrentCountry->getCountry()
#2 ~/web/modules/contrib/commerce/src/Resolver/ChainLocaleResolver.php(46): Drupal\commerce\Resolver\DefaultLocaleResolver->resolve()
#3 ~/web/modules/contrib/commerce/src/CurrentLocale.php(46): Drupal\commerce\Resolver\ChainLocaleResolver->resolve()
#4 ~/web/modules/contrib/commerce/modules/price/src/CurrencyFormatter.php(29): Drupal\commerce\CurrentLocale->getLocale()
#5 [internal function]: Drupal\commerce_price\CurrencyFormatter->__construct(Object(Drupal\commerce_price\Repository\NumberFormatRepository), Object(Drupal\commerce_price\Repository\CurrencyRepository), Object(Drupal\commerce\CurrentLocale))
#6 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1142): ReflectionClass->newInstanceArgs(Array)
#7 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(586): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true, 'commerce_price....')
#8 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1260): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('commerce_price....', 1, Array, true)
#9 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1212): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Object(Symfony\Component\DependencyInjection\Reference), Array, true)
#10 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1112): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array, true)
#11 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1262): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true)
#12 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1212): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Object(Symfony\Component\DependencyInjection\Definition), Array, true)
#13 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1212): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array, true)
#14 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(1112): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array, true)
#15 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(586): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true, 'serializer')
#16 ~/vendor/symfony/dependency-injection/ContainerBuilder.php(531): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('serializer', 1)
#17 ~/web/modules/contrib/views_data_export/src/Plugin/views/style/DataExport.php(52): Symfony\Component\DependencyInjection\ContainerBuilder->get('serializer')
#18 ~/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(21): Drupal\views_data_export\Plugin\views\style\DataExport::create(Object(Drupal\Core\DependencyInjection\ContainerBuilder), Array, 'data_export', Array)
#19 ~/web/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('data_export', Array)
#20 ~/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(824): Drupal\Component\Plugin\PluginManagerBase->createInstance('data_export')
#21 ~/web/core/modules/rest/src/Plugin/views/display/RestExport.php(351): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('style')
#22 ~/web/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\rest\Plugin\views\display\RestExport->collectRoutes(Object(Symfony\Component\Routing\RouteCollection))
#23 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes()
#24 ~/web/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func(Array)
#25 ~/web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
#26 ~/web/core/includes/common.inc(485): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
#27 ~/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(87): drupal_flush_all_caches()
#28 [internal function]: Drush\Commands\core\UpdateDBCommands->updatedb(Array)
#29 ~/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
#30 ~/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#31 ~/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#32 ~/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#33 ~/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#34 ~/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#35 ~/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#36 ~/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#37 ~/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#38 ~/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#39 ~/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run(Array)
#40 ~/vendor/drush/drush/drush(4): require('/Users/bauman/S...')
#41 ~/vendor/bin/drush(120): include('/Users/bauman/S...')
#42 {main}
TypeError: SplObjectStorage::contains(): Argument #1 ($object) must be of type object, null given in SplObjectStorage->contains() (line 45 of ~/web/modules/contrib/commerce/src/CurrentCountry.php).

aaronbauman → created an issue.

bump

Depends on 🐛 Check for session before calling getSession(), or catch SessionNotFoundException Active

aaronbauman → changed the visibility of the branch 3532439-TEST-ONLY to hidden.

Oh, thanks for the heads up - TIL!

Is that a configuration for core only, or for all projects?

aaronbauman → created an issue.

3532360-TEST-ONLY MR !12485 - test only to demonstrate bug.

3532360-check-for-session MR !12486 - includes test and fix, ready for review

MR 13 ready for review

Neither patch nor MR are applying to D11

aaronbauman → created an issue.

aaronbauman → created an issue.

I see.
Do you have a thread open about this in Drupal core somewhere?
I'm not an expert on dependency injection, but my understanding is that this approach breaks testability and autowiring. Possibly other consequences as well. Seeing as how Commerce is, like, top 10 modules for Drupal, it's weird to implement an anti pattern.

I won't hold my breath about Commerce specifically, but I'll urge you to keep an open mind about it.

I started working on a MR, but this issue is pretty extensive.

Will wait to hear from maintainers as to whether this change would be considered before I sink more hours into it.

aaronbauman → changed the visibility of the branch 3530865-why-is-dependency to hidden.

aaronbauman → created an issue.

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

aaronbauman → created an issue.

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

Reviving this because I'd like to add shipping and tax to the orders view.

There are two "Adjustment" fields that show up in views - for Orders and Order Items - but they don't render anything.

Is Commerce supporting adjustments in views now?
And if not, is it still too painful to add support?

Yup, makes sense.

I found the module https://drupal.org/project/jquery_downgrade that I'm gonna try to limp along with for now.

I haven't thoroughly tested, but at least some of my pages appear to be rendering properly now and I'm not getting a console full of javascript errors.

Helpful! And thanks for updating the IS

Yeah, it is working fine.
I was confused somehow

aaronbauman → created an issue.

Since this issue was the top hit on Google for my query "drupal 11 bootstrap jquery" - what is the status?

Is Bootstrap going to work with Drupal 11 or not?

Opened MR144
https://git.drupalcode.org/project/radix/-/merge_requests/144

aaronbauman → created an issue.

Figured it out. The MR didn't have a composer.json

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

aaronbauman → created an issue.

aaronbauman → created an issue.

aaronbauman → created an issue.

Looks good to me.
Thanks for jumping on that feedback so quickly.
I'll set to RTBC and get it into the next release.

push params event is also called in PullBase

Probably the SalesforcePushParamsEvent in PullBase should be made into its own class.
Seems like it was shoehorned in there, and is not exactly appropriate for the use case.
That's outside the scope of this issue though.

This is good to go i think.

Also opened related issue 📌 Improve pull queue exception handling and subscriber options Active

aaronbauman → created an issue.

LGTM

Thank you for the detailed description and the MR.
This is an interesting idea, I think we can make something work here.

I don't like having these 2 different events one after another - one event should suffice. And I'd like to see it be a little less single-purpose.

Proposed changes:
1. Build this logic into existing PushParams event, rather than adding a new event
2. Allow subscriber to override push operation and choose any of update, upsert, or create

So maybe that looks like a new method on PushParams, which can be set by a subscriber to override whatever operation would have been selected in MappedObject::push

Does this make sense? I think it would solve your issue, as well as making this more useful in more scenarios.

aaronbauman → created an issue.

Opened MR448 converting patch #32 into MR, and moved the availability logic into an AvailabilityChecker

Seems like this should all be going into an AvailabilityChecker instead of jammed into the process method:

      $purchased_entity = $order_item->getPurchasedEntity();
      if (!$purchased_entity) {
        if ($order_item->hasPurchasedEntity()) {
          $order_items_to_remove[$order_item->id()] = $order_item;
        }
        continue;
      }
      // Check if the product or variation is unpublished.
      $product = $purchased_entity->getProduct();
      if (empty($product) || !$product->isPublished() || !$purchased_entity->isPublished()) {
        $order_items_to_remove[$order_item->id()] = $order_item;
        continue;
      }

MR44 is passing, back to NR

Hid the other 2 MRs

aaronbauman → changed the visibility of the branch 3107993-3x-template-not-found to hidden.

aaronbauman → changed the visibility of the branch 3107993-template-is-not to hidden.

+1 RTBC pls merge

MR27 gtg please merge.

Please commit

So it is, thanks!

aaronbauman → created an issue.

aaronbauman → created an issue.

aaronbauman → created an issue.

aaronbauman → created an issue.

Patch #2 works great for me, thanks

This doesn't have anything to do with Salesforce module.

Please create an issue against core, or whatever contrib module is responsible for this.

This is committed to 2.0.4

This patch uses the "amount_to_collect" received from Taxjar and creates a single, Adjustment on the Commerce Order for the tax amount.

Please review.

Fixed, thanks for the patch

The module does send the shipping cost to Taxjar, but I honestly don't know how that gets handled on the Taxjar end.

Do you know of a jurisdiction in which shipping is taxable, so that we could test it?

Fixed, thank you for the patch

Yes, you can implement hook_commerce_taxjar_tax_request_alter and hook_commerce_taxjar_transaction_request_alter to set $request_body to an empty array based on your business logic. This will avoid sending the request to TaxJar altogether.

Closing all 7.x issues. Please reopen if this issue still pertains to D10 version

Closing all 7.x issues. Please reopen if this issue still pertains to D10 version

Closing all 7.x issues. Please reopen if this issue still pertains to D10 version

Closing all 7.x issues. Please reopen if this issue still pertains to D10 version

Closing all 7.x issues. Please reopen if this issue still pertains to D10 version

Good idea, thanks for the patch

Fixed, thanks for the patch

Good idea, thanks for the patch

Thank you for the patch, this is now moot

Fixed in D10 version, thank you

Fixed, thank you

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

This was due to a patch I was running locally. Working as expected without that patch.

Emailed andyg5000 requesting commit and release access.

aaronbauman → created an issue.

aaronbauman → created an issue.

aaronbauman → created an issue.

aaronbauman → created an issue.

aaronbauman → created an issue.

Yeah, i'm running into all sorts of problems.

I had to switch back to the basic credit card pane, and even that is be a bit buggy.