# Problem/Motivation `LayoutBuilderHelper::getBlockTypeFields()` advertises a text format for every formatted text field (`text`, `text_long`, `text_with_summary`), but the value is hardcoded: ```php // Add text format info for text fields. if (in_array($definition->getType(), ['text_long', 'text_with_summary', 'text'], TRUE)) { $field_info['format'] = 'basic_html'; } ``` The same assumption is repeated in the `sections` input description of `SetEntityLayout` ("For text fields use {"value": "HTML content", "format": "basic_html"}") and in the README. This is the catalogue an agent relies on to fill in block fields, so it should reflect the site, not a default install. On many sites it does not: - **Per-field restrictions are ignored.** Formatted text fields have an `allowed_formats` field setting. A field restricted to e.g. `full_html` or `restricted_html` is still advertised as `basic_html`. - **The format may not exist.** `basic_html` is config shipped by the Standard install profile. Sites installed from Minimal or another profile, or that renamed/removed it, do not have it. - **User access is ignored.** Which formats may be used depends on the account's permissions. The account executing the tool (e.g. an OAuth-authenticated MCP client) may not be allowed to use `basic_html`, or may have a more appropriate default. Because the write path does not check the format, following the catalogue silently stores content in a format the field or user is not allowed to use, or in a non-existent format, which then renders through the fallback format. # Steps to reproduce 1. On a site with a block content type that has a `text_long` field, set the field's "Allowed text formats" to only `full_html`. 2. Call `get_layout_builder_blocks`. 3. The field is returned with `"format": "basic_html"`, a format the field does not allow. Alternatively, on a site without a `basic_html` format, the tool still advertises `basic_html` for every formatted text field. # Proposed resolution In `getBlockTypeFields()`, compute the format info per field, following the same logic core's `text_format` form element uses: - `allowed_formats`: the formats the current user can use (`$format->access('use', $account)`), intersected with the field's `allowed_formats` setting when that setting is not empty. - `format`: the suggested format, being the first entry of that list, in format weight order (equivalent to the user's default format when the field has no restriction). - If the list is empty, omit `format` and add a note that the current user cannot write to this field. Then remove the hardcoded `basic_html` from the `SetEntityLayout` input description and the README, and refer to the `format` / `allowed_formats` returned by `get_layout_builder_blocks` instead. The module supports `^10.3 || ^11`, so this should not rely on `FilterFormatRepositoryInterface` (new in 11.4), nor on `filter_formats()` / `filter_default_format()` (deprecated in 11.4). Loading `filter_format` entities sorted by weight and checking `use` access works on all supported versions. Enforcing the format when writing is out of scope here, and handled in a follow-up issue about inline blocks being saved without validation. # Remaining tasks - Implement and review. - Add kernel test coverage for: a field without restrictions, a field with `allowed_formats`, and a user without access to any allowed format. # User interface changes None. # API changes The `get_layout_builder_blocks` catalogue changes for formatted text fields: `format` now reflects the site and user instead of always being `basic_html`, and a new `allowed_formats` key lists the usable formats. `format` may be absent when the user has no usable format for the field. # Data model changes None. --- AI Assisted Issue: this issue was generated with AI assistance, but was reviewed and refined by the creator.