Een hart voor de Drupal Community

Afterburner is a performance module for Drupal that brings true concurrency to background and queue processing. It integrates Spatie’s Async library to process tasks in parallel PHP workers, both during the Terminate event and within queue systems.

Why Afterburner? Drupal’s native queue system and terminate hooks are sequential — they process one item at a time or run within a single PHP request. Afterburner adds a layer of asynchronous concurrency, enabling heavy post-response or queue workloads to execute in parallel, without blocking user-facing requests.

Problem/Motivation

The current workflow with the upstream la_eu repository, as well as our Dropsolid hosting-specific repository is a bit difficult to follow, at least in my head. So we should document the current state, to make sure everyone can understand how it's set up.

Problem/Motivation

When the option "Automatically show Groups in the admin menu" is selected, a menu item is added for each Group, linking to the Site Settings entity listing, with the "Group" exposed filter prefilled.

The prefilled value is the Group ID, but the produces an error when clicked:

Example:

When the group name is used in the URL, instead of the ID, this works again: /admin/content/site-settings?group=Company+information

Problem/Motivation

Followup from issue #3541876: Allow collapsing / expanding of multivalue items:

Furthermore it would be nice if we could optionally select a (text) property of the custom_field field that functions as the details label, instead of Item (1), Item (2), etc...

Proposed resolution

- In the form widget settings, add an optional setting to select the property whose value should be used as the details wrapper label - This setting is only shown when the "Details" wrapper is selected - The setting shows a select list of properties available on that custom_field field - probably only string values should be in that list - If selected, some Javascript code should be added to the widget form, which copies the text from the selected property and uses it as details label. When the text of the selected property changes in the form, the details label should be updated. The text should probably be sanitized and have a maximum length set (if too long, append "..." at the end?)

Glad to read the fix works!

No idea why the test in the MR failed.

Thanks for the patch.

Fons added a comment on drupal.org: Fatal error: Declaration of Drupal\webform\EntityStorage\WebformEntityStorageTrait::__get($name) must be compatible with Drupal\Core\Entity\ContentEntityStorageBase::__get(string $name): mixed

Oops, like we cross posted.

Also fixed it here:

https://www.drupal.org/project/webform/issues/3556348

f0ns created an issue. See original summary.

Problem/Motivation

I just upgraded to Drupal 11.2.6 and I get the following errog:

Fatal error: Declaration of Drupal\webform\EntityStorage\WebformEntityStorageTrait::__get($name) must be compatible with Drupal\Core\Entity\ContentEntityStorageBase::__get(string $name): mixed

Had to shuffle some code around to make it reusable

Aside from having the bulk update form, we needed a Drush script for a customer.

bceyssens created an issue. See original summary.

The HTMX Extras module adds some lazy loading functionality to your website.

Currently, these elements are implemented:

• Lazy load entity: A template to lazily load an entity render
• Lazy load route: A template to lazily load the contents of a given route
• Search API lazy load row plugin: Renders your views lazily when they're revealed in the viewport (completely customizable, uses the "Lazy load entity"-template)

More functionality will be added once the need arises, feel free to create a ticket if you have a use case that could fall under this module's scope.

For replacing Drupal's AJAX API with HTMX, we gladly refer to the excellent HTMX-project

