🇺🇸United States @cecrs

For those commenters that couldn't click in the input box after applying the patch, the toolbar might be at fault. My particular issue is after I open a modal from the toolbar. If I close the modal and reload the page, the input field works fine. (I'm using a custom module called account modal that opens the user/edit in a modal, including the link in the toolbar user menu.)

I ran into this issue too, as well as needing to apply the accordion checkout to a custom checkout flow that my site uses. I've added module configuration for both.

To configure: /admin/commerce/config/accordion

NB: In order to solve the issue with the template, I added a configuration to use/not use the default template. If checked, the module will use the details.html.twig provided by the module. If unchecked, Drupal will determine which template to use in the usual way, and this modules template will NOT be used. If you use this configuration, you MUST provide a custom template in your theme, that checks for the new accordion attribute, and selects a template accordingly.

It should look like so:

{% if attributes.accordion is defined and attributes.accordion == true %}
  < This is an accordion details pane. Insert the template code provided by the module here, it is needed for the module to work correctly. >
{% else %}
  {#
    For all other details elements, use the correct template. I copied the one from my base theme into my subtheme and renamed it to detailsDefault.html.twig to avoid namespace conflicts
  #}
  {% include '@mytheme/form/detailsDefault.html.twig' %}
{% endif %}

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

Adding a patch, WSOD when using Paypal Smart button in checkout. Let me know if you'd prefer a new issue for this.

@gwvoigt

Check out this issue: https://www.drupal.org/project/drupal/issues/3370930 🐛 Aggregation URL hashes should be built from normalized list of libraries Fixed

We were also still seeing problems with missing ckeditor5 toolbars, and it was caused by aggregate files not getting written to disk due to mismatched hashes. There isn't a patch for < D10, but it's minimal changes and easy to generate a patch for if you aren't on D10 yet. Appears to have resolved our issues.

Promises settle is deprecated (https://docs.aws.amazon.com/aws-sdk-php/v3/api/function-GuzzleHttp.Promi...), need to use Utils. Patch attached.

Uploading a new patch, the fastly_purger submodule has the same issue

Just leaving this here in case someone else runs into this for the same reason I did - I had a view with multiple exposed Term filters, and multiple relationships to the vocabularies. The Term filters were using the wrong relationship and that produced this error. I.e., view misconfiguration.

@Daniel

Possibly, I would suggest trying removing all except the minimal required config, clear cache see if it works. If it does, add things back one by one (clearing cache between each, natch) until it breaks. If not, the issue is somewhere else and my experience will be of no help... :P

Working example:

    $form['text'] = array(
      '#type' => 'text_format',
      '#title' => $this->t('Text'),
      '#format' => 'basic_html',
      '#default_value' => $this->configuration['text']['value'],
    );

Fwiw, I was getting these issues due to a malformed array in my custom template. (Specifically the default_value for a text_format field, which has to be $this->configuration['']['value'], not $this->configuration['']. No patches were necessary.

Just as an fyi, to render a formatted field in the twig template, you will need to use this format:
{% set descriptionFormatted = {
'#type': 'processed_text',
'#text': description.value,
'#format': 'basic_html',
}
%}

{{ descriptionFormatted }}