@tonytheferg

I would say this issue is mostly aimed at areas where $next_state = $capture ? 'completed' : 'authorization'; is set without checking the related transaction event. This was the only place I found where this happens.

It appears to me that the payment element already gets the $next_state off the data from the capture method, not strictly from the $capture variable passed through createPayment() as is the case with the card element.

See: https://git.drupalcode.org/project/commerce_stripe/-/blob/8.x-1.x/src/Pl...

Maybe overly explicit, but I wanted to be safe rather than sorry.

Maybe we should fall back to $capture if $intent->capture_method is not set.

Here is a patch for starters

tonytheferg → created an issue.

Critical → seems correct, as the CVV seems completely broken here, and users should be aware when trying to implement.

Jumping in to confirm this. Using the same exact credentials between drupal 7 live site, and a drupal 10 development version. The CVV is set on the gateway to decline if no match, and on the Drupal 10 site, you can complete an order with ANY CVV code. 123 etc.

The transaction details show the following on submissions from Drupal 10:

Card Code Status: Not Applicable

Where as transactions are declined with D7 when the CVV doesn't match.
Major bummer.

This is probably a little cleaner.

Better title

I do think this is a bug, as changes to the transaction type through the provided event do not properly affect the capture behavior.

Same:
TypeError: str_replace(): Argument #3 ($subject) must be of type array|string, Drupal\layout_builder\Section given in str_replace() (line 32 of /var/www/html/web/modules/contrib/content_type_clone/src/Helpers/ContentTypeCloneHelper.php).

There is no patch to review here though.

Whoops, forgot TRUE logic.

tonytheferg → created an issue.

Getting better.

Test results:

There were 2 failures:
1) Drupal\Tests\commerce_vado\Functional\VadoCartTest::testSyncQuantityOn
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "edit-settings-container-hide-parent-zero-price" not found.
/builds/project/commerce_vado/vendor/behat/mink/src/WebAssert.php:731
/builds/project/commerce_vado/vendor/behat/mink/src/WebAssert.php:841
/builds/project/commerce_vado/tests/src/Functional/VadoCartTest.php:398
2) Drupal\Tests\commerce_vado\Functional\VadoManagementFormTest::testVadoManagementForm
Behat\Mink\Exception\ResponseTextException: The text "Add on product variation types" was not found anywhere in the text of the current page.
/builds/project/commerce_vado/vendor/behat/mink/src/WebAssert.php:907
/builds/project/commerce_vado/vendor/behat/mink/src/WebAssert.php:293
/builds/project/commerce_vado/web/core/tests/Drupal/Tests/WebAssert.php:979
/builds/project/commerce_vado/tests/src/Functional/VadoManagementFormTest.php:49
--
3 tests triggered 2 PHP warnings:
1) /builds/project/commerce_vado/web/core/modules/user/tests/src/Traits/UserCreationTrait.php:172
Array to string conversion
Triggered by:
* Drupal\Tests\commerce_vado\Kernel\Entity\VadoGroupTest::testVadoGroup
  /builds/project/commerce_vado/tests/src/Kernel/Entity/VadoGroupTest.php:180
* Drupal\Tests\commerce_vado\Kernel\Entity\VadoGroupTest::testVadoGroupDuplicate
  /builds/project/commerce_vado/tests/src/Kernel/Entity/VadoGroupTest.php:236
* Drupal\Tests\commerce_vado\Kernel\Entity\VadoGroupTest::testVadoGroupItemGroup
  /builds/project/commerce_vado/tests/src/Kernel/Entity/VadoGroupTest.php:206
2) /builds/project/commerce_vado/web/core/modules/user/tests/src/Traits/UserCreationTrait.php:188
Array to string conversion
Triggered by:
* Drupal\Tests\commerce_vado\Kernel\Entity\VadoGroupTest::testVadoGroup
  /builds/project/commerce_vado/tests/src/Kernel/Entity/VadoGroupTest.php:180
* Drupal\Tests\commerce_vado\Kernel\Entity\VadoGroupTest::testVadoGroupDuplicate
  /builds/project/commerce_vado/tests/src/Kernel/Entity/VadoGroupTest.php:236
* Drupal\Tests\commerce_vado\Kernel\Entity\VadoGroupTest::testVadoGroupItemGroup
  /builds/project/commerce_vado/tests/src/Kernel/Entity/VadoGroupTest.php:206
FAILURES!
Tests: 14, Assertions: 562, Failures: 2, Warnings: 2.

For:

 ------ ---------------------------------------------------------------------- 
  Line   src/Form/VadoManagementForm.php                                       
 ------ ---------------------------------------------------------------------- 
  59     Method Drupal\Core\Form\ConfigFormBase::__construct() invoked with 1  
         parameter, 2 required.                                                
 ------ ---------------------------------------------------------------------- 

See:
https://www.drupal.org/project/paragraphs_report/issues/3472669 📌 Drupal 11 Compatibility Fixed

Also seeing this in tests:
Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for views.view.commerce_vado_groups with the following errors: views.view.commerce_vado_groups:display.default.display_options.arguments.product_id.default_argument_skip_url missing schema

