## Summary This occurs since the changes introduced by https://www.drupal.org/sa-contrib-2026-121 `TextExtractor::shouldExtract()` calls `access('view')` on every field, and core's `LayoutSectionItemList::defaultAccess()` returns `AccessResult::forbidden()` unconditionally, so `layout_builder__layout` fails that check for every account, including user 1 with `configure any layout`. The layout field is therefore dropped before `LbFieldExtractor` ever runs, and Layout Builder inline block content is never translated. The check was added in 1.3.2 and 1.4.1; the failure is silent, so translations come out with an empty or untranslated layout and nothing reports a problem. ## Steps to reproduce 1. Drupal 11 with `layout_builder`, `layout_builder_at` (or `layout_builder_st`) and ai_translate 1.4.1 or 1.3.2, each set up as its own documentation prescribes. For `layout_builder_at` that includes enabling translation on the layout field under *Configuration > Regional > Content Language*, which is a documented install step of that module. 2. Enable content translation for a content type and for the content block type used in layouts, and add a second language. 3. Create a node whose body content lives entirely in Layout Builder inline blocks. 4. Translate it from the Translate tab. Verifiable in isolation, without any AI provider: ```php $node = \Drupal::entityTypeManager()->getStorage('node')->load($nid); // FALSE for every account, including user 1: var_dump($node->get('layout_builder__layout')->access('view')); // No items with parents[0] === 'layout_builder__layout': var_dump(\Drupal::service('ai_translate.text_extractor')->extractTextMetadata($node)); ``` ## Expected result The translation contains the Layout Builder content, translated, in the shape the site's translation module calls for: - `layout_builder_at`: the translation gets its own layout with cloned inline blocks in the target language, carrying translated text. - `layout_builder_st`: the shared inline blocks each gain a target-language translation with translated text. ## Actual result The translation saves successfully and reports success, but the Layout Builder content is not translated. Both symptoms are silent: no message, no watchdog entry, no failure in the result object: - `layout_builder_at`: the translation is created with an **empty layout**. The page body is gone. - `layout_builder_st`: the shared inline block never gains a target-language translation, so the translated page renders the source text. ## Root cause `TextExtractor::shouldExtract()`, as of 1.3.2 and 1.4.1: ```php // Fields the acting account cannot view must not be sent for translation. if (!$entity->get($fieldName)->access('view')) { return FALSE; } ``` Core forbids that access for layout fields: ```php // core/modules/layout_builder/src/Field/LayoutSectionItemList.php public function defaultAccess($operation = 'view', ?AccountInterface $account = NULL) { // @todo Allow access in https://www.drupal.org/node/2942975. return AccessResult::forbidden(); } ``` `EntityAccessControlHandler::fieldAccess()` takes that as its `:default` grant and `processAccessHookResults()` lets forbidden win, so no module can grant it back with `hook_entity_field_access()`. Consequence: `extractTextMetadata()` returns no metadata for the layout field, so `LbFieldExtractor::setValue()` is never invoked, so inline blocks are never processed. The `^layout_builder_` entry in `shouldExtract()`'s `$supportedFieldNames` is now unreachable. ## Scope Affects both ways of translating Layout Builder overrides, and both currently supported releases. | | `layout_builder_at` 3.0.2 | `layout_builder_st` 2.0.0 | |---|---|---| | ai_translate 1.4.x | affected | affected | | ai_translate 1.3.2 | affected | affected | `layout_builder_st` is affected for the same reason: it leaves core's `LayoutSectionItemList` in place for `layout_builder__layout` (its own `LayoutTranslationItemList`, on the separate `layout_translation` field it adds, also returns `AccessResult::forbidden()`). The two modules cannot be installed on the same site, so each was verified separately, in its own documented configuration. ## Impact Any site combining AI Translate with Layout Builder inline blocks. Where page content lives in Layout Builder translations come out effectively empty, and nothing reports a problem. Both currently supported releases (1.3.2 and 1.4.1) are affected; the only releases without the check are the ones the security advisory covers, so downgrading is not an option. ## Why an exemption is safe here The check's intent is right: content an account cannot view should not be sent to a provider. But field access is the wrong test for a *structural container*. Core forbids `layout_builder__layout` because layouts are manipulated through section storage rather than as a field — an API decision, flagged `@todo Allow access in #2942975`, not a confidentiality boundary. No site can rely on it as one, because it is forbidden for everybody. `LbFieldExtractor::extract()` recurses with `$this->textExtractor->extractTextMetadata($blockEntity)`, which applies `shouldExtract()` — and therefore the same access check — to every field of every inline block. Measured on the affected site: | | result | |---|---| | `layout_builder__layout` (container) `access('view')` | forbidden for every account | | inline block entity `access('view')` | allowed | | each of the block's 9 fields `access('view')` | allowed | So exempting the container does not bypass any access check on real field data; the contained fields remain individually gated. ## Proposed fix A marker interface the extractor plugin opts into, mirroring the existing `ConfigurableFieldTextExtractorInterface` idiom so nothing changes for third-party plugins on a stable branch: ```php // src/ContainerFieldTextExtractorInterface.php interface ContainerFieldTextExtractorInterface extends FieldTextExtractorInterface {} ``` `LbFieldExtractor` implements it, and `TextExtractor::shouldExtract()` becomes: ```php // Fields the acting account cannot view must not be sent for translation. // Container fields are exempt: they hold no text themselves, and every // field of the entities their plugin recurses into is checked separately // by this same method. // @see \Drupal\ai_translate\ContainerFieldTextExtractorInterface if (!$this->plugins[$fieldType] instanceof ContainerFieldTextExtractorInterface && !$entity->get($fieldName)->access('view')) { return FALSE; } ``` `ReferenceFieldExtractor` recurses too but is deliberately **not** opted in: view access on an entity reference field is a permission decision a site can genuinely make, unlike `layout_section`, so it stays enforced. That distinction is the reason for opting in per plugin rather than exempting every recursing extractor. Alternatives considered: exempting the `layout_section` field type by name in `TextExtractor` (smaller, but no way for a contrib field type to opt in), or moving the access check after the plugin gate (does not help — the plugin is never reached). ## Environment - Drupal version: 11.4.6 on the affected site; reproduced on 11.4.5 - Module version: 1.4.1 and 1.3.2 - PHP version: 8.4 - Provider: not provider-specific — the failure happens before any provider call, and the automated reproduction stubs the translator - Last known working version: 1.4.0 (and 1.3.1 on the 1.3.x branch) ### Error messages or logs *(optional)* None. That is part of the problem: the translation reports success, and nothing is written to watchdog. ## AI Usage - [x] AI Assisted Issue — This issue was generated with AI assistance, but was reviewed and refined by the creator.