🇺🇸United States @joegl

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 Active ?

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.

Apparently there's another page that only has one step and it's how to create a merge request: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

I believe the documentation mentioned in the OP should either include a link to this one, or the following instructions:

On the issue page, find the branch you have been working on in the issue fork area, and click the “Open merge request” button.

joegl → created an issue.

joegl → created an issue.

After this was merged into 8.1.5 the patterns we have in our child theme are encountering a TWIG fatal error on site installs.

Twig\Error\LoaderError: Template "@my_subtheme/news-list/news-item-list.html.twig" is not defined in "modules/contrib/ui_patterns/templates/patterns-use-wrapper.html.twig" at line 9. in Twig\Loader\ChainLoader->getCacheKey() (line 98 of /vendor/twig/twig/src/Loader/ChainLoader.php).

I know this issue is closed so I've created a new Support Request issue here: https://www.drupal.org/project/ui_patterns/issues/3354131 💬 TWIG Fatal Error in child theme pattern definitions after 1.5 upgrade Active

I'm assuming we may need to change something on our end or in the configuration, but I'm not sure what.

joegl → created an issue.

We had a site not get updated properly on a multi-site and couldn't downgrade back to the old version. I have not found a perfect path to upgrade, but the process I've used is:

1. Go to `/admin/config/system/field-encrypt/field-overview`. This lists all the encrypted fields on the site.

2. Retrieve the values of these fields or make sure you have them on hand already (also perform a database backup). There is a "Decrypt" button on the field-overview page, but I could not get it to work.

3. Uninstall the `field_encrypt` module

4. Re-install the `field_encrypt` module. We use config management, so I did this with importing config with drush instead `drush ci` and `drush updatedb`.

5. Go to `/admin/config/system/field-encrypt/process-queues` and click the button to process the queues.

6. Re-fill in the values for the fields you have encrypted.

Perhaps there's a better way to do this, but this worked for our needs.

Apparently, this module uses the url as the unique key for this field instead of a unique ID. That probably should be changed; either that or some kind of check needs to be performed that denies the user the creation of a duplicate entry.

I am guessing the issue has to do with collation of a database and how it stores unique characters. Because if the unique key is the URL, then duplicate entries by definition shouldn't exist. The only reason they exist is because they're not duplicates, and one is probably using a special character of some kind. The problem is when the database gets dumped and imported, somewhere along that process the unique character which makes two entries separate gets stripped or modified and thus the entries now match and are considered duplicates.

In my case, it was because the difference in MySQL versions between the production site and my local where I was importing and how certain characters were treated between those versions.

Suggestions with different label and value are supported too. The label will be shown in autocompleter and the value will be inserted into the input.

Is this actually a problem with the current JQuery UI Autocomplete or it's core implementation? As far as I know, drupal core inserts the label into the input instead of the value, and this wasn't a constraint or design decision forced by JQuery UI Autocomplete. I'm not in anyway stating we shouldn't move on from JQuery UI Autocomplete, but just wanted an answer on this. The reason for this I believe is the need to store the value while still showing the label to the user (by appending the ID's with the labels in parentheses to regex them out later). It appears Awesomplete does solve this, but I'm not entirely clear on how.

EDIT: Apologize for all the edits and if this is redundant, I'm just excited about this!

Entity ID's and ID's in general are internal reference keys and users should:

A) Not be expected to know what they are
B) Be expected to be confused/thrown off by them

I also think it's pretty straightforward that the "label" is what they want users to see and the "value" is what the server-side/backend is going to operate on. It seems logically inconsistent to use the "value" as the display for the field once selected instead of the label, but I completely understand why (where else does the value go?).

The obvious workaround that comes to mind for UI purposes would be to store the actual value in a hidden field, and put the label in the textfield that's displayed to the user, but I am not certain how easy it is to incorporate.

We actually have a custom AJAX autocompleteselect callback that pulls the value off the $form_state for the field, sets it in the $form storage, and then re-sets the userInput and value for the field on the $form_state to what the label is. The only problem with this approach is that for a split-second the user still sees the raw value instead of the label, as the AJAX is being performed (and apparently that's still really confusing).