Een hart voor de Drupal Community

MR created

randalv created an issue. See original summary.

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

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.

Let's get this module ready for D11 :)

randalv created an issue. See original summary.

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

svendecabooter created an issue. See original summary.

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.

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

svendecabooter created an issue. See original summary.

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.

Renamed issue for clarity.

Adding a simple patch file to just restore the canonical link, to fix this issue via Composer patching workflow (only recommended for websites not using the flattened site settings loader obviously), while awaiting a more robust solution in the next release.

I have added a new MR now, to attempt to fix this issue. In the first commit, I just restore the canonical link for SiteSettingEntity.

In the second commit, I add a configuration setting to not render the site entity on its canonical link, but its edit form instead. I have added an option in the config form to disable this.

I'm not really sure why site settings shouldn't have a canonical view actually... When you use the revision system of that entity (by deselecting the config option "Hide the administrative advanced options"), it would make sense that you can view the latest revision of the entity + earlier revisions, for comparison. They are only viewable for people with the "view published site setting entities" or "view unpublished site setting entities" permissions...

I'm not sure what the exact issue with the flattened site settings loader is exactly, that causes an infinite loop, but there might be another way to fix that, rather than messing too much with the default Drupal entity link templates...

Can someone check if my solution that renders the edit form instead, fixes the flattened site settings loader issue? And could use some extra thoughts on whether the edit form rendering is a good idea to begin with...

We are encountering similar issues. Site settings entities are no longer translatable after #3522947: Remove the canonical route of the site setting entity type has been committed.

The translatability of an entity is checked by \Drupal\content_translation\ContentTranslationManager::isSupported(). This checks if there is a link template "drupal:content-translation-overview".

Looking into where this template is defined - \Drupal\content_translation\Hook\ContentTranslationHooks::entityTypeAlter, we see it is only defined after the following logical check: if ($entity_type->hasLinkTemplate('canonical')) {}

Which is now no longer the case.

I think the safest solution would be to restore the canonical route, and perhaps just load the entity "edit" form for that route?