Een hart voor de Drupal Community

Thanks for the MR. Logic looks good to me. Only thing I'm wondering: couldn't we use a QueueWorker plugin to process the deletion of the stale log entries? Then we wouldn't need the batch processing logic within the cron hook. The processing time could be configured in the QueueWorker plugin - e.g. \Drupal\locale\Plugin\QueueWorker\LocaleTranslation has this set to 30 seconds.

Yeah I have set it up with "Details" wrapper currently. Would be good to allow for 1-click collapsing / expanding though, to easily switch between "editing" mode and "reordering" mode.

svendecabooter created an issue.

Problem/Motivation

We use custom_field to create multivalue fields, containing a bunch of properties / subfields. While this allows site editors to add rather complex multivalue data, it is a challenge for them to reorder the items, once created.

In some cases we are using modals for content editing, which makes it even more challenging.

Example:

A video of me trying to reorder the items for a custom_field field with a bunch of subfields, is available here: https://www.drupal.org/files/issues/2025-08-18/custom_field_reorder_issu...

For example the Paragraphs module seems to provide a better UX for this, with Collapse (all) / Edit (all) buttons:

By default the editing experience would be similar, with all fields exposed:

Clicking "Collapse all" gives us the following:

This allows for easy reordering, and subsequently editing a specific item.

MR created

Problem/Motivation

It's possible a referenced paragraph does not exist, resulting in a WSOD with this error: Error: Call to a member function createDuplicate() on null in Drupal\layout_builder_at\Plugin\Field\FieldWidget\LayoutBuilderCopyWidget->cloneEntity() (line 344 of /.../web/modules/contrib/layout_builder_at/src/Plugin/Field/FieldWidget/LayoutBuilderCopyWidget.php).

Steps to reproduce

I'm not sure how this came to be, but one of our nodes had a block with a referenced paragraph that doesn't seem to exist.

Proposed resolution