I have it running on 3 websites in production and all is well (it's also a minor change) so I've changed the status to reviewed & tested.

Would love to get this change in so I can get rid of the patches.

Thanks in advance!

Fons added a comment on drupal.org: The highlight js code runs on all code blocks

Problem/Motivation

I tested the upcoming 11.3 functionality to export Drupal content to a directory. This with the purpose the import it again on other websites through recipes.

While #3532951: Support exporting content and its dependencies to a folder structure on disk and https://www.drupal.org/project/default_content/issues/3160146#comment-16... seem to imply that Layout Builder content export will be possible, this seems to be only half the case.

When I create a Layout Builder section that contains an inline block component, I would expect the block_content entity to be exported as well.

For this to work previously with the Default Content contrib module, I needed to apply several patches, including https://www.drupal.org/project/default_content/issues/3160146. I assume the logic in that patch was not moved over to the Drupal core default content system yet.

Since Layout Builder, inline blocks and default content export are all in core, it seems less acceptable to me that this wouldn't work out of the box.

Steps to reproduce

- Install Layout Builder and activate it for a content type - Create a new block type containing a field - Configure Layout Builder to allow adding that block type to a LB section on a test node - Export the test node (through php core/scripts/drupal content:export node [NID] --dir=../test_default_content --with-dependencies)

Example simple node with an inline LB block:

After exporting, I get the following file: test_default_content/node/4f651b20-2513-4a64-889d-1aa0e721f75b.yml

_meta:
  version: '1.0'
  entity_type: node
  uuid: 4f651b20-2513-4a64-889d-1aa0e721f75b
  bundle: page
  default_langcode: nl
default:
  revision_uid:
    -
      target_id: 1
  status:
    -
      value: true
  uid:
    -
      target_id: 1
  title:
    -
      value: 'Test page with an inline layout builder block'
  created:
    -
      value: 1760792440
  promote:
    -
      value: false
  sticky:
    -
      value: false
  path:
    -
      alias: /test-page-inline-layout-builder-block
      langcode: nl
  content_translation_source:
    -
      value: und
  content_translation_outdated:
    -
      value: false
  layout_builder__layout:
    -
      section:
        layout_id: layout_onecol
        layout_settings:
          label: ''
        components:
          558dca26-6728-4bb6-97e5-587cced0f198:
            uuid: 558dca26-6728-4bb6-97e5-587cced0f198
            region: content
            configuration:
              id: 'inline_block:test_block_type'
              label: 'Test block type'
              label_display: false
              provider: layout_builder
              view_mode: full
              block_id: '18'
              block_revision_id: '18'
              block_serialized: null
              context_mapping: {  }
            weight: 0
            additional: {  }
        third_party_settings: {  }

Note that the text "This text should be exported" is nowhere to be found. This would have to added to a test_default_content/block_content/558dca26-6728-4bb6-97e5-587cced0f198.yml file....

@loparev closing this one as well. I'll reopen or create a new ticket when needed.

Reapplied patch #15 to version 3.6

Apologies, the last patch missed some changes to the entity's interface.

Another possible edge case would be if one entity's field is translatable and the other isn't, then the one to many relationship should also be reworked so it updates all translations of the translatable entity rather than just the current translation.

I updated the MR to allow one-to-many translation relationships.

Randal added a comment on drupal.org: Incorrect behaviour with multi language site

I can reproduce the issue you're talking about, furthermore I also run into an issue where the values are added to the default translation of the corresponding entity.

I added a merge request that fixes these issues for me locally.

It: - Retrieves the translated version of the original entity, if it exists - Retrieves the translated version of the referenced (corresponding) entity, if it exists

This should also not affect untranslated fields, if the field is untranslated and you retrieve a translation of an entity, the values will just be saved to the default translation.

I also added a static patch of the MR in its current state.

randalv made their first commit to this issue’s fork.

Thank you!

It's a minor but important change.

All the best, Fons

You can see it in action on my live site here:

https://webhaven.io/documentation/theming/theme-structure

Hi @loparev,

The code still needs an improvement for translating locale strings, it's not an entity so context can't be send to Smartling. We receive this error in the logs: Failed to alter contextUrl= with the following message: The "default" entity type does not exist.

Maybe just check if the entity type exists? https://git.drupalcode.org/project/tmgmt_smartling/-/blob/8.x-9.x/tmgmt_...

Problem/Motivation

As a followup to #3549657: AI CKEditor: use prompt entities instead of custom configurations, I noticed the ai_ckeditor prompts are stored in global settings for the module. However, other settings (such as the selected provider) are stored in the AiCKEditor plugin settings, on a per filter_format basis.

Is there a specific reason for this? And is that reason still valid after prompts are stored as ai_prompt entities, rather than just textual prompts in config?

It might be interesting to store a reference to the selected ai_prompt entity on a per filter_format basis. That way, users can decide to provide alternative prompts, based on the filter format that is chosen.

Especially since the AI provider can also be changed per filter format, it seems logical you might want to provide a different prompt per filter format as well (e.g. to tailor it towards the selected AI provider).

@loparev, you are correct, we weren't using the new metatag_computed field. We're also looking in detail why the other fields are still there, but it should also be somewhere in our part of the configuration. I close the issue when we get this validated by our client. Thanks!

Fons added a comment on drupal.org: The highlight js code runs on all code blocks

Fons added a comment on drupal.org: The highlight js code runs on all code blocks