🇺🇸United States @joegl

Migrate Tools 6.1.0 was released yesterday which modifies the create method and introduces this error. Does #3410487 cover this entirely?

https://git.drupalcode.org/project/migrate_tools/-/blob/6.1.0/src/Drush/...

It added 3 new dependency injections.

Yes, ui_patterns_ds is enabled.

Sure, I've pasted it below. I did remove all the hidden fields from the hidden section and config dependencies to try to reduce the lines here.

Also it does sound like what I'm trying to do is supported in 2.x still, and something else could be preventing it from working? I can do some more troubleshooting on my own if that's the case but I wanted to confirm that functionality is intact in 2.x, because I got mixed results when looking it up,

langcode: en
status: true
dependencies:
  config:
    - core.entity_view_mode.node.org_card
    - field.field.node.org_news.layout_builder__layout
    - field.field.node.org_news.cm_news_featured_media
    - field.field.node.org_news.cm_news_publishing_date
    - field.field.node.org_news.cm_news_source
    - field.field.node.org_news.cm_news_topics
    - field.field.node.org_news.cm_ext_news_dek_long
    - field.field.node.org_news.cm_ext_news_news_source
    - node.type.org_news
  module:
    - datetime
    - ds
    - element_class_formatter
    - field_formatter_class
    - link
    - org_media
    - user
third_party_settings:
  ds:
    layout:
      id: 'ui_patterns:ext_profile_helper:news_vertical_teaser'
      library: null
      disable_css: false
      entity_classes: all_classes
      settings:
        label: ''
        ui_patterns:
          component_id: 'ext_profile_helper:news-vertical-teaser'
          variant_id: null
          props:
            attributes:
              source_id: attributes
              source:
                value: ''
          slots: {  }
    regions:
      news_vertical_teaser_image:
        - cm_news_featured_media
      news_vertical_teaser_headline:
        - node_title
      news_list_publishing_date:
        - cm_news_publishing_date
      news_topics:
        - cm_news_topics
      news_source:
        - cm_ext_news_news_source
      news_dek:
        - cm_ext_news_dek_long
      news_url:
        - 'dynamic_token_field:node-news_content_url'
      news_external_url:
        - cm_news_source
    fields:
      'dynamic_token_field:node-news_content_url':
        plugin_id: 'dynamic_token_field:node-news_content_url'
        weight: 6
        label: hidden
        formatter: default
      node_title:
        plugin_id: node_title
        weight: 1
        label: hidden
        formatter: default
        settings:
          link: false
          'link class': ''
          wrapper: ''
          class: ''
id: node.org_news.org_card
targetEntityType: node
bundle: org_news
mode: org_card
content:
  cm_news_featured_media:
    type: media_multimedia_formatter
    label: hidden
    settings:
      view_mode: default
      link: false
      image:
        image_formatter: responsive_image_style
        image_formatter_image_style: cta_2x_1014x676
        image_formatter_responsive_image_style: card_3_2
        image_formatter_view_mode: default
      video:
        video_formatter: entity
        video_formatter_view_mode: default
      other:
        view_mode: default
    third_party_settings:
      field_formatter_class:
        class: ''
    weight: 0
    region: news_vertical_teaser_image
  cm_news_publishing_date:
    type: datetime_default
    label: hidden
    settings:
      timezone_override: ''
      format_type: org_month_date_year
    third_party_settings:
      field_formatter_class:
        class: ''
    weight: 2
    region: news_list_publishing_date
  cm_news_source:
    type: link
    label: hidden
    settings:
      trim_length: null
      url_only: true
      url_plain: true
      rel: '0'
      target: '0'
    third_party_settings:
      field_formatter_class:
        class: ext-news-ext-link
    weight: 7
    region: news_external_url
  cm_news_topics:
    type: entity_reference_list_label_class
    label: hidden
    settings:
      link: true
      class: cm-list-unstyled
      list_type: ul
    third_party_settings:
      field_formatter_class:
        class: ''
      ds:
        ds_limit: '1'
    weight: 3
    region: news_topics
  cm_ext_news_dek_long:
    type: wrapper_class
    label: above
    settings:
      class: ''
      tag: div
      link: false
      link_class: ''
      summary: false
      trim: 200
    third_party_settings: {  }
    weight: 5
    region: news_dek
  cm_ext_news_news_source:
    type: entity_reference_label_class
    label: above
    settings:
      link: false
      class: ''
      tag: span
    third_party_settings:
      field_formatter_class:
        class: ''
    weight: 4
    region: news_source
