Switching on aggregation generates fatal "Column not found: 1054 Unknown column" SQL error when using multi-column Fields

It's trying to find a field field_officer_contact_form_ on the contact form entity. Does this exist? Is this an entity reference field to a contact form entity or something else? I'm just trying to get a feel of which parts of core are involved in this.

Maybe you can attach a yml export of this particular view config? That might help us identify the components involved in this.

@RKopacz well some clear steps to reproduce with a vanilla core install would be the best thing to get this moving. That way we can write some tests for this and fix this. Cause something is not right here, but what.

You say you have seen this multiple times, but was it always related to a view using the contact form in some way?

The same issue I faced, after some hours of digging I found that it is due to field aggregation settings. But this is not happening for all fields, only for field having multiple columns value like image having columns target_id, alt, title, height and width.

These are the steps to reproduce the issue:

1. Create new view for article or basic page
2. Add fields title, body and image
3. Then enable views aggregation

For now I solved by just saving the image field aggregation settings:

I know this is not a permanent solution. Will try to fix it and give a patch for the same.

Patch applies fine and it works, So making it RTBC. Would love to see what Core maintainers / View maintainer @dawehner says.

@manojapare nice work finding some steps to reproduce! Tested the steps and indeed there is an error when using an image field. A node ref didn't have any problems.

So if I understand correctly, the reason this happens is because there is no default value for the aggregation? And by saving the settings, a value gets set, and the problem goes away.