Also noticing some deprecations, note to self, see for backwards compatibility:
https://www.drupal.org/project/search_api_autocomplete/issues/3442321 🐛 Fix call to deprecated method renderPlain() Fixed

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

@gravisrs does this take care of it for you?

Seeing this on the page title here:
/admin/commerce/vado-groups

And here on the field labels here:
/admin/commerce/config/vado

Where else?

Again, glad to review a MR.
Thanks

patch neglects project bot changes

I'm currently maintaining it. I'll have a look at your merge request, and try to update when I have time.

Thanks!

For any who land here, I stumbled upon this error trying to create a backup of files.

#19 works. Thanks!

See https://www.drupal.org/project/commerce_conditions_plus/issues/3239061 🐛 Does not work with promotion offers Needs work

reroll

30 and 38 no longer apply to 10.3.5

I'm glad to review a MR

8.x is no longer supported

Thanks. I see you have the schema, sorry I am on my phone at lunch and didn't look.

Also I've really tried to keep the color box implementation as a equally up to date with the UI dialogue so I would really probably like to see this implemented in both.

Even though you might not be using Colorbox I understand why you might think that should be a separate issue but I really tried to keep the two features as equal as possible in the development of the module.

I'm cool with adding a class, but it needs to have tests in all applicable locations, and schema etc.

Thanks for the work on this. I'm flexible here @bedir.

Feel free to add that to the merge request.

Yup, that fixes it!

I will take a look! Thanks

Setting to needs work for more explicit functional tests.

I think we definitely need to make sure that the test is checking for an altered rate from an event subscriber, and accounting for a couple of selections on the checkout pane.

This bug was not caught before because there wasn't sufficient testing in to test that the event subscriber rate was applied both to the checkout Pane and also to the order summary

So I would highly recommend adding that test to make sure that this doesn't get broken later down the road.

With brief manual testing, the patch seems to fix the behavior reported in the issue. I don't understand how promotions were breaking this, but If you guys are confident this is the fix, then I say +1

I can try to have a look today.

Posted a patch for 10.2.6 for anyone who lands here.

https://www.drupal.org/node/2981047 →

Here is a patch that applies to 10.2.6. Removing this hunk from the phpstan-baseline.neon allowed it to apply cleanly:

diff --git a/core/phpstan-baseline.neon b/core/phpstan-baseline.neon
index b99733aed6aee10cb47823c0774d656d228f1db6..099a9a17e8e23cc7ec79a9176a3f610bfb67e15a 100644
--- a/core/phpstan-baseline.neon
+++ b/core/phpstan-baseline.neon
@@ -2500,11 +2500,6 @@ parameters:
 			count: 9
 			path: modules/views/src/Plugin/views/field/Date.php

-		-
-			message: "#^Method Drupal\\\\views\\\\Plugin\\\\views\\\\field\\\\EntityField\\:\\:getFieldStorageDefinition\\(\\) should return Drupal\\\\Core\\\\Field\\\\FieldStorageDefinitionInterface but return statement is missing\\.$#"
-			count: 1
-			path: modules/views/src/Plugin/views/field/EntityField.php
-
 		-
 			message: "#^Method Drupal\\\\views\\\\Plugin\\\\views\\\\field\\\\EntityField\\:\\:renderItems\\(\\) should return string but return statement is missing\\.$#"
 			count: 1

MR4224 doesn't apply to 10.2.6

https://www.drupal.org/project/smart_date →

Handles this

tonytheferg → created an issue.

+1 for this. The fix works.

+1 for this. The fix works.

Yeah, this needs some work. With 14 applied, the dropdowns in mobile don't expand.

+1 for the patch in #26 Couldn't install the module through importing config without the schema.

I just wasn't to reiterate #20

This is reproducible without promotions

No problem. See Ryan's quote in the IS linked.

I think we should think about that and account for those thoughts.

A third amount field seems like a bit much IMO.

Well if another amount field is considered, we should include that field in the form display so that users can manually specify an amount through the UI.

This is reproducible without promotions.

There is actually some cool functionality here, but it still lacks a default solution for per field config.

https://www.drupal.org/project/media_directories/issues/3045654 📌 Map Media Directories to physical directories Active

tonytheferg → created an issue.

tonytheferg → created an issue.

Bumped to major because media thumbnails are broken too.

Maybe the work from the referenced issue should be rolled together.

#7 removes the error, but breaks layout builder compatibility. Flexsliders with LB don't render with the patch.

Something like this works:

    $src = [];
    if (!preg_match("/<img.+?src=[\"'](.+?)[\"'].+?>/", (string) $item, $src)) {
      preg_match("/<img.+?srcset=[\"'](.+?)[\"'].+?>/", (string) $item, $src);
    }

#7 removes the error, but breaks layout builder compatibility. Flexsliders with LB don't render with the patch.

I was seeing this, but only for flexsliders that use media instead of files directly:

TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given in preg_match() (line 155 of modules/contrib/flexslider/templates/flexslider.theme.inc).

