🇨🇭Switzerland @tcrawford

I am working on a project where this issue has suddenly surfaced after a Drupal 11 update. I am also not sure why we have also redirect_fallback_action of NULL on most node types. To resolve, I have just opened the node type config and resaved.

Thanks for the feedback.
In best case, a redirect to the login page of another Drupal domain will result in the destination parameter being lost.
The domain access (and not just the domain source) module might be required to first trigger the 403.
That said, we also have other custom access and tac lite ( https://www.drupal.org/project/tac_lite → ) installed on the project, and I am not 100% sure they are also not required to reproduce (although looking at the stack trace suggests not).
I would have to test the scenario on a clean install, but have not yet had the possibility to do that.

tcrawford → created an issue.

We have the same symptom, but a slightly different cause and therefore MR87 does not work for us.
In our case, we have a custom form mode and $form['account']['pass'] is not set at all. Therefore, the check falsely identifies the password as being mutable.

$password_mutable = $form['account']['pass']['#access'] ?? TRUE;

I would suggest the check could be changed to the following, where we check if the pass field is even present and if so check the access to that. I would also reverse the order of the and as it is less expensive that way.

  $password_mutable = (isset($form['account']['pass']) && ($form['account']['pass']['#access'] ?? TRUE));

  // Load form if relevant.
  if ($password_mutable && \Drupal::service('password_policy.validation_manager')->tableShouldBeVisible()) {

The check also needs to be added to check if validation should run (otherwise we just don't show the table rows, but validation will still catch us). That possibly should be though in the PasswordPolicyValidationManager.

if ($password_mutable && \Drupal::service('password_policy.validation_manager')->validationShouldRun()) {
    $form['#validate'][] = '_password_policy_user_profile_form_validate';
    $form['#after_build'][] = '_password_policy_user_profile_form_after_build';
  }

I have created an MR. We are testing this (by using the issue fork as a composer repository, as drupal lenient can't be used due to the composer dependency). Therefore, I am moving this on to 'needs review'.

   "commerce_payrexx_integration": {
            "type": "package",
            "package": {
                "name": "drupal/commerce_payrexx_integration",
                "version": "2.0.1",
                "type": "drupal-module",
                "source": {
                    "url": "https://git.drupalcode.org/issue/commerce_payrexx_integration-3513451.git",
                    "type": "git",
                    "reference": "685b6c29d9946151be20e16355e674b3de2cde70"
                }
            }
        },

tcrawford → created an issue.

We had the same issue on a project. The above hint was very helpful. Thank you.
I wonder if the menu item recursion should not be checked during a cache clear to prevent such configurations getting into production.

I am re-assigning this as there are some minor issues with the view.

I have added the view for commerce product variations, adapted the derivative plugin and updated the view access tests. I am therefore assigning this one to 'needs review'. Thanks in advance.

@Jonathan1055: Sorry. I missed your prior message. I now have tests passing now. I just need to add the view and integrate this and consider whether to do the rules integration.

Thanks for the feedback on where to include the plugin.

But is there any benefit in putting it within a submodule of Scheduler which only gets enabled when required?

I would tend to suggest to leave it in the main module as it is consistent with the commerce product plugin.

Is this why you added 'language', 'locale' and 'config' to SchedulerBrowserTestBase here ?

Yes. I have removed these though as they were not required.

Hi @jonathan1055. Thanks for the feedback. I had not, but I just read the documentation.

If you would prefer the plugin for product variations to be stored in a third party module or is it a commonly used enough entity to be included here (perhaps due to its relation to the commerce product entity that it included)?

Unfortunately, I had some issues running these tests locally (the runner is complaining about missing dependencies that don't seem to be an issue on the server). I reached out to pfrenssen, who is a colleague, for some assistance and so if I can get the tests running locally I will save some resources on the server and be a bit faster.

Great idea, I will comment out data types (now that the prior tests are passing) to get feedback on the new entity type only.

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

The test pipeline failures appear to predate this change.

The automated patch that was merged in MR 3 unfortunately missed the composer dependency. I am fixing this now.

I created MR 16 (against 2.x) that also contains the changes to the info file. This needs a review.

This issue was created against 2.x and MR 15 does not apply against 2.x (only 1.x). MR 12 does not adapt the core version requirement. Therefore, I am placing this issue back to needs work. I suggest to create a separate issue for Drupal 11 compatibility for 1.x.

tcrawford → created an issue.

Thanks Milan. Much appreciated. I confirm the patch worked. We probably need to consider a sustainable fix here, such as making this optional.

I bumped in to the issue.
In our case we have a form display mode that does not have the name field present, which is a valid use case.
We have the MR from https://www.drupal.org/project/password_policy/issues/2451159 ✨ Password policy doesn't work when updating the user Needs work installed as a patch, but the issue can be reproduced without this and the patch resolves the issue regardless.
The name is actually already persisted on the entity.

Error:

```

Warning: Undefined array key "account" in /app/docroot/modules/contrib/password_policy/password_policy.module on line 243

Warning: Trying to access array offset on value of type null in /app/docroot/modules/contrib/password_policy/password_policy.module on line 243

Warning: Trying to access array offset on value of type null in /app/docroot/modules/contrib/password_policy/password_policy.module on line 243

Warning: Undefined array key "#default_value" in /app/docroot/modules/contrib/password_policy/password_policy.module on line 243
The website encountered an unexpected error. Try again later.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO "users_field_data" ("uid", "langcode", "preferred_langcode", "preferred_admin_langcode", "name", "pass", "mail", "timezone", "status", "created", "changed", "access", "login", "init", "default_langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array ( [:db_insert_placeholder_0] => 52200 [:db_insert_placeholder_1] => de [:db_insert_placeholder_2] => de [:db_insert_placeholder_3] => fr [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => $2y$10$O0rUbJ7ueExLy7vEmBfVp.oOv5Vzl1xnQM52SOyp8rsy2JK5RcD0W [:db_insert_placeholder_6] => sanitized@example.com [:db_insert_placeholder_7] => Europe/Zurich [:db_insert_placeholder_8] => 1 [:db_insert_placeholder_9] => 1737379851 [:db_insert_placeholder_10] => 1737473718 [:db_insert_placeholder_11] => 1737380061 [:db_insert_placeholder_12] => 1737380061 [:db_insert_placeholder_13] => sanitized@example.com [:db_insert_placeholder_14] => 1 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Drupal\Core\Database\StatementWrapperIterator->execute(Array, Array) (Line: 44)
Drupal\mysql\Driver\Database\mysql\Insert->execute() (Line: 1022)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToSharedTables(Object) (Line: 935)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doSaveFieldItems(Object, Array) (Line: 33)
Drupal\user\UserStorage->doSaveFieldItems(Object) (Line: 718)
Drupal\Core\Entity\ContentEntityStorageBase->doSave('52200', Object) (Line: 486)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 806)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 354)
Drupal\Core\Entity\EntityBase->save() (Line: 293)
Drupal\Core\Entity\EntityForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('user_pharmacies_form', Array, Object) (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 68)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 53)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 742)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```

Cause:
Function _password_policy_user_profile_form_validate(&$form, FormStateInterface $form_state) sets the name to an empty value if not found in the form.

Proposed solution:
As above. I am moving this back to needs review. Please consider again the prior proposed solution. https://www.drupal.org/files/issues/2023-01-12/3332884-integrity-constra... →

// set username if form_state name value is empty
if (empty($form_state->getValue('name'))) {
$user->setUsername($form_state->getValue('name', $user->name->value));
}

I have created a separate module with an event subscriber to set the checkout language on the order. The rational for a separate module is that it can be activated or de-activated, thereby avoiding the need for configuration. I use both the add to cart and checkout completion events (see the prior comment). I can create the module if you agree, otherwise, I can update the MR for core (with tests) if agreed.

<?php

declare(strict_types=1);

namespace Drupal\commerce_checkout_language\EventSubscriber;

use Drupal\commerce_cart\Event\CartEntityAddEvent;
use Drupal\commerce_cart\Event\CartEvents;
use Drupal\commerce_checkout\Event\CheckoutEvents;
use Drupal\commerce_order\Entity\OrderInterface;
use Drupal\commerce_order\Event\OrderEvent;
use Drupal\Core\Language\LanguageManagerInterface;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

/**
 * Sets the checkout language on the order.
 */
final class CommerceOrderLanguageSubscriber implements EventSubscriberInterface {

  /**
   * Constructs a CommerceCheckoutLanguageSubscriber object.
   */
  public function __construct(
    private readonly LanguageManagerInterface $languageManager,
  ) {}

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents(): array {
    return [
      CheckoutEvents::COMPLETION => ['onCheckoutCompletion'],
      CartEvents::CART_ENTITY_ADD => ['onCartEntityAdd'],
    ];
  }

  /**
   * Respond to the checkout completion event.
   *
   * @param \Drupal\commerce_order\Event\OrderEvent $event
   *   The order event.
   */
  public function onCheckoutCompletion(OrderEvent $event): void {
    // The checkout completion event requires the user to return to the checkout
    // after any offsite gateway.
    $this->setOrderLanguage($event->getOrder());
  }

  /**
   * Respond to the cart entity add event.
   *
   * @param \Drupal\commerce_cart\Event\CartEntityAddEvent $event
   *   The cart entity add event.
   */
  public function onCartEntityAdd(CartEntityAddEvent $event): void {
    // The cart entity add event is fired when a purchasable entity is added to
    // the cart. This is used as a default, which may be overridden by the
    // checkout completion event. We do this to ensure that the order language
    // is set even if the order is completed in the IPN (and the user does not
    // return to the checkout).
    $this->setOrderLanguage($event->getCart());
  }

  /**
   * Sets the order language to the current language.
   *
   * @param \Drupal\commerce_order\Entity\OrderInterface $order
   *   The order.
   */
  protected function setOrderLanguage(OrderInterface $order): void {
    $order->setData('checkout_language', $this->languageManager->getCurrentLanguage()->getId());
  }

}

I will also open an issue on the Drupal Symfony Mailer module (which includes the CommerceOrderEmailBuilder), which will include the following patch:

From 6cd4e1fbf60ad99d6673996b50fd0a5566fa5cb0 Mon Sep 17 00:00:00 2001
From: Trent Crawford <trent.crawford@liip.ch>
Date: Mon, 6 Jan 2025 14:47:35 +0100
Subject: [PATCH] Set the language based on the checkout language.

---
 .../CommerceOrderEmailBuilder.php             | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/src/Plugin/EmailBuilder/CommerceOrderEmailBuilder.php b/src/Plugin/EmailBuilder/CommerceOrderEmailBuilder.php
index 601cc8b..656833b 100644
--- a/src/Plugin/EmailBuilder/CommerceOrderEmailBuilder.php
+++ b/src/Plugin/EmailBuilder/CommerceOrderEmailBuilder.php
@@ -5,6 +5,7 @@ namespace Drupal\symfony_mailer\Plugin\EmailBuilder;
 use Drupal\commerce_order\Entity\OrderInterface;
 use Drupal\commerce_order\Entity\OrderType;
 use Drupal\symfony_mailer\Address;
+use Drupal\symfony_mailer\AddressInterface;
 use Drupal\symfony_mailer\EmailFactoryInterface;
 use Drupal\symfony_mailer\EmailInterface;
 use Drupal\symfony_mailer\Entity\MailerPolicy;
@@ -92,6 +93,27 @@ class CommerceOrderEmailBuilder extends EmailBuilderBase {
       ->setVariable('order_number', $order->getOrderNumber())
       ->setVariable('store', $store->getName());
 
+
+    // This is a workaround to set the email language based on the
+    // order checkout language.
+    if ($checkout_language = $order->getData('checkout_language')) {
+      // Calling setTo() above is still required to ensure we get the
+      // list of addresses.
+      $to_addresses = $email->getTo();
+      // In this case we likely only have one to address.
+      foreach ($to_addresses as $index => $to_address) {
+        if ($to_address instanceof AddressInterface) {
+          $to_addresses[$index] = new Address(
+            $to_address->getEmail(),
+            $to_address->getDisplayName(),
+            $checkout_language,
+            $to_address->getAccount()
+          );
+        }
+      }
+      $email->setTo($to_addresses);
+    }
+
     // Get the actual email value without picking up the default from the site
     // mail. Instead we prefer to default from Mailer policy.
     if ($store_email = $store->get('mail')->value) {
-- 
2.47.1

I will open an issue on commerce core with an MR:

From 344ef06b869b9535b2b558df380deb1146a0a5c7 Mon Sep 17 00:00:00 2001
From: Trent Crawford <trent.crawford@liip.ch>
Date: Mon, 6 Jan 2025 16:29:52 +0100
Subject: [PATCH] Send the email in the checkout language if available.

---
 modules/order/src/Mail/OrderReceiptMail.php | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/modules/order/src/Mail/OrderReceiptMail.php b/modules/order/src/Mail/OrderReceiptMail.php
index 67affa1e..ff0db9c7 100644
--- a/modules/order/src/Mail/OrderReceiptMail.php
+++ b/modules/order/src/Mail/OrderReceiptMail.php
@@ -43,6 +43,8 @@ class OrderReceiptMail implements OrderReceiptMailInterface {
     $order_type = $order_type_storage->load($order->bundle());
     $subject = $order_type->getReceiptSubject();
     if (!empty($subject)) {
+      // @todo Support token replacement in the checkout language.
+      // @see Drupal\commerce\MailHandler::changeActiveLanguage().
       $subject = $this->token->replace($subject, [
         'commerce_order' => $order,
       ]);
@@ -73,6 +75,11 @@ class OrderReceiptMail implements OrderReceiptMailInterface {
       $params['langcode'] = $customer->getPreferredLangcode();
     }
 
+    // Use the checkout language if available.
+    if ($checkout_language = $order->getData('checkout_language')) {
+      $params['langcode'] = $checkout_language;
+    }
+
     return $this->mailHandler->sendMail($to, $subject, $body, $params);
   }
 
-- 
2.47.1

I am welcome to any feedback on the approach.

The commerce email module will potentially also need an update for this.

I am not sure the checkout completion event is a reliable point in time to set the language, as order completion can occur in the IPN/webhoook and the user may not return to the site.

Order completion is also not reliable as the completion may occur in the webhook, where the language context is not available (as not all payment gateways provide a way to set the callback URL per order).

tcrawford → created an issue.

tcrawford → created an issue.

I am also seeing the issue periodically. Looking in the logs, I am currently not seeing "PluginNotFoundException" (although we have in the past in connection with this issue). What I am seeing is the out of memory issue. Therefore, I am linking this to the existing issue #3303674. I am not 100% positive they are related, but it provides context.

I seem to be having the same symptom. I am using symfony mailer lite. I suspect this is related. I will update if I find the cause.

tcrawford → created an issue.

The issue was caused by another module 'responsive_preview'.
Disabling this module resulted in the module working as expected.
Closing as 'cannot reproduce'.

tcrawford → created an issue.

tcrawford → created an issue.

tcrawford → created an issue.

tcrawford → created an issue.

This same issue occurs at other places. I will add some commits to the above MR.

I am just following up again on this issue, are you willing to work with me so I can help improve the module?

I am looking at a cleaner way to implement this, so re-assigning the issue to me.

I have added test coverage. Thanks in advance for a code review and community testing.

You can also user massageFormvalues() to set empty strings to null, which is the approach I took in a custom widget.

tcrawford → created an issue.

@mondrake You are right. The issue only occurs for me in projects using the drupal/rokka module, which uses its own RokkaToolkit that extends the GDToolkit. Rokka supports the svg extension, but there is no related type and so we see the type error.

  /**
   * Get the mime type.
   *
   * @return string
   *   Mime type.
   */
  public function getMimeType(): string {
    $mime_type = $this->getType() ? image_type_to_mime_type($this->getType()) : '';

    // GD library does not support SVG, but Rokka does. So we will trick the
    // toolkit and detect SVG as a mime time the first time the file is uploaded
    // to the tmp folder. If we detect an SVG image, we allow the upload.
    if (empty($mime_type)) {
      $uri = $this->getSource();
      if ($uri && file_exists($uri) && strpos($uri, 'rokka://') === FALSE) {
        $rokka_additional_allowed_mime_types = ['image/svg', 'image/svg+xml'];
        $mime_type_guessed = mime_content_type($uri);
        if (in_array($mime_type_guessed, $rokka_additional_allowed_mime_types)) {
          $mime_type = $mime_type_guessed;
        }
      }
    }

    return $mime_type;
  }

I guess we need to get have the Rokka Toolkit modified to override the load() method also and check that getType() is set.

I am closing this issue as 'cannot reproduce' as it only occurs in combination with the RokkaToolkit.

tcrawford → created an issue.

tcrawford → created an issue.

tcrawford → created an issue.

@jon.oltman. I have added some test coverage now, so assigning back to you. Thank you.

Thanks John. I am not sure we need the test to use the CRON. The CRON just runs a services to queue expired carts for deletion and the queue worker just uses the storage to delete them, so we could test by just deleting the carts programmatically. We can update the "steps to reproduce" to include "programmatically delete a cart" if you would like. I can write a test for that as time permits.

tcrawford → created an issue.

Hi. This fix works fine if an order item is deleted and the cart still exists. The fix does not work in a common use case where the order item is deleted in the postDelete of the order. This happens commonly when an abandoned cart is deleted via CRON. The issue is that the code tries to load the order to check if it is a cart (but can't as it was deleted) and therefore does not clean up the registration. Shall I re-open this issue or create a separate issue?

  // Delete registrations referenced by an order item being deleted from
  // a cart, unless the registration is already complete. There is a cart
  // subscriber that handles cart item removals, but modules can delete
  // items from a cart programmatically without invoking the cart manager.
  // @see \Drupal\commerce_registration\EventSubscriber\CartEventSubscriber
  elseif ($entity instanceof OrderItemInterface) {
    if ($order = $entity->getOrder()) {
      $is_cart = FALSE;
      if (!$order->get('cart')->isEmpty()) {
        $is_cart = $order->get('cart')->getValue()[0]['value'];
      }
      if ($is_cart && !$entity->get('registration')->isEmpty()) {
        $registrations = $entity->get('registration')->referencedEntities();
        foreach ($registrations as $registration) {
          if (!$registration->isComplete()) {
            $registration->delete();
          }
        }
      }
    }
  }

tcrawford → created an issue.

Reviewed and the change looks safe. Thanks.

The issue was fixed here: Issue #3137498 by tBKoT: Unable to unpublish a product variation.

I think this issue is stale and can be closed as the product variation translation annotation now points to Drupal\commerce_product\ProductTranslationHandler instead of the original content translation handler.

tcrawford → created an issue.

Please note that the patch should be applied upstream to the code base, otherwise every customer who installs the module will encounter this error and need to search the queue and then apply the patch to their project. Please advise if you intend to do this. If you need a merge request for this, please let me know and I am happy to open one. I am reopening this issue as it does not appear that the fix has been applied to the code base.

I have rerolled #60 as #66 (against 10.2.x) and this applies for me properly. I hope that helps if someone else was having an issue with #60. I am sorry that I have not yet been able to otherwise move this issue forward.
→

The above issue with the TypeError is coming as the second diff in patch #60 did not apply properly on one of our projects (and weirdly failed silently both locally and in the pipeline). Applying the second diff manually works. There appears to be an issue with patch #60 in that case and it would be good if someone else can verify. I have never seen a patch partially apply and fail silently and therefore suspect there is an issue on our side.

diff --git a/core/modules/system/src/Controller/EntityAutocompleteController.php b/core/modules/system/src/Controller/EntityAutocompleteController.php
index a49da37340..fd597a3947 100644
--- a/core/modules/system/src/Controller/EntityAutocompleteController.php
+++ b/core/modules/system/src/Controller/EntityAutocompleteController.php
@@ -77,6 +77,7 @@ public static function create(ContainerInterface $container) {
    */
   public function handleAutocomplete(Request $request, $target_type, $selection_handler, $selection_settings_key) {
     $matches = [];
+    $target_types = explode(',', $target_type);

     // Get the typed string from the URL, if it exists.
     if ($input = $request->query->get('q')) {
       $tag_list = Tags::explode($input);
@@ -109,8 +110,12 @@ public function handleAutocomplete(Request $request, $target_type, $selection_ha
           }
         }
       }
-
-      $matches = $this->matcher->getMatches($target_type, $selection_handler, $selection_settings, $typed_string);
+      foreach ($target_types as $t_type) {
+        $target_matches = $this->matcher->getMatches($t_type, $selection_handler, $selection_settings, $typed_string);
+        if ($target_matches) {
+          $matches = array_merge($matches, $target_matches);
+        }
+      }
     }

     return new JsonResponse($matches);

I am seeing a type error in SelectionPluginManager as getSelectionGroups does not return an entry for the concatenated entity entity type ID of 'node,taxonomy_term'.

The website encountered an unexpected error. Try again later.

TypeError: uasort(): Argument #1 ($array) must be of type array, null given in uasort() (line 65 of core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionPluginManager.php).

Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getPluginId('node,taxonomy_term', 'default') (Line: 41)
Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getInstance(Array) (Line: 41)
Drupal\Core\Entity\EntityAutocompleteMatcher->getMatches('node,taxonomy_term', 'default', Array, 're') (Line: 118)
Drupal\system\Controller\EntityAutocompleteController->handleAutocomplete(Object, 'node,taxonomy_term', 'default', '3kwQYPisvvlkGtu1zMaBQotUMioVXxI_qWM7KjOEK2w') (Line: 25)
Drupal\realname\Controller\RealnameAutocompleteController->handleAutocomplete(Object, 'node,taxonomy_term', 'default', '3kwQYPisvvlkGtu1zMaBQotUMioVXxI_qWM7KjOEK2w')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 53)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This is on Drupal 10.2.5 (PHP 8.1) with patch #60 applied.