🇺🇸United States @Amerie

This seems to be an issue on a fresh Drupal install.

Steps to reproduce:

1. Fresh install of Drupal 10.4.3
2. Enable the following modules:
   • Block
   • Database logging
   • Field
   • Field UI
   • Filter
   • Internal dynamic page cache
   • Internal page cache
   • MySQL
   • Node
   • System
   • Update manager
   • User
   • Views
   • Datetime
   • Text
   • Scheduler
3. Leave Scheduler settings same as they are by default on install
4. Create or edit an existing content type, check "Enable scheduled publishing...", and save
5. Add a node reference field to the content type and make it required
6. Set the form display widget for the reference field to "Select list"
7. Go to create a new node of the content type and attempt to save without filling out the reference field
8. When the page reloads with an error at the top about the required field, open the "Scheduling options" box and see that the "Publish on" date field has been automatically filled with the current date/time
9. If you fill out the reference field and attempt to save again, you will get an error about the "Publish on" date needing to be in the future.

From what we have found, this notice is generated any time a view page using facets is accessed with a key in the URL query string that doesn't correspond to a facet. For example if your view is example.com/view, if you go to example.com/view?key=value and "key" is not associated with a facet you have created, it will generate the "The core_views_facets module tried at least once to generically handle..." notice. We have been having issues with bot activity involving a whole bunch of nonsense in the query strings, which has been generating thousands of these notices. Would be nice to have an option to either skip the "generic" handling or at least suppress the notices, but I'm not familiar enough with the workings of this module to be able to figure out how to do that. Advice welcome!

Works great for me, thank you! Here is a patch for 3.0.3 if people need it for composer.

amerie → created an issue.

Just wanted to give a heads up that the problem reported by riskogab in comment #105 is still an issue with the latest patch (comment #189). Using a List (text) field with unlimited allowed values using the checkboxes widget as a Controlled By field does not work inside a paragraph, though other field types do, and it does work on a node.

We are using an entity autocomplete field in a custom form (not an entity edit form) and I couldn't find any info about how to use the views selection plugin in that situation so we just created our own selection plugin that extends the default one. Here it is in case anyone else needs it:

<?php

namespace Drupal\YOUR_MODULE\Plugin\EntityReferenceSelection;

use Drupal\Component\Utility\Html;
use Drupal\Core\Entity\EntityReferenceSelection\SelectionWithAutocreateInterface;
use Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection;
use Drupal\Core\Field\EntityReferenceFieldItemListInterface;

/**
 * Custom plugin implementation of the Entity Reference Selection plugin.
 *
 * @EntityReferenceSelection(
 *   id = "default_with_bundle",
 *   label = @Translation("Default (with entity bundle)"),
 *   group = "default",
 *   weight = 0,
 *   deriver = "Drupal\Core\Entity\Plugin\Derivative\DefaultSelectionDeriver"
 * )
 */
class DefaultWithBundleSelection extends DefaultSelection implements SelectionWithAutocreateInterface {

  /**
   * {@inheritdoc}
   */
  public function getReferenceableEntities($match = NULL, $match_operator = 'CONTAINS', $limit = 0) {
    $target_type = $this->getConfiguration()['target_type'];

    $query = $this->buildEntityQuery($match, $match_operator);
    if ($limit > 0) {
      $query->range(0, $limit);
    }

    $result = $query->execute();

    if (empty($result)) {
      return [];
    }

    $options = [];
    $entities = $this->entityTypeManager->getStorage($target_type)->loadMultiple($result);
    foreach ($entities as $entity_id => $entity) {
      $bundle = $entity->bundle();
      $entity_label = $this->entityRepository->getTranslationFromContext($entity)->label() ?? '';
      $bundle_label = $this->getBundleLabel($entity);
      $options[$bundle][$entity_id] = Html::escape($entity_label . ' [' . $bundle_label . ']');
    }

    return $options;
  }

  private function getBundleLabel($entity) {
    $label = '';
    if ($entity) {
      if ($bundle_field_name = $entity->getEntityType()->getKey('bundle')) {
        $bundle_field = $entity->get($bundle_field_name);
        if ($bundle_field instanceof EntityReferenceFieldItemListInterface) {
          $label = $bundle_field->entity->label();
        } else {
          $lable = $entity->bundle();
        }
      }
    }
    return $label;
  }

}

Amerie → created an issue.

Here is a patch version of the changes in #9 just in case anyone else needs it. :) Also I don't think it says anywhere (or I could have just missed it) but the argument needs to be given with a dash between the workflow name and the moderation state name (e.g. editorial-published).