🇨🇿Czech Republic @kyberman

Thank you very much @jviitamaki,
I can confirm your simple patch fixes the "{{ getSender(message) }}" problem for me.
Best regards
Vit

Hi Eleo,
The D10-compatible release is now published.
Best regards
Vit

Hi, if anybody simply needs to export the "layout_builder__layout" field serialized value using a REST view (e.g. for migration), I created a little formatter with a combination of hook_entity_field_access_alter. Any feedback is welcome, thanks!

function YOUR_MODULE_entity_field_access_alter(array &$grants, array $context) {
  if ($context['field_definition']->getName() === 'layout_builder__layout'
    && $context['operation'] === 'view' && $grants[':default']->isForbidden()
  ) {
    $grants[':default'] = AccessResult::allowed()->inheritCacheability($grants[':default']);
  }
}

namespace Drupal\YOUR_MODULE\Plugin\Field\FieldFormatter;

use Drupal\Core\Field\FieldItemListInterface;
use Drupal\Core\Field\FormatterBase;
use Drupal\Core\Render\Markup;

/**
 * @FieldFormatter(
 *   id = "layout_builder_raw",
 *   label = @Translation("Layout Builder raw data"),
 *   description = @Translation("Display the Layout Builder raw data."),
 *   field_types = {
 *     "layout_section",
 *   }
 * )
 */
class LayoutBuilderRawFormatter extends FormatterBase {

  public function viewElements(FieldItemListInterface $items, $langcode) {
    $elements = [];
    $entity = $items->getEntity();

    foreach ($items as $delta => $item) {
      $elements[$delta] = [
        '#markup' => Markup::create(serialize($item->section)),
        '#cache' => [
          'tags' => $entity->getCacheTags(),
        ],
      ];
    }

    return $elements;
  }

}

Hi everybody!

For a very specific use case (e.g. a lot of nodes being updated at once), the queue processing shutdown could cause more trouble than leaving it workable and letting it process at least partially, I would say. In my case, CloudFlare API allows to purge 30 items at once, multiplied by 2000 possible requests daily. If the queue grows to over 100 000 items quickly, the purging process is stopped immediately. That means there are potentially around 60 000 items that could be processed before the CloudFlare API limit is exhausted.

The idea this patch brings is to never stop the queue processing, but instead, there is an error logged after the queue grows to 30 000 items, so there is time to recognize and fix the possible issue. Could you please review and comment on this?

This could be a settings/config/state/hook to override the default 100 000 items limit.
Another idea is to enqueue the item only if it doesn't exist yet. Any thoughts?

Thank you
Vit

smustgrave → credited kyberman → .

We should skip the JS form submit event if the element is invisible.
This could be useful e.g. when another payment method is used.
(patch for branch 8.x-1.x)

This is now fixed in the dev branch.