hidden:
  layout_builder__layout: true

Yes I have the ui_patterns_layout module enabled. I am able to set up everything in the UI the same as in 1.x. The issue is that the HTML output isn't using the .twig template included with the SDC component. It could be something we have custom in the back-end but I had assumed this functionality was part of UI Patterns. Thanks for the response.

joegl → created an issue.

There's been a release today with a change to resolve the issue: https://github.com/PHPCSStandards/composer-installer/releases/tag/v1.1.1

I've added the patch and tested it. It is working as expected.

I changed the issue title to better align with the work you did here, although it may still need some tweaking.

Thanks Roderick -- this does look like exactly what we need. I agree this sounds like it should be the default behavior, but is it something that would fit as a toggle-able configuration option that's on by default?

I will see if I have time to test the patch today otherwise I'll have to wait until next week.

joegl → created an issue.

This is popping up in our PHPCS scans and typically only affects the user.mail.yml configuration after almost every configuration export. Because it does not cause any problems, we've chosen to ignore it in the PHPCS configuration:

<rule ref="Drupal.Files.EndFileNewline.NoneFound">
  <exclude-pattern>*config/sync/user.mail.yml</exclude-pattern>
</rule>

This might save others some grief / catastrophe in data loss. We recently had an issue where we uninstalled the allowed_formats module at the same time as the field configurations were updated to remove the module as a dependency. The order of the config import then went like this:

1. Import core.extension.yml (uninstalls allowed_formats module). Because the active configuration on the site still had allowed_formats as a dependency for the fields, it deleted those fields.
2. Update field configurations to remove allowed_formats as a dependency. Because the uninstalling of the module deleted the fields, this step actually re-created the fields.

This resulted in losing all the data for the fields. I would recommend making sure all the fields are correctly configured to not have the allowed_formats module as a dependency, and then uninstalling the module at a later time. Or write a database update to manually update the relevant field configurations as part of the deployment.

I added the conditional to the merge request and cut a new patch on 10.4.x

I ran into a unique fatal error caused by the patch. In short, the media entity being used to generate the edit link for the error message will not always be saved in the database, and will not have an ID or valid edit link. I recommend adding a condition to check if for the ID of the media entity before continuing.

In length, a content type with an oEmbed media entity will reference the media entity using an entity reference field. When using layout builder for the default display for the content type, the content preview for layout builder uses the generateSampleValue method on the entity reference item to generate a preview. The method attempts to find a random, valid entity to use as a sample value. If it cannot find one, it generates an entity on the fly. The entity generated on the fly is not saved, and does not have a valid ID. This throws a fatal error then when using this code because it attempts to generate an edit link on a media entity without an ID. I recommend adding a condition to check if for the ID of the media entity before continuing.

Perhaps there's a better way to go about this then adding a check for the $media->id().

I had same issue as #7 with Views Bulk Edit. Pasting the exact error here for google to index and hopefully help future users.

Error: Call to undefined method Drupal\views_bulk_operations\Form\ConfigureAction::getEntity() in field_formatter_class_field_widget_complete_form_alter() (line 142 of modules/contrib/field_formatter_class/field_formatter_class.module).

We used the "Overwrite Label" field on the settings for the On/Off checkbox widget in a content type form display, which added a dependency and wrote to the third_party_settings for the field_formatter_class field, even though we were not using it.

I also cut a new patch from the merge request, although geek-merlin's patch may end up being the correct way without the use of the additional conditionals.

I think this could be closed now? Looks like there's a stable release with security coverage.

Applied a patch from the Merge Request diff successfully to Drupal Core 10.3.13.

I reviewed the Merge Request in #2972846 first, but that issue does not add an access check before logging the error and does not appear to resolve the issue of this error showing to anonymous users. As another user commented in that issue, it appears the changes there are exposing even more detailed information to anonymous users which exacerbates the issue presented here.

Thanks! I've moved it to the forums: https://www.drupal.org/forum/support/installing-drupal/2025-02-20/optimi... →

joegl → created an issue.

