Een hart voor de Drupal Community

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!

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.

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!

Problem/Motivation

At the moment whenever a piece of code is wrapped in a code block the library is automatically used.

I don't think that's desirable.

You would want to have it fired on code block (pre code). But you also want to be able to add inline code like this in a text where you don't want to use this library.

Steps to reproduce

Add code blocks with and without pre around it and you'll notice the library is always fired.

Proposed resolution

Alter the JS so it's only fired on pre code.

f0ns created an issue. See original summary.

Problem/Motivation

In https://www.drupal.org/project/ai/issues/3549153 we changed the configuration schema for storing prompts in the ai_translate module. Instead of having the actual prompt text (default + prompt text per language) stored in configuration, we store a reference to an ai_prompt config entity.

I haven't tested yet if this will break this module, since it extends the ChatTranslationProvider from ai_translate. If it does break things, a fix will need to be implemented for support with the upcoming ai-1.2.0 stable release. If it does not break things, it might be good to alter the logic of this module, to also use ai_prompt entities, for consistency with the main AI module.

The fix doesn't apply anymore in the latest upgrade to Drupal 11.2.5, I'll look into it.

So the daily bucket works by reusing old jobs for new entity updates, the job items contain copied field values from the entity.

The issue we have is that we updated field configuration to be excluded from tmgmt translation, and it is still being send for translation by the daily bucket.

We had the issue with https://www.drupal.org/project/tmgmt/issues/3485924. The tmgmt module update got installed on 18/11/2024 and we experience this still today:

tmgmt_sources/JobID14167_en_en-US.xml:                                                    <span sl-variant="media-33808-metatag][0][tag" class="atom" id="bNTc0NDNdW21ldGF0YWddWzBdW3RhZw">meta</span>
tmgmt_sources/JobID14167_en_en-US.xml:                                                    <span sl-variant="media-33808-metatag][1][tag" class="atom" id="bNTc0NDNdW21ldGF0YWddWzFdW3RhZw">link</span>

It also causes issues with plugin IDs and rabbit hole (see screenshots), which breaks functionality completely. So we fixed our part but are still stuck with old cached data in the job items that get reused.

You mentioned that there should be a way to update the old job item data with new updated configuration/content. An alternative solution for the daily bucket would be to create a new job containing completely new job items, that would prevent the issue as well.

bceyssens created an issue.

bceyssens created an issue.

Similar to https://www.drupal.org/project/tmgmt/issues/3485924 but then for the fields create by rabbit_hole module.

Problem/Motivation

Add Gitlab CI integration, to better monitor code quality.