Merged 11.x again, and updated per your comment.
Thanks for the feedback.
Relate / duplicate https://www.drupal.org/project/commerce_stripe/issues/3546136 🐛 Include requires action intent status to prevent intent cancellation Active ?
Created 📌 Tag a Drupal 11 release Active for a nudge
aaronbauman → created an issue. See original summary → .
This was fixed yesterday by 🐛 Error on redirect to display that uses contextual filters and route parameters Active
Rerolled MR to fix js linter issues
Updated IS
aaronbauman → made their first commit to this issue’s fork.
The individual checkboxes do have labels.
Not sure when/if this changed since previous comment April 2024, but this is not moot.
I did my best to reroll the changes, but the CSS diff is basically unreadable.
It's a very brittle changeset that's going to break again if there are more upstream changes to CSS.
Setting to "needs work" per pervious comment.
astonvictor added to maintainers.
thank you for your efforts!
I agree, changing the order would make more sense to me.
I didn't want to introduce a breaking change without knowing why they were in this order, but if you are more familiar with how this works then I will defer to you.
Opened a new branch to try a 4.x version of this patch, but 4.x Places appears to be broken / unsupported.
aaronbauman → made their first commit to this issue’s fork.
MR 116 adds a test to demonstrate the server key problem.
Thank you for all these details.
Ddev looks like a great project.
But it seems a bit unwieldy to include this stack of tooling into every contrib project.
There must be a more efficient way to achieve this, rather than copy-pasting the same configuration everywhere?
I believe this was addressed by 🐛 RelatedTermString plugin discards multiple values Active
Copying RTBC status from duplicate #3540647
Closing as duplicate on #3539586
Looks like this is moot, based on https://git.drupalcode.org/project/protected_pages/-/commit/cc15bc142730...
Can someone confirm?
Rerolled MR again.
This has been RTBC for almost 2 years, can we get this committed please?
aaronbauman → created an issue.
aaronbauman → created an issue. See original summary → .
This patch was quite a mess after the other upstream changes.
I've cleaned it up and opened a new MR !30, and attaching patch version of same.
I'm not going to bother with an interdiff.
aaronbauman → changed the visibility of the branch 3111456-resolve-langcode-issue to hidden.
aaronbauman → changed the visibility of the branch feature/3111456-langcode to hidden.
aaronbauman → changed the visibility of the branch 3111456-resolve-langcode-issue to hidden.
#78 does not apply on latest dev
Actually seems like maybe \Drupal\Core\Cache\RefinableCacheableDependencyTrait would be more appropriate?
aaronbauman → created an issue.
aaronbauman → created an issue.
working for me, +1 RTBC, thanks
Huh, yeah, i see that now.
Weird that it's working at all then, unless like you suggest it's legacy support.
Seems straightforward enough.
OAuth JWT is a different module altogether.
The doc you want is user-agent flow.
https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_u...
The recommended method is OAuth JWT, and setup is described here:
https://www.drupal.org/docs/contributed-modules/salesforce-suite/create-... →
and here:
https://www.drupal.org/docs/contributed-modules/salesforce-suite/set-up-... →
That's provided through salesforce_jwt sub-module
salesforce_oauth module is not really supported or recommended any more, so I'm hesitant to make further updates.
The namespace was changed, and now it's been changed back to avoid this exact issue.
See
https://github.com/drush-ops/drush/issues/6018
https://github.com/drush-ops/drush/pull/6019
🐛
Compatibility with Drush 13
Active
Opened MR 180, which cancels zero-balance payment intents during the destruct method of the order payment intent subscriber.
Not sure this is the best way to handle it, but it's working for me.
Issue is in the destructor, which instead of cancelling a zero-dollar payment intent, attempts to update the amount to zero.
This is invalid, according to Stripe, which throws an exception:
The amount must be greater than or equal to the minimum charge amount allowed for your account and the currency set (https://docs.stripe.com/currencies#minimum-and-maximum-charge-amounts). If you want to save a Payment Method for future use without an immediate payment, use a Setup Intent instead: https://docs.stripe.com/payments/setup-intents
The exception gets caught and logged, but the payment intent does not get removed.
Subsequently, upon checkout, the payment intent is processed with the incorrect amount.
aaronbauman → created an issue.
Merged, thanks for the patch
aaronbauman → made their first commit to this issue’s fork.
I don't think project bot is going to be doing any additional automated followups.
Probably makes sense to mark this fixed, since the OP has been resolved, and open new issues if there are additional deprecations during D11 minor releases.
Why was this marked fixed?
The MR was not merged, and there is still not D11 release
Should this be marked fixed?
If not, can someone update IS with remaining todos?
Emailed maintainers
aaronbauman → created an issue.
Opened a clean Merge request !12486 against 11.x for review
aaronbauman → changed the visibility of the branch 3532360-check-for-session to hidden.
aaronbauman → created an issue.
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?