Nevermind I figured this out. The Administrator and Anonymous roles had the relevant "View the config page type page entity" permissions enabled, but the Authenticated User role did not, and neither did any of the other roles.

Looks like the block access fix implemented in 2.17 is properly enforcing these permissions now.

joegl → created an issue.

Oh that's interesting. I'm going to attribute this to PIBKAC / user error then. Thanks!

joegl → created an issue.

I was directed to use the approach here instead of the patch in #3207813 . I don't see a patch in here and the merge request has quite a few changes. Is this ready for use on 10.3.x? It seems there's still some discussion on approach and the code looks like a work in progress.

Looking at the code committed for #3457863. It drops the array_intersect_key function which removed any themes that weren't in present in both arrays ($list and $installed_themes). The new code loops through $installed_themes array keys and then uses the value from the $list in the addTheme method. The error pops up when there is a theme in $installed_themes that's not in $list (and which would previously get removed via the array_intersect_key function). $installed_themes comes from the theme configuration in the core.extension.yml while the $list comes from a list of themes present in the codebase.

The patch catch provided adds a check to replace what array_intersect_key was doing.

However, the problem for sites encountering the error is most likely because the theme configuration settings in the core.extension.yml includes a theme which is no longer present in the codebase. This was the case for us.

Thanks #23 and #26 for the informative comments. I was able to implement the solution in #26 (second option outlined in #23) while leaving the Ignore Characters processer enabled for other characters outside of the troublemakers: "._-".

In the Ignore Characters configuration:
- Remove the "." from the Strip by Regular Expression field (change it to "['¿¡!?,:;]")
- Under the "Strip by character property" settings, uncheck the "Punctuation, Dash Characters" box (see https://en.wikipedia.org/wiki/Unicode_character_property for info here).
- If you're also worried about the underscores "_", uncheck the "Punctuation, connector" box as well.
This essentially keeps the "." and "-" intact (and "_" if you want).

Then as described in the Tokenizer configuration:
- Remove "._-" from the Ignore characters field (leave it blank)
- Add "._-" to the Whitespace characters field

For closure: We were able to resolve this internally and don't believe it was a problem with the module. It had to do with the a child theme pattern.

We cut a patch from the merge request and applied it a Drupal 10.2.7 multisite stack with about 100+ sites. During deployment about 20% of sites were losing home page content and content on a few other pages inconsistently with no determinable pattern. We do not have Memcache enabled. The patch resolved the issues we were having.

In logs, we noticed a few errors pop up during these deployments and perusing the issues queues they all seemed to point back to this issue, including:

Route "entity.path_alias.collection" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName()
Uncaught PHP Exception Error: "Call to undefined method Drupal\Core\Entity\Entity\EntityViewDisplay::isLayoutBuilderEnabled()

I understand the methodology here isn't ideal, but it was a critical issue to resolve for us.

This may be the wrong place for this (apologies if so).

The change record and documentation state Drupal 10.2.0 plugins should start using attribute-based instead of annotation-based plugins, but the core plugins don't actually support attribute-based discovery until 10.3.x. Can there be more clear documentation stating it's not well-supported yet until 10.3.x?

Relevant links:
- https://www.drupal.org/node/3403921 → (10.2)
- https://www.drupal.org/node/3395575 → (10.2)
- https://www.drupal.org/node/3229001 → (10.3)

If an update hook is going to install a module, the module should probably be included as a composer dependency. A failed update (even due to a deprecation) isn't the way.

Also, if there is a a deprecation, it'd be great to have the notice and steps to upgrade in the release notes for the release.

6.0.4 does not fix this issue. Our custom plugin which extends Drupal\migrate_plus\Plugin\migrate_plus\data_parser\Json::getSourceData is still broken:

PHP Fatal error: Declaration of Drupal\CustomJson\Plugin\migrate_plus\data_parser\CustomJson::getSourceData(string $url): array must be compatible with Drupal\migrate_plus\Plugin\migrate_plus\data_parser\Json::getSourceData(string $url, string|int $item_selector = '')

joegl → created an issue.

I've applied the diff from merge request on a 10.3.x site and it works great: https://git.drupalcode.org/project/drupal/-/merge_requests/5882.diff

Just want to confirm having this issue saving all entity_share forms. The saved data goes through for adding and editing, but it prevents deletion of channel entities.

This module is great and was pretty easy to set up. Unfortunately, this is blocking our implementation because we only want to import specific fields and leave other fields blank for users to edit, and we can't modify the JSON:API output because it's used for other services. Although I understand that doesn't necessarily align with the module intent, it'd be a great feature to have.

Thanks larowlan -- from what I've read so far this sounds perfect for our use case.

joegl → created an issue.

Awesome thanks acbramley

This module could also really benefit from transitioning to semver versioning. https://www.drupal.org/node/1015226#semver-transition →

Dropping Drupal 9 support, adding Drupal 11 support and requiring PHP 8.1 all in one release should probably be part of a larger version jump.

I was able to test sending the request a Referer header and it worked successfully.

In core/modules/media/src/OEmbed/ResourceFetcher.php starting on line 69:

      $response = $this->httpClient->request('GET', $url, [
        RequestOptions::TIMEOUT => 5,
        'headers' => [
          'Referer' => 'https://MYURL.COM',
        ]
      ]);

I then checked the response with and without the header. With the header it returned the title (and a number of other metadata). It also include the title attribute on the iframe. Without the header it was missing the metadata and had no title attribute on the iframe.

I will see if I can't work on actual patch/MR with the actual site URL instead of it hard-coded, but I wanted to test the path forward first. This might fit into its own issue at this point because of the specific scenario?

tl:dr; Unlisted or domain-restricted Vimeo videos do not return metadata (including the title) in the oembed API results unless the URL is sent as a Referer header.

I've noticed the title attribute missing from the inner iframe when using the oembed content in Drupal to display videos.

From what I can tell, the core media module is getting the iframe code directly from the Vimeo API response using their oembed.json. The request is made in core/modules/media/src/OEmbed/ResourceFetcher.php. A request to the Vimeo API looks like this: https://vimeo.com/api/oembed.json?url=https%3A//vimeo.com/VIMEO_VIDEO_ID

In reviewing the Vimeo API documentation for oembed's, this appears to be an issue with the video privacy settings. The videos on our sites have domain-level privacy enabled on Vimeo -- this means the videos can only be embedded and viewed on the configured domains. In the "Embedding videos with domain-level privacy" section, it says (paraphrasing):

For videos with the whitelist privacy setting — that is, videos with domain-level privacy — The oEmbed request returns a simplified response containing no private metadata.

The metadata excluded includes the "title" attribute.

The solution according to the documentation is to send the URL as the Referer header in with the request (and a curl example is given).

curl -e http://example.com https://vimeo.com/api/oembed.json?url=https:%2F%2Fvimeo.com%2F286898202

I'm not exactly sure how to build this into the `ResourceFetcher`, but that seems to be the solution for this (if possible).

I believe we have fixed this by manually implementing a UUID property fix from this issue: https://www.drupal.org/project/paragraphs_browser/issues/3347934 🐛 PHP 8.2 Deprecated function: Creation of dynamic property RTBC

The fix was been merged into the dev code here about a month ago: https://git.drupalcode.org/project/paragraphs_browser/-/commit/c0c457a63...

We didn't want to use the dev version of the module and created a patch for it to apply via composer instead.

Nevermind. I was still using a patch for https://www.drupal.org/files/issues/2022-04-29/menu_block_rendered_empty... → that removed these. Just need to remove that patch. Nothing to see here.

Attached a patch for use with composer

joegl → created an issue.

We are having the same issue on our staging and dev environments (but oddly not on production). It appears to only affect paragraphs added initially after logging in and creating a new page. Subsequent additions don't appear to be affected when editing the page after the initial failed save.

Notice: unserialize(): Error at offset 129052 of 321619 bytes in Drupal\Component\Serialization\PhpSerialize::decode() (line 21 of /docroot/core/lib/Drupal/Component/Serialization/PhpSerialize.php)
#0 /docroot/core/includes/bootstrap.inc(164): _drupal_error_handler_real(8, 'unserialize(): ...', '/mnt/www/html/h...', 21)
#1 [internal function]: _drupal_error_handler(8, 'unserialize(): ...', '/mnt/www/html/h...', 21)
#2 /docroot/core/lib/Drupal/Component/Serialization/PhpSerialize.php(21): unserialize('a:58:{s:11:"#at...')
#3 [internal function]: Drupal\Component\Serialization\PhpSerialize::decode('a:58:{s:11:"#at...')
#4 /docroot/core/lib/Drupal/Core/KeyValueStore/DatabaseStorageExpirable.php(61): array_map(Array, Array)
#5 /docroot/core/lib/Drupal/Core/KeyValueStore/StorageBase.php(35): Drupal\Core\KeyValueStore\DatabaseStorageExpirable->getMultiple(Array)
#6 /docroot/core/lib/Drupal/Core/Form/FormCache.php(121): Drupal\Core\KeyValueStore\StorageBase->get('form-HJjw9Ap6mo...')
#7 /docroot/core/lib/Drupal/Core/Form/FormBuilder.php(456): Drupal\Core\Form\FormCache->getCache('form-HJjw9Ap6mo...', Object(Drupal\Core\Form\FormState))
#8 /docroot/core/lib/Drupal/Core/Form/FormBuilder.php(269): Drupal\Core\Form\FormBuilder->getCache('form-HJjw9Ap6mo...', Object(Drupal\Core\Form\FormState))
#9 /docroot/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\node\NodeForm), Object(Drupal\Core\Form\FormState))
#10 /docroot/core/modules/layout_builder/src/Controller/LayoutBuilderHtmlEntityFormController.php(39): Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#11 [internal function]: Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#12 /docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#13 /docroot/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#14 /docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#15 /docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#16 /vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#17 /vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#18 /docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /docroot/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /docroot/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /docroot/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#29 {main}

We are also seeing the following error on the edit page: /node/1/edit?_wrapper_format=drupal_ajax&ajax_form=1

Deprecated function: Creation of dynamic property Drupal\paragraphs_browser\Plugin\Field\FieldWidget\ParagraphsBrowserWidget::$uuid is deprecated in Drupal\Component\Serialization\PhpSerialize::decode() (line 21 of /mnt/www/html/humscigryphontest/docroot/core/lib/Drupal/Component/Serialization/PhpSerialize.php)

#0 /docroot/core/includes/bootstrap.inc(164): _drupal_error_handler_real(8192, 'Creation of dyn...', '/mnt/www/html/h...', 21)
#1 [internal function]: _drupal_error_handler(8192, 'Creation of dyn...', '/mnt/www/html/h...', 21)
#2 /docroot/core/lib/Drupal/Component/Serialization/PhpSerialize.php(21): unserialize('a:58:{s:11:"#at...')
#3 [internal function]: Drupal\Component\Serialization\PhpSerialize::decode('a:58:{s:11:"#at...')
#4 /docroot/core/lib/Drupal/Core/KeyValueStore/DatabaseStorageExpirable.php(61): array_map(Array, Array)
#5 /docroot/core/lib/Drupal/Core/KeyValueStore/StorageBase.php(35): Drupal\Core\KeyValueStore\DatabaseStorageExpirable->getMultiple(Array)
#6 /docroot/core/lib/Drupal/Core/Form/FormCache.php(121): Drupal\Core\KeyValueStore\StorageBase->get('form-GMfBN39kXi...')
#7 /docroot/core/lib/Drupal/Core/Form/FormBuilder.php(456): Drupal\Core\Form\FormCache->getCache('form-GMfBN39kXi...', Object(Drupal\Core\Form\FormState))
#8 /docroot/core/lib/Drupal/Core/Form/FormBuilder.php(269): Drupal\Core\Form\FormBuilder->getCache('form-GMfBN39kXi...', Object(Drupal\Core\Form\FormState))
#9 /docroot/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\node\NodeForm), Object(Drupal\Core\Form\FormState))
#10 /docroot/core/modules/layout_builder/src/Controller/LayoutBuilderHtmlEntityFormController.php(39): Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#11 [internal function]: Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#12 /docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#13 /docroot/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#14 /docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#15 /docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#16 /vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#17 /vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#18 /docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /docroot/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /docroot/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /docroot/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#29 {main}

If we're uninstalling this module and using the new "Sanitize filenames" settings at /admin/config/media/file-system, I assume we'd want to enable all the options and leave the Replacement Character as the dash? Thanks!

I'm happy to closet his now, just not sure what closed status is most applicable here. I'm going to pick "cannot reproduce".

Well this is interesting.

We were not using the views_rss module for our feed. I wasn't aware the RSS feed in views was part of Drupal core, which appears to be what we're using. That would explain the dpm/var_dump thing. However, once I uninstalled the views_rss module from the site, the problem completely disappeared. I'm going to run a few more tests to confirm, otherwise this is probably resolved.

I've created views of different types and this only happens with feeds created with `views_rss`. I created an XML feed with `views_data_export` and it did not have this problem. I also created an XML Feed with REST Export and it did not suffer from this issue. Even though I couldn't reproduce it on a vanilla drupal install, there appears to be something with this module specifically that causes this problem. Unfortunately the aforementioned modules don't allow for the creation of a "true" RSS Feed. We may end up coming up with an in-house solution to generate the feed but it would be nice to figure out what's going on here.

FWIW, I've also struggled a lot trying to debug the code in this module with `dpm` and `var_dump`. I've never been able to get any output from either of those in any part of the code for this module.

Our solution for this was to patch the one line and adjust the condition to allow our custom blocks as well:

if (contextualId && !(contextualId.startsWith('layout_builder_block:') || contextualId.startsWith('OUR_CUSTOM_BLOCKS:'))) {

I'd still like to see something more comprehensive to allow customizations like ours if possible. Again, this change makes a lot of assumptions about the desired user experience.

We have a custom module to create block groups in layout builder. The child blocks in the parent block group have their own contextual links defined by the module, and do not have the `layout_builder_block:` start to the contextual ID. This change made the contextual links for child blocks all get removed, and they can no longer be edited, removed, moved, etc.,

What is the best way to approach changes to our custom module to support this change? Adding the colon `:` to the end here seems a bit heavy handed. If it wasn't there, we could at least update our module to use the `layout_builder_block_` prefix.

I finally got around to testing this on a vanilla drupal install using drupal/recommended-project and was not able to reproduce this

A really inelegant workaround I've found is to set the field as already validated in the buildConfigurationForm() method of our base class:

 public function buildConfigurationForm(array $form, FormStateInterface $form_state) {

    // at bottom of the method
    $form = parent::buildConfigurationForm($form, $form_state);
    $form['column_widths']['#validated'] = TRUE;
    return $form;
  }

Ideally none of the fields in the $form['config'] in layout_paragraphs/src/Plugin/paragraphs/Behavior/LayoutParagraphsBehavior.php would not be validated when a new layout selection is made in the , and only validated once the layout selection is saved.

I'm going to re-summarize the issue here for my own clarity (apologies for any redundancy).

We extend the core `layout_builder``MultiWidthLayoutBase` class which adds width options to the configuration form (Layout Options in the Layout Paragraphs) using the `getWidthOptions()` method. When two layouts have different Width Options and we switch between them, there is an error "The submitted value (VALUE_HERE) in the Content Width element is not allowed." If there is existing paragraphs, the error does not effect anything. If there are existing paragraphs. some of them are lost.

I've been having trouble debugging the validateConfigurationForm method, but from what I can tell, the newly selected layout options are being used to validate against the selected form value for the option.

E.g., If you have a one column layout selected with '100' => '100%' as the width options and then switch to a two column layout with '50-50' => '50% - 50%' as the width options, it's going to validate your selected option in the form for the one column (100) against the options for the two column layout (50-50).

It looks like this error isn't "harmless" but actually causes paragraphs to be lost when switching between different layouts that have existing paragraphs in regions. Linked relevant issue.

I believe we are running into the same thing here: https://www.drupal.org/project/layout_paragraphs/issues/3393704#comment-... 💬 Form error on layout section when using module layout_section_classes Active

I thought the bug/error in the above issue was harmless but it turns out it's causing the problem described in this issue.

Going to link these two issues.

Does anyone have a good solution for this? We need to be able to have separate options available in different layouts and we can't always force the keys to match.

To expand on this, I noticed in the LayoutParagraphsBehavior buildBehaviorForm() method there is a supposed to be an ajax callback that fires (ajaxUpdateOptions) when a layout is selected:

    $form['layout'] = [
      '#title' => $this->t('Choose a layout:'),
      '#type' => 'layout_select',
      '#options' => $available_layouts,
      '#default_value' => $default_value,
      '#ajax' => [
        'wrapper' => $wrapper_id,
        'callback' => [$this, 'ajaxUpdateOptions'],
        'progress' => [
          'type' => 'throbber',
        ],
      ],
      '#weight' => 0,
    ];

The callback itself seems like it's supposed to rebuild the $form['config'] options (where the width options are):

  public function ajaxUpdateOptions(array $form, FormStateInterface $form_state) {
    $triggering_element = $form_state->getTriggeringElement();
    $parents = $triggering_element['#parents'];
    array_splice($parents, -1, 1, ['config']);
    $config_form = NestedArray::getValue($form, $parents);
    if (isset($config_form)) {
      return $config_form;
    }
    return [];
  }

However, when a layout is selected this callback is not firing, and the submitBehaviorForm() method is ran instead. I'm not sure if that's how it's supposed to work or not.

We are also seeing this when we extend the core layout_builder module's MultiWidthLayoutBase class.

When we switch layouts in the layout section pop-up and there the option selected for the current layout doesn't exist in the getWidthOptions() for the new layout, it spits out this error. It doesn't appear to have any affect and the error is actually coming from the submitConfigurationForm() method, and not buildConfigurationForm().

For example, we have a three column and two column layouts both extending the MultiWidthLayoutBase:

Three column:

class ThreeColumn extends MultiWidthLayoutBase implements PluginFormInterface {
  protected function getWidthOptions() {
    return [
      '100' => '100%'
    ];
  }
}

Two column:

class TwoColumn extends MultiWidthLayoutBase implements PluginFormInterface {
  protected function getWidthOptions() {
    return [
      '50-50' => '50% - 50%',
      '33-67' => '33% - 67%',
      '67-33' => '67% - 33%',
    ];
  }
}

When we switch from ThreeColumn to TwoColumn it complains because the 100 option doesn't exist in the TwoColumn (and vice-versa).

I think we are going to start using the display_field_copy → module for this instead. I'm happy to close this assuming it was specific to our code.

Thanks for your help on this swentel.

When creating a new block field on the Displays / Fields page, there are options to select Layout Builder blocks in the "Block" drop-down. They typically look something like: `FIELD NAME (Layout Builder: MACHINENAMES)` for example the `Description: (Layout Builder: field_block:taxonomy_term:hs_event_category:description)`. We have created a few fields this way to use in a View Mode when we need data from the same field displayed twice (such as a Date field where we want to show the Time in one place and the Date in another).

It's possible there is something a conflict in our own codebase causing this, but we're experiencing it across all sites on the same platform after the upgrade.

We are also having a separate issue where on a few sites it causes a fatal error when a field block with a Layout Builder block is being used.

This is on Drupal 10.2.2

It looks like this came from https://www.drupal.org/project/ds/issues/2679785 →

https://git.drupalcode.org/project/ds/-/commit/de04bc69e385c18e795c72b55...

joegl → created an issue.

That's what I plan to do next. Probably won't get to it until January but I will report back

I did some debugging of the views-view-rss.html.twig

{{ dpm(items) }}

I returned NULL for the items when I saved the unpublished node.

So something is breaking the rendered items when I save an unpublished node.

Also, after I saved an unpublished node, the view breaks. When I rebuild the cache either through UI or a drush cr, the view is still not working. However, if I re-save the view and try to load it, it works.

I switched to the Stark theme and was able to still reproduce the issue.

As many as are available. The amount doesn't seem to matter.

This doesn't affect the Preview section of the view. It only affects the rendered view. And the saving of a node as unpublished as the trigger is suspicious. I am guessing the issue is occurring when it builds the cache of the rendered view after saving content. I'm not exactly sure of the best way to debug, but if I could get a stack trace of the render pipeline I could see if maybe we have a custom hook or code affecting this.

Is this related to https://www.drupal.org/project/views_rss/issues/3079683 💬 Add CDATA tags at description field on D8 Closed: duplicate ?

Patch unfortunately did not resolve the issue.

The view has a filter to filter out Unpublished content and it does not show Unpublished content from what I can tell. I will try the patch and get back to you. Thanks for your help!

I'm guessing since this isn't widespread that it's something unique in our stack/setup or a hook we have somewhere.

joegl → created an issue.

joegl → created an issue.

We ran into the same issue on 6.0.1:

Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("linkit_profile") to generate a URL for route "linkit.autocomplete". in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 181 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

Confirming upgrade to 6.0.2 fixed this.

Thanks!

Thanks @keshavv. Confirming patch works.

joegl → created an issue.