tonytheferg → created an issue.

Yeah, I thought that too, but I know you guys don't like superfluous settings.

My thought was that one entry for shipping and billing on newly created users could just be the standard.

Sorry for the lack of clarity here. Updated.

tonytheferg → created an issue.

tonytheferg → created an issue.

Just found this. Thanks for the fix!
How should accounts that are created programatically handle this sort when there is an existing username? Like is there a way to put an _1 etc after the username?

#4 Works, Thanks!

Setting to no returns all files, setting to yes returns nothing.

Not sure if this is the right fix. Need a maintainer who knows the module to review.

Here is the backtrace:

#0 /var/www/html/web/modules/contrib/filefield_sources/src/Plugin/FilefieldSource/Reference.php(48): filefield_sources_element_validate(Array, Object(Drupal\file\Entity\File), Object(Drupal\Core\Form\FormState))
#1 /var/www/html/web/modules/contrib/filefield_sources/filefield_sources.module(365): Drupal\filefield_sources\Plugin\FilefieldSource\Reference::value(Array, Array, Object(Drupal\Core\Form\FormState))
#2 /var/www/html/web/core/modules/file/src/Element/ManagedFile.php(91): filefield_sources_field_value(Array, Array, Object(Drupal\Core\Form\FormState))
#3 /var/www/html/web/core/modules/file/src/Plugin/Field/FieldWidget/FileWidget.php(337): Drupal\file\Element\ManagedFile::valueCallback(Array, Array, Object(Drupal\Core\Form\FormState))
#4 [internal function]: Drupal\file\Plugin\Field\FieldWidget\FileWidget::value(Array, Array, Object(Drupal\Core\Form\FormState))
#5 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(1266): call_user_func_array(Array, Array)
#6 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(1006): Drupal\Core\Form\FormBuilder->handleInputElement('node_tool_edit_...', Array, Object(Drupal\Core\Form\FormState))
#7 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(1076): Drupal\Core\Form\FormBuilder->doBuildForm('node_tool_edit_...', Array, Object(Drupal\Core\Form\FormState))
#8 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(1076): Drupal\Core\Form\FormBuilder->doBuildForm('node_tool_edit_...', Array, Object(Drupal\Core\Form\FormState))
#9 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(1076): Drupal\Core\Form\FormBuilder->doBuildForm('node_tool_edit_...', Array, Object(Drupal\Core\Form\FormState))
#10 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(579): Drupal\Core\Form\FormBuilder->doBuildForm('node_tool_edit_...', Array, Object(Drupal\Core\Form\FormState))
#11 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(325): Drupal\Core\Form\FormBuilder->processForm('node_tool_edit_...', Array, Object(Drupal\Core\Form\FormState))
#12 /var/www/html/web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\node\NodeForm), Object(Drupal\Core\Form\FormState))
#13 /var/www/html/web/core/modules/layout_builder/src/Controller/LayoutBuilderHtmlEntityFormController.php(39): Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#14 [internal function]: Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#15 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#16 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#17 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#18 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#19 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#20 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#21 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#34 {main}

tonytheferg → created an issue.

tonytheferg → created an issue.

My mention of need in the UI was that it's needed in Commerce. That comment was not meant to be a critique of the patch. 😉👍

Most entities in the commerce ecosystem ship with a view for the list builder to be able to accomplish this type of thing OOTB. In those situations, this is still accomplished by a view, with VBO.

Shipping methods do not ship with a view because the list builder table is draggable allowing you to set the weights for how the shipping methods show up on the shipping information pane. See here.

So if you don't want that draggable table feature, I am assuming the recommended path would be to override the page with a view and VBO.
The other option is to expose the weight field, and edit that manually for every method, and sort your view by weight so that you can see the order that the shipping methods will display.

There is definitely something needed here in the UI.

I think this would be better to:

• Add this on the edit_form so that it doesn't clutter up the canonical.
• Also, maybe links.action instead of tasks.
• Also, maybe make use of ContentEntityConfirmFormBase

I added this functionality to my site by adding a links.action to the order edit_form.

Yes that's the only change

Posted a patch in ✨ Allow payments without orders to be deleted Needs review

tonytheferg → created an issue.

If anyone encounters this, you can stop the bleeding momentarilly by setting notranslate on the class for each element.

You can add this in a custom module in a hook_form_alter.

  if (strpos($form_id, 'views_form_commerce_cart_form_') === 0) {
    // Google Translate fix: Add notranslate class to all submit buttons on
    // Commerce cart form to prevent Google Translate from changing submit value,
    // which makes Drupal form no longer know what button was clicked because the action changed.
    $form['actions']['submit']['#attributes']['class'][] = 'notranslate';
    $form['actions']['checkout']['#attributes']['class'][] = 'notranslate';
    $form['actions']['empty_cart']['#attributes']['class'][] = 'notranslate';
    // Also for the remove buttons.
    foreach (Element::children($form['remove_button']) as $key) {
      $form['remove_button'][$key]['#attributes']['class'][] = 'notranslate';
    }
  }

This is a poor solution, but at least customers can checkout...