Lines 338 to 344 of the LayoutBuilderCopyWidget contain this code:

          $values = $clone->get($definition->getName())->getValue();
          if (!empty($values)) {
            foreach ($values as $value) {
              /** @var \Drupal\Core\Entity\EntityInterface $reference */
              /** @var \Drupal\Core\Entity\EntityInterface $reference_clone */
              $reference = \Drupal::service('entity_type.manager')->getStorage($target_type)->load($value['target_id']);
              $reference_clone = $reference->createDuplicate();

I would suggest replacing it with:

          /** @var \Drupal\Core\Entity\EntityInterface[] $references */
          $references = $clone->get($definition->getName())->referencedEntities();
          if (!empty($references)) {
            foreach ($references as $reference) {
              $reference_clone = $reference->createDuplicate();

This ensures only existing references can be cloned, and `createDuplicate` can't be called on a null-value.

Remaining tasks

I'll create a patch/MR

User interface changes

N/A

API changes

N/A

Data model changes

N/A

randalv created an issue. See original summary.

Module purpose

This module provides a Drupal-sauce around the gotenberg/gotenberg-php package, with basic configuration and a wrapper class to be used within Drupal.

It also adds an 'entity_print'-plugin that uses Gotenberg as the printing back-end.

For more information regarding Gotenberg, please visit their website and documentation Website: https://gotenberg.dev Documentation: https://gotenberg.dev/docs/getting-started/introduction

Alright, I've pushed some changes that should make it fully D11 compatible.

The biggest one was the constructor for the ConfigurationForm, in D11 an extra argument was required. To keep backwards compatibility, I've removed the constructor entirely and set the custom properties in the static create() method.

This has the added advantage that any future changes to the constructor will be fully handled by the parent create() method, and we can simply set our own custom properties without having to worry about that.

Other than that, only a version requirement change was needed in composer & info.yml.

randalv created an issue. See original summary.

Let's get this module ready for D11 :)

A small fix in this patch: when checking whether the alias is unique, two faults were present in the code.

1. The REQUEST domain was used, not the ENTITY domain, this meant that with entity saves via CLI (e.g. drush), the domain context was always the main domain... So aliases for other domains were saved with `-0` or `-1` 2. When checking if the alias is reserved, the source was not given, meaning if the alias previously existed in the database with the current source then it's marked as 'reserved' even though it's not.

This latest patch solves all of that.

Fons added a comment on drupal.org: Admin toolbar height is not 100% since upgrading to Drupal 11.2

Sven Decabooter added a comment on drupal.org: Use Icon API for Navigation module integration

svendecabooter created an issue. See original summary.

Problem/Motivation

Since Drupal 11.2.x, the (experimental) Navigation module no longer shows and icon in the Navigation sidebar:

This seems caused by the fact that the navigation sidebar icons are added via the new Icon API now. In #3507687: Add Site settings menu to Navigation module content block we opted to add a default icon (same as for Configuration), and added it via CSS. This approach seems to no longer work in 11.2.x.

Steps to reproduce

- Install Drupal 11.2.x - Enable Site Settings module - Enable Navigation module - Check icon in the sidebar

Proposed resolution

- Use new Icon API to set the same icon as previously.

Tested patch as well, and works like a charm.

Sven Decabooter added a comment on drupal.org: Navigation sidebar + small viewport + big_pipe needs double click for action

Problem/Motivation

We encountered this issue after updating to Drupal 11.2.2. We are using the experimental navigation module, but when viewing the website in smaller view ports, the sidebar expand / collapse toggle + close button doesn't seem to react the first time they get clicked. On a subsequent click, the action is triggered.

See attached video for an example.

Since we encountered this issue on a website with a bunch of customizations and contrib modules, I tried to reproduce the behavior by checking a Drupal core 11.2.x development branch and installing a clean instance. At first I couldn't reproduce this, but after trying to pinpoint the culprit by disabling specific JS files on my client website, I narrowed it down to being related to big_pipe module.

Steps to reproduce

I was now able to reproduce the issue (see attached video) with the following configuration:

• Drupal 11.2.x dev branch checkout
• big_pipe module enabled
• DDEV config: webserver_type: apache-fpm (I had this set to nginx first and couldn't reproduce the issue with that webserver)

I don't know if this issue belongs in the navigation module component, or big_pipe. Adding it to navigation module for now + referencing it in a meta-issue for big_pipe related issues.

svendecabooter created an issue. See original summary.

I can confirm the fix in MR 12461 restores the height of the navigation sidebar.

Little use case where the patch did not help for me:

- layout_builder - layout_builder_at (for asymmetric LB translations) - added new boolean field to block - saved pre-existing block with that new boolean field (ticket or unticked)

This field was initially empty (not `['value' => 0]` but just non-existing), upon saving a block (even the default translation) I received the error mentioned in this issue because the value was "changed" (it changed from non-existing to `['value' => 0]`.

The solution for me was to simply turn on the "Hide untranslatable fields" checkbox on my block types, this did not impact the editor experience whatsoever in my case because with `layout_builder_at` the blocks are *cloned* into translations, they aren't translated, so even on node translations all the fields on the block are always visible because you're always editing the block's default translation.

Hope it helps someone.

I had the same error.

Applying and testing the code that is in the merge request (https://git.drupalcode.org/project/pathauto/-/merge_requests/91.patch) fixed it for me.

Thanks!

Looks good to me.

Problem/Motivation

The AI Translated text extractor plugins have been revamped in the AI module in branch 1.2.x. See #3531717: Add text extractor plugins for image, file, text_with_summary and link field types. As part of this effort, the asymmetric translation of Layout Builder has been included in the main LbTextExtractor plugin, to avoid having multiple plugins conflicting with each other for the same field type.

This means this module will no longer be needed when using AI 1.2.x.

Proposed resolution

* Update composer.json to indicate this module requires ai 1.0.x or 1.1.x, but not 1.2.x E.g. `"drupal/ai": "~1.0.0 || ~1.1.0"` * Update the project description, to indicate the module is no longer needed for AI 1.2.x onwards, since it has been included into the main AI package.

This seems like a useful feature, just passing the mapped value along to the field setter should work fine.

Drupal's entity_reference field setters can handle all of the following input values just fine: - 13 - [13, 14, 15] - ['target_id' => 13] - [ ['target_id' => 13], ['target_id' => 14], ['target_id' => 15] ]

So I don't see any issues with this patch.

I tested the current MR, and this seems to work as intended. Maybe the Drupal logo color changing according to the environment indicator settings could be an option? Although from what I can see this is managed in CSS, so probably not very easy to make this configurable...

Sven Decabooter added a comment on drupal.org: Version identifier fallback source not used

Problem/Motivation

When the primary version identifier source cannot be retrieved, the fallback option is never shown.

Steps to reproduce

Set the configuration at /admin/config/development/environment-indicator as follows: - Source of version identifier to display: "Deployment identifier" - Fallback source of version identifier to display: "Drupal version"

Make sure there is no deployment identifier configured anywhere. This should show the Drupal version, but shows nothing at all.

svendecabooter created an issue. See original summary.