+++ b/core/modules/views/src/Plugin/views/field/Field.php
@@ -232,7 +232,7 @@ public function query($use_groupby = FALSE) {
+    if ($use_groupby && !empty($this->options['group_column'])) {

So this would mean that $fields doesn't get set and the call to $this->addAdditionalFields($fields); will add all additional fields.
Is there no way to set a proper default? Because defaulting to 8 fields getting added (in the case of an image field) to the query also doesn't sound great. And there is really no way to tell that this is happening other then looking at the query that was build.

Also this will need some tests.

Oh and this will need a separate patch for 8.3.x because the handler got renamed to \Drupal\views\Plugin\views\field\EntityField (but no need to worry about that yet)

@Lendude That's a good catch. Yeah as you commented $this->addAdditinalFields() adding all additional fields. So as per my observation to prevent it we need to make it run similarly when aggregation is not set.

Below patch will avoid adding all additional fields if group_column for the filed is not set.

In case of aggregation not set and multiple value field, if ($this->add_field_table($use_groupby) && !empty($this->options['group_column'])) condition statements won't be executing. But those need to be executed in the same case

@rakesh.gectcr Thanks for the quick review.

Please review the latest patch.

I can confirm that the work around of editing the Image's aggregation settings will fix the problem.

But I tried to apply patch #16 but fails to apply.

$ git apply -v 2815881-16.patch
Checking patch core/modules/views/src/Plugin/views/field/Field.php...
error: while searching for:
      unset($fields[$entity_type_key]);
    }

    if ($use_groupby) {
      // Add the fields that we're actually grouping on.
      $options = array();
      if ($this->options['group_column'] != 'entity_id') {

error: patch failed: core/modules/views/src/Plugin/views/field/Field.php:232
error: core/modules/views/src/Plugin/views/field/Field.php: patch does not apply

As 8.2.x is no longer in development, upping the version to 8.3.x and adding "Needs reroll" tag.

@john-cook The patch is failling to apply on 8.3.x branch beacuse Drupal\views\Plugin\views\field is been deprecated and instead we need to use Drupal\views\Plugin\views\field\EntityField.

Please find and review the rerolled patch for 8.3.x branch.

I've tested patch #18 against 8.4.x.

The patch does prevent the SQL error from appearing.

Before:

After:

I cannot see any problems with the code.

I would set this to RTBC but there still needs to be a test created to ensure that this isn't reverted. Because of this I'm setting this back to Needs work but removing the Needs re-roll tag.

Tidied issue summary.

I don't have any experience in writing test in Drupal. Can someone guide me or give documentation on how to write tests.

Here is a rather clumsy (but effective, nonetheless) pair of tests for the proposed change. This should at least give you something to start from.

Thanks Jo Fitzgerald this one is very useful to start with PHPUnit.

I am changing the status to `Needs work` because in unit test one more condition in add_field_table need to be covered.

I have written unit test for covering the missed condition in add_field_table method to ensure that this scenario is handled in future as well. Once again thanks to Jo Fitzgerald.

Please review it.

I like the test coverage here, but still not convinced by the fix. To me, the underlying problem is that apparently no default gets set in \Drupal\views\Plugin\views\field\EntityField::defineOptions. Why doesn't the image field/entity ref get a default?

This fix leads to all columns getting added, which might be nice as a last resort, but for a frequently used field type we need to look at getting the right default too I feel.

@Lendude, Thanks for reviewing the patch. I too wondered the same question: Why doesn't the image field/entity ref get a default?

These are my findings for the same:

1. In \Drupal\views\Plugin\views\field\EntityField::defineOptions all column names are been obtained from field storage definition.
2. $default_column is been determined by this code,
   

   // Try to determine a sensible default.
       if (count($column_names) == 1) {
         $default_column = $column_names[0];
       }
       elseif (in_array('value', $column_names)) {
         $default_column = 'value';
       }

3. Using $default_column only $options['group_column'] is been set as
   

   $options['group_column'] = array(
         'default' => $default_column,
       );

In case of normal fields say node title, $column_names = ['value']. But in case image field, $column_names = ['target_id', 'alt', 'title', 'width', 'height']. Hence for image/entity ref $default_column will be empty string which in-turn causes the problem.

I even tried just changing the code for determining default column in \Drupal\views\Plugin\views\field\EntityField::defineOptions like below:

   // Try to determine a sensible default.
    if (in_array('value', $column_names)) {
      $default_column = 'value';
    }
    elseif (count($column_names) >= 1) {
      $default_column = $column_names[0];
    }

which will set default_column for any field having additional fields. But this is also not solving the issue.

Let me know if this is not the way to debug or to fix it.

I would do something like this. This only works for fields that have been added after applying the patch, existing fields will have a empty default.
This will need an integration level test.

And depending on what we want to do here, it will also need an upgrade path to fix the existing field defaults. Optionally we can not do an upgrade path and let the existing fields use the fallback introduced here for fields that we can't determine a default column for. But I would say an upgrade path would be the way to go here.

@Lendude, This is working fine.

But still I am wondering, why even after setting default_column and hence options['group_column'] the error is been not fixed.

@manojapare because the default gets set when you add the field to the View. So any existing fields will already have the wrong default, but newly added fields will work with the new default.

New test. Test only patch only contains the new test and is the interdiff.

This still needs an upgrade path.

Upgrade path and test.

Quick cleanup.

Updated the I.S. to reflect the current fix.

+++ b/core/modules/views/src/Plugin/views/field/EntityField.php
@@ -344,13 +344,16 @@ protected function defineOptions() {
+      if (count($column_names) == 1) {
+        $default_column = $column_names[0];
+      }
+      elseif (in_array('value', $column_names)) {
+        $default_column = 'value';
+      }

Well, and otherwise choose the first available column?

Well, and otherwise choose the first available column?

Sounds good, but then we can just 'else' to the first column if 'value' isn't found. So something like this.

8.3 version won't apply to 8.4, so 2 versions.

Missed a little cleanup.

1. +++ b/core/modules/views/src/Plugin/views/field/EntityField.php
   @@ -348,12 +348,12 @@
   -      if (count($column_names) == 1) {
   -        $default_column = $column_names[0];
   -      }
   -      elseif (in_array('value', $column_names)) {
   +      if (in_array('value', $column_names)) {
            $default_column = 'value';
          }
   +      else {
   +        $default_column = $column_names[0];
   +      }
   

Needs reroll because of #2776975: March 3, 2017: Convert core to array syntax coding standards for Drupal 8.3.x RC phase

Rerolled

Just a reroll, the world is still green.

And another reroll...

Added a test view from another issue to the 8.4.x version, duh! 8.3.x didn't change but re-uploading to keep them together

Another re-RTBC

Can we have before & after screenshots?

Please see before and after screenshots

I think we need to do a fix in Views::preSave() too. Similar to what we did in #2248983: Define the revision metadata base fields in the entity annotation in order for the storage to create them only in the revision table so views from a modules config/install or config/optional folder are fixed too? No?

There's really nice test coverage on this patch.

I think we need to do a fix in Views::preSave() too.

@alexpott yes, you are of course correct.

Added a private function called in preSave(), the actual changes are done by that function when running post_update so the upgrade test covers both the post_update and the preSave()

now with the actual patch....

That is the 8.4.x version, will roll a 8.3.x version if this lands

Tested in 8.4.x branch, working fine and unit test and coverage looks fine. Marking as RTBC, even though found usage of 2 deprecated methods fixTableNames() and fixEmptyGroupColumn() in preSave () of View entity class.

Great work on the update path and tests!

I found something small that needs fixing here:

+++ b/core/modules/views/src/Entity/View.php
@@ -347,6 +348,50 @@ private function fixTableNames(array &$displays) {
+   * Fixes empty group columns.
+   *
+   * Some fields could be saved without a group column, this assures that every
+   * field has a default group column.
+   *
+   * @deprecated in Drupal 8.3.0, will be removed in Drupal 9.0.0.

Private and deprecated is a strategy I haven't seen before for an update helper. Seems reasonable. I guess fixTableNames() is the same.

However, we need to update the version here (not 8.3.0 anymore) and we should also add a @trigger_error() in the code path for it. (Probably just the top of the function.)

Queuing SQLite and PostgreSQL tests for this as well.

Updated the version, added the trigger_error, changed the update test to a BTB test

Queuing SQLite and PostgreSQL test for both 8.4.x and 8.5.x

@lendude Good job. Both patch for 8.4.x and 8.5.x applies fine and it is working fine. Making it RTBC.

Would like to see what Core maintainers says.

Needed another reroll, 8.4.x was still good, reupping to keep everything together

Both patch for 8.4.x and 8.5.x applies fine and it is working fine. Making it Re - RTBC.

1. +++ b/core/modules/views/src/Entity/View.php
   @@ -344,6 +345,51 @@ private function fixTableNames(array &$displays) {
   +   */
   +  private function fixEmptyGroupColumn() {
   +    @trigger_error(__METHOD__ . ' is deprecated in version 8.4 and will be removed before 9.0.0.', E_USER_DEPRECATED);
   +    /** @var \Drupal\Core\Entity\EntityFieldManagerInterface $entity_field_manager */
   

   I think the trigger_error() should not be at the top of the function since we always run it unconditionally. It's not actually deprecated code, it's a bc layer which is a bit different.

2. +++ b/core/modules/views/src/Entity/View.php
   @@ -344,6 +345,51 @@ private function fixTableNames(array &$displays) {
   +        foreach ($display['display_options']['fields'] as $field_name => &$field) {
   +          // Only update fields that have group_column set to an empty value.
   +          if (!empty($field['plugin_id']) && $field['plugin_id'] == 'field' && isset($field['group_column']) && empty($field['group_column'])) {
   +            // Attempt to load the field storage definition of the field.
   

   Instead shouldn't we put it here so it only runs when there's a View that needs fixing?

@catch,

Let me revamp the points to make sure I got your points. First of all, this method is been called for all view irrespective of view needs fixing or not. And this method is part of bc layer and not a deprecated one.

Based on the above point you are suggesting to trigger deprecation error only when the view needs actual fixing.

IMHO. Here the whole method is part of bc layer not just a part of it. So we need to trigger deprecation unconditionally all the time.

+++ b/core/modules/views/src/Plugin/views/field/EntityField.php
@@ -354,13 +354,16 @@ protected function defineOptions() {
+    // Try to determine a sensible default if none if provided by the field
+    // definition.
+    if (!$default_column) {
+      if (in_array('value', $column_names)) {
+        $default_column = 'value';
+      }
+      else {
+        $default_column = $column_names[0];
+      }
     }

Sorry for jumping in here so late, but are we sure this is needed? If a field type decides not to have a main property I think we should respect that. And since even before you can run into cases where $default_column is empty, I don't really understand why we do so much magic. Or is that precisely the bug here? (It's a bit hard to tell) If the latter is the case, I think we should at least drop the hardcoding of a "value" column and just always use the first one.

Re-rolled the patch for 8.5.x. Also made changes as per @tstoeckler suggestion.

Straight up rerolled #66 for 8.5.x. For some reason creating an interdiff was not possible so here is just the patch.

Anyone has tested it with rest views?.

I am facing a similar problem:

I have a rest view of a taxonomy term (books) and wants to add a contextual filter by the category. /books/drama. To do that, I add the relationship with the taxonomy term category and all the content get's duplicate. To fix it, I enable the aggregation but PUM! an SQL error.

Any idea?.

Drupal 8.6

I think I'm having this issue too with 8.6
SQLSTATE[42S22]: Column not found: 1054 Unknown column

- Nick

Let's get this one fixed, finally. Retesting the last patches, will then provide an interdiff and reroll against 8.6.x-dev.

First step: Here's the missing interdiff #66 -> #72, showing:

• that @tstoeckler's suggestion per #70 was honored
• that @catch's suggestion per #68 was ignored (and that's where all the test failures are coming from)
• some minor, yet distracting code reorganization

So here's another patch based on #66, yet taking into account both #68 and #70, and of course rerolled against 8.6.x-dev.

1. As suggested by @catch in #68, I'm moving the @trigger_error further into the code, so an error is only triggered when a field's 'group_column' is actually set to an empty value ('').
2. As suggested by @tstoeckler in #70, I'm removing the "magic 'value' column", instead always defaulting to the first column, if no main property is provided.
3. Some minor code refactoring, hopefully not all to distracting to reviewers, yet bringing the logic in line in both places.

Let's see if we can bring the number of test fails down again.

Nice. So here I'm fixing the rather new media view and a test view, and codesniffer's CS fix.
Now there shouldn't be more than a handful of test fails.

1.)
$display_name renamed to $display_id for clarity.

2.)

            $executable = $this->getExecutable();
            $executable->setDisplay($display_name);
            /** @var \Drupal\views\Plugin\views\field\FieldHandlerInterface $field_handler */
            $field_handler = $executable->getDisplay()->getHandler('field', $field['id']);

First thought we could get the handler for a particular display without setting and getting the display, but no we can't: #3034692: getHandler() != getHandler().

            /** @var \Drupal\views\Plugin\views\field\FieldHandlerInterface $field_handler */
            $field_handler = $this->getExecutable()->getHandler($display_id, 'field', $field['id']);

only gives me the handler configuration, not the actual handler object, so leaving everything as it is, except for the first two lines that can be chained.

3.)
This doesn't make any sense:

              $field_storage = NULL;
              if (isset($field['field']) && isset($field_storage_definitions[$field['field']])) {
                $field_storage = $field_storage_definitions[$field['field']];
              }
              // Use the field's main property as default column. If the field item does
              // not define a main property, use the first column as default column.
              $default_column = $field_storage->getMainPropertyName();
              if (empty($default_column)) {
                $column_names = array_keys($field_storage->getColumns());
                $default_column = $column_names[0];
              }

We can't do a getMainPropertyName() on NULL, neither can we do a getColumns() on NULL.
This is more correct:

              if (!isset($field['field']) || !isset($field_storage_definitions[$field['field']])) {
                continue;
              }
              $field_storage = $field_storage_definitions[$field['field']];
              // Use the field's main property as default column. If the field item does
              // not define a main property, use the first column as default column.
              $default_column = $field_storage->getMainPropertyName();
              if (empty($default_column)) {
                $column_names = array_keys($field_storage->getColumns());
                $default_column = $column_names[0];
              }

and hopefully enough.

4.)
Finally, following line was missing to make it all actually work:

              $field['group_column'] = $default_column;

Hope we got it right now. Let's have another test run to see how things turn out.

Straight reroll against 8.8. Interdiff didn't work, so here's a plain diff.

            $executable = $this->getExecutable()->setDisplay($display_name);
            $field_handler = $executable->getDisplay()->getHandler('field', $field['id']);

can't work. My fault, introduced in #84, now reverted.

Also replaced the deprecated getMock() by createMock() in the tests we're introducing to Drupal\Tests\views\Unit\Plugin\field\FieldTest.

-              if (!empty($field_storage) && $field_storage->getMainPropertyName()) {
-                $field['group_column'] = $field_storage->getMainPropertyName();
-              }
-              elseif (!empty($field_storage)) {
+              $default_column = $field_storage->getMainPropertyName();
+              if (empty($default_column)) {

Another incorrect change, again my fault, introduced in #80, now reverted:
We're only attempting to load the field's storage.

And following #3023981: Add @trigger_error() to deprecated EntityManager->EntityRepository methods, we need to replace $this->entityManager by $this->entityFieldManager and/or $this->entityTypeManager.
Now let's see if there's still something missing to make our bots happy... :)

Nice, only deprecation notices left, which may now be suppressed by @group legacy.
I'm also pushing our new deprecation notice to Drupal 8.7.x, as I don't see this being cherrypicked into Drupal 8.6.x anymore.

Tested green locally, so finally ready for review!

Hi! I don't know when it happens, but views don't display "list text" fields with enabled aggregation.

On Drupal 8.6.15 I ran into the above issue. But I couldn't find a working patch for this version. Could someone give me a hint which one to use?

#92 Patch Failed to Apply.

Patch rerolled.

When I apply the patch, Hunk #1 for the file core/modules/views/tests/src/Kernel/QueryGroupByTest.php failed at 3, but everything else applies cleanly and it seems to fix the problem for me. Using 8.7.6, which may be the reason it didn't all apply cleanly.

#97 worked for me! Thank you @vacho!

The patch from #97 does not apply to the 8.9.x branch. Another reroll is needed.

Added "novice" tag for the reroll.

I have reroll the patch #97. Hope, this will solve the issue.

This patch should fix the PHPLint Error.

This patch should fix the PHPLint Error.

Hi,

Anyone get success to install this patch?
If so someone can help me?
I'am installing this with composer

"extra": {
		"enable-patching": true,
		"patches" : {
			"drupal/core" : {
				"images aggregation": "https://www.drupal.org/files/issues/2019-07-26/2815881-97.patch"
			}
		},
}

After added that to my composer.json run command "composer install" and get an error:

"Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2019-07-26/2815881-97.patch"

I'm using #97 patch.

Or if anyone could solve this issue (image field with aggregation not working) with another solution please share.

Thanks in advance :)

Patch #97:

8.8.x: Patch Failed to Apply

Reroll from #97.

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because it looks like the test failures are pretty straightforward to fix.

Also I think the deprecation notices are out-of-date in the patch.

It would also be helpful to run the issue through the major issue triage process.

Tried to apply comment #110 patch, but it is not getting applied in 8.9.x branch. Patch applied successfully in 8.8.x branch. So updating the patch for 8.9.x branch. For 9.1.x branch there is mismatch of code in files. I will update patch for 9.1.x after it passes for 8.9.x branch.

adding fix for failed test case

Patch applied in Drupal9.1.x.

fix added for failed test cases.

Tested patch #21 with 9.1.x branch. Before applying the patch, I am able to reproduce the error on drupal 9.1.0-dev.

Before applying the patch I got the error.

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'node__field_image.field_image_' in 'field list': SELECT "node_field_data"."title" AS "node_field_data_title", "node__body"."body_value" AS "node__body_body_value", "node__field_image"."field_image_" AS "node__field_image_field_image_", "node_field_data"."created" AS "node_field_data_created", MIN(node_field_data.nid) AS "nid" FROM {node_field_data} "node_field_data" LEFT JOIN {node__body} "node__body" ON node_field_data.nid = node__body.entity_id AND (node__body.deleted = :views_join_condition_0 AND node__body.langcode = node_field_data.langcode) LEFT JOIN {node__field_image} "node__field_image" ON node_field_data.nid = node__field_image.entity_id AND (node__field_image.deleted = :views_join_condition_2 AND node__field_image.langcode = node_field_data.langcode) WHERE ("node_field_data"."status" = :db_condition_placeholder_4) AND ("node_field_data"."type" IN (:db_condition_placeholder_5)) GROUP BY node_field_data_title, node__body_body_value, node__field_image_field_image_, node_field_data_created ORDER BY "node_field_data_created" DESC LIMIT 11 OFFSET 0; Array ( [:db_condition_placeholder_4] => 1 [:db_condition_placeholder_5] => article [:views_join_condition_0] => 0 [:views_join_condition_2] => 0 )

After applying patch #121, it solves the problem. It works well and giving an output of view with aggregation without any error.

+++ b/core/modules/views/src/Entity/View.php
@@ -293,6 +293,9 @@ public function preSave(EntityStorageInterface $storage) {
+    $this->fixEmptyGroupColumn();

@@ -305,6 +308,97 @@ public function preSave(EntityStorageInterface $storage) {
+  private function fixTableNames(array &$displays) {
...
+  private function fixEmptyGroupColumn() {

We now have ViewsConfigUpdater available to store these methods on, so let's move them there.

+++ b/core/modules/views/src/Entity/View.php
@@ -293,6 +293,9 @@ public function preSave(EntityStorageInterface $storage) {
+    $this->fixTableNames($displays);

@@ -305,6 +308,97 @@ public function preSave(EntityStorageInterface $storage) {
+  private function fixTableNames(array &$displays) {

This got added in #117 but has nothing to do with this issue, this needs to be removed again.

patch #121 works for. After applying the patch not getting SQL error.

Fixed changes suggested in #123

@mohrerao now the upgrade path test is missing and my first point in #123 was not addressed at all

Removing the novice tag because this is not a novice task anymore.

For what's it's worth, we were having an issue with images columns as well... #8, way back in the thread above, worked for us. (Project we're on is Drupal 8.9.7; changing the aggregation on images solved the problem after our team had spent hours.)

@manojapare - thanks.

Addressing #123 based on the patch in #121.

Tagging "Bug Smash Initiative"

Sorry, forgot attaching the patch.

A patch for 9.1.x

Ignore the patches in #133 and #134 please.

Trying to address #123 based on the patch in #121 again.

+++ b/core/modules/views/tests/src/Functional/Update/EmptyFieldGroupColumnUpdateTest.php
@@ -0,0 +1,43 @@
+ * @see views_post_update_empty_entity_field_group_column()

Are we missing this update hook?

Thanks @jibran, It exists in #118, but got removed in #121

Added a patch for 9.3.x based on the latest MR.

Based this of the patch in #143

• The test was failing because a View got added to Umami that has an empty group_column. Fixed that.
• While fixing that found out that the update hook was only tailoring for 'field' not 'entity_field', fixed that and added coverage to the update test for that.
• As @jibran pointed out on the MR, the update itself should be much simpler if we use the power of ViewsConfigUpdater, did that, which is a lot of refactoring but looks much much cleaner now.
• Somewhere along the way, the update test View got a value added to 'group_column' so it wasn't actually testing anything anymore. Added a 'before' set of assertions to make sure we start with broken config.
• We are triggering a deprecation, which need a CR, so added a CR.

Tested patch #145 on Drupal 9.3.0 and seems to be working. Fixed the 1054 Unknown Column error I was seeing, for what it's worth.

Solved my problem with 9.3.9. After adding the image field, I had to go into the aggregation setting for the field and save it before the error went away.

Applied patch #145 and issue fixed

Before patch:

After patch:

Nice, hope this gets into core soon as this is really annoying bug

As per #146, #147 and #148, makring RTBC.

Let's hope we get this into core asap :)

Quick reroll

A broken view got added in #3173180: Add UI for 'loading' html attribute to images, hopefully this fixes it again.

We seem to hit the PHP 8.1 change for (mb_)strtolower(NULL) being deprecated: https://3v4l.org/fAUcN.

core/modules/views/tests/fixtures/update/views.view.group_column_post_update.yml doesn't have an uuid, which leads to this deprecation error:

Drupal\Tests\views\Functional\Update\EmptyFieldGroupColumnUpdateTest::testViewsPostUpdateEmptyFieldGroupColumn
Exception: Deprecated function: mb_strtolower(): Passing null to parameter #1 ($string) of type string is deprecated
Drupal\Core\Config\Entity\Query\Condition->compile()() (Line: 39)

when testing against PHP 8.1.
The same test passes with (for example) PHP 7.4

Unsure if we should address the whole (mb_)strtolower(NULL)) deprecation issue here, but if we add an uuid to the group_column_post_update View all seems to pass on PHP 8.1 and lower.

Also changed `Master` to `Default`.

Let's see if these changes please the TestBot Gods...

Green Testbot (after an initial JStest failure).

Putting this on NR, not back to RTBC because of:

Unsure if we should address the whole (mb_)strtolower(NULL)) deprecation issue here, [snip]

PHP 8.1 & MySQL 8 Patch Failed to Apply on D9.4

Added reroll of patch #157 on Drupal 9.4.x.

Thanks for the reroll! there is still a problem on the patch for the 10.1.x branch unfortunately.