@tonytheferg

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...

This is a nasty bug, as sites will have carts that can't proceed to checkout if they are translating the site.

Maybe just change this to:

    $shipments = [
      [
        'title' => $this->t('Shipment #1'),
        'items' => [],
      ],
    ];

Hey @TomTech, there is this, that could use fixed as well:
https://www.drupal.org/project/commerce_fedex/issues/3264329 →

It's simple. I have an even subscriber in place just to clean up after it.

Commerce Shipping titles the Shipment #1, etc

Yeah.
Well, it's present in 8.x-2.5 which was released in Jan 2023. I didn't chase it any farther back than that due to composer dependancies on my environment.

I think in my use case I can just set the Original amounts in my ES, and it works pretty well.

        $rate_number = $rate->getAmount()->getNumber();
        $new_number = $rate_number + $markup;
        $new_price = new Price($new_number, 'USD');
        $rate->setOriginalAmount($new_price);
        $rate->setAmount($new_price);

This works... Not sure what might break tho.

Maybe we could set the altered rates in data, so that we could use them, and then unset the data on refresh.

The more I think about this, (and I don't know the codebase that well) I think this needs to be fixed in the LateOrderProcessor. So that the $rate is passed to the $shipment_amount.

https://git.drupalcode.org/project/commerce_shipping/-/blob/8.x-2.x/src/...

It may be good to invoke the event in the test and make selections here between the two rates, and assert that the order summary reflects those changes:
https://git.drupalcode.org/project/commerce_shipping/-/blob/8.x-2.x/test...

Curious how much stuff blows up by not checking $should_refresh.

Have you tried views bulk operations?

Finding in my testing that the event rate alterations only apply if I comment out this section in the EarlyOrderProcessor.php:

      if (!$should_refresh) {
        continue;
      }

https://git.drupalcode.org/project/commerce_shipping/-/blob/8.x-2.x/src/...

tonytheferg → created an issue.

🎉
Is there a reason we can't opt into security coverage?

Cool. Thanks @TomTech!

I see you are grinding it out on FedEx. :) That's great!

I noticed the slow response times issue as well,
I agree that is needed as the requests are rather slow.

Another note, with the shipping method plugin:
https://git.drupalcode.org/project/commerce_fedex/-/blob/8.x-1.x/src/Plu...

We can use the config value as the #default_value on password form elements so that every time you edit the method you don't have to re-paste the password.
'#default_value' => $this->configuration['api_information']['api_password'],

Ok, production error it seems was from not having pricing options set under FedEx Options.

Maybe those checkboxes should be required.

Ok, so I enabled them all, and created new api keys.
Sandbox/test credentials were not working:
This was the response for test credentials:

FedEx response received.
(object) array(
   'transactionId' => 'APIF_SV_RATC_TxID607eddad-0918-4e6c-93c0-eef236e4568b',
   'errors' => 
  array (
    0 => 
    (object) array(
       'code' => 'REQUEST.MISMATCH',
       'message' => 'The response is unavailable for the request payload sent to this virtualized sandbox instance. Please use the exact request payload from API JSON Collection available for download through FedEx Developer Portal and try again.',
    ),
  ),
)

And this is the message I get with live/production credentials:

	FedEx response received.
(object) array(
   'transactionId' => 'a8593635-4162-40fd-a731-7aa28bbcb542',
   'errors' => 
  array (
    0 => 
    (object) array(
       'code' => 'REQUESTEDSHIPMENT.RATEREQUESTTYPE.REQUIRED',
       'message' => 'Rate request type is required. Please update and try again.',
    ),
  ),
)

There are 13 api's to choose from when creating a project. Do we know which ones we will need for Drupal?

format

Added documentation:
https://www.drupal.org/docs/contributed-modules/commerce-variation-add-o... →

new feature and spelling

Cool. Tests are better than they were before this issue.

Updated the documentation.

new feature, and spelling

Notes of interest on the logic behind the exclude parent feature:

When the parent is excluded, children are added to the cart, with no other vado data. So no discounts, no links to parent data, no sync data, and no combo id.
https://git.drupalcode.org/project/commerce_vado/-/merge_requests/17/dif...

The quantity for each child is multiplied off the parent order item to account for when a parent has more than one child:
https://git.drupalcode.org/project/commerce_vado/-/merge_requests/17/dif...

The parent variation price is excluded because the variation itself is excluded.
https://git.drupalcode.org/project/commerce_vado/-/merge_requests/17/dif...

tonytheferg → created an issue.

I found this to be more dependable:

    // Join the order table and skip all items from orders that are carts.
    $query->leftjoin('commerce_order', 'o', 'o.order_id = li.order_id');
    $query->addField('o', 'status', 'o_status');
    $query->condition('o.status', 'checkout_checkout', 'NOT IN');
    $query->condition('o.status', 'checkout_shipping', 'NOT IN');
    $query->condition('o.status', 'checkout_review', 'NOT IN');
    $query->condition('o.status', 'cart', 'NOT IN');

So basically, the issue was here setting the single group id as an $id_field_alias, was just returning one result, and preventing the array from being built for each result - since there is only one group.

Not sure the most dependable way to get the group_item ids off the view, and also, I think this would require the view to have a group item relationship.

Basically, the view works, but the result gets reduced to one result, I think somewhere here:
https://git.drupalcode.org/project/commerce_vado/-/blob/2.0.x/src/Plugin...

Ok, good start.

Now we just need to decide what rows and style options we need.

tonytheferg → created an issue.