🇨🇦Canada @rbrownell

This error baffles me. I understand that architecture is the normal solution, but it can't be if the business requirements of the project require timely and rapid updating of a large volume of nodes/pages.

Please correct me if I am wrong, but it is my understanding that queues are supposed to help prevent server crashing by regulating the volume of data being sent to whatever system is receiving it. This would presumably occur in smaller batches instead of all at once. The fact that the queue stops processing after reaching a certain threshold suggests to me that the queue is not really a proper queue that processes things in smaller batches, but rather a dumping ground which is then sent all at once. There's got to be a better way of handling this than just stopping everything. There are mechanisms that can be added to reduce servers from crashing based on data volume.

Renaming patch to better reflect this issue.

There is a minor issue with the automatically generated patch where some errors were being thrown that indicate an improper implementation of the normalize function in the BlockNormalizer class.

PHP Fatal error: Declaration of Drupal\rest_block_data\Normalizer\BlockNormalizer::normalize($object, $format = null, array $context = []) must be compatible with Drupal\serialization\Normalizer\ConfigEntityNormalizer::normalize($object, $format = null, array $context = []): ArrayObject|array|string|int|float|bool|null in /app/docroot/modules/contrib/rest_block_data/src/Normalizer/BlockNormalizer.php on line 22

I have attached an updated patch which addresses this.

There is a minor issue with the automatically generated patch where some errors were being thrown that indicate an improper implementation of the normalize function in the BlockNormalizer class.

Fatal error: Declaration of Drupal\rest_block_layout\Normalizer\BlockNormalizer::normalize($object, $format = null, array $context = []) must be compatible with Drupal\serialization\Normalizer\ConfigEntityNormalizer::normalize($object, $format = null, array $context = []): ArrayObject|array|string|int|float|bool|null in /app/docroot/modules/contrib/rest_block_layout/src/Normalizer/BlockNormalizer.php on line 46

I have attached an updated patch which addresses this.

Here is a patch for this issue as it occurs in Drupal 10.

I performed a brief test on this with Paragraphs and Media additional testing is required for other nested entity types.

Adding upgrade instructions for projects that are based on drupal/recommended-project.

Done. It was hard to not follow the existing Drupal Admin menu layout. I hope that if there are very large changes coming, we provide search out of the box to ensure that users can find what they are looking for.

I'm having similar issues. This is breaking a config-sync operation by indicating the configuration is out of sync that of my local file system. When I look at the differences, it appears that the latest version of Webform has replaced the `category` with the `categories` configuration. There doesn't appear to be a proper update routine that ensures the value contained within `category` is retained before it is changed.

I tested the patch in #2 on Drupal 10 running on PHP 8.1 and the warnings are gone. Recommend merging into code base.

Confirming that #4 works well and doesn't break an existing custom implementation of TBMM.

I have also reviewed and tested Patch #4 on an existing customized implementation of this module. I can confirm that this patch is functioning as expected on Drupal 9.5.9.

An in-depth description of the issue and the recommendation can be found on this comment 🐛 [warning] Trying to access array offset on value of type bool PluginBase.php:187 Needs work on a similar issue.

This is a very difficult issue to reproduce as it relies on a views plugin improperly defining one or more options.

Prior to Drupal 9.5, Views did not expect every options value to be an associative array. This particular error occurs when an option is defined in a Views plugin that has a Boolean value without being nested within an associative array with an item with the key default.

For example, in the most recent version of the Search API Location Views module (8.x-1.0-alpha3) an option with key require is defined within the defineOptions() function as:

$options['require'] = FALSE;

This does not follow the prescribed structure found in the PluginBase parent class which reads:

  /**
   * Information about options for all kinds of purposes will be held here.
   * @code
   * 'option_name' => array(
   *  - 'default' => default value,
   *  - 'contains' => (optional) array of items this contains, with its own
   *      defaults, etc. If contains is set, the default will be ignored and
   *      assumed to be array().
   *  ),
   * @endcode
   *
   * @return array
   *   Returns the options of this handler/plugin.
   */
  protected function defineOptions() {

In the example above the correct way of implementing this option is:

$options['require'] = ['default' = FALSE];

As a result of this, in order to resolve this situation, updates to the output of the offending Views plugin's defineOptions() functions should be made to follow the prescribed array structure instead of updating Drupal core.

Recommend changing issue status to Closed (won't fix).

rbrownell → created an issue.

rbrownell → created an issue.

rbrownell → created an issue.