🇺🇸United States @dalemoore

I'm having this issue as well, I need to set a default placeholder image for event content type and it worked before but apparently doesn't now. There are no errors in the console or anything, it just doesn't work.

I had this same need. I have a Department content type and we need for the user to be able to select a department in a dropdown list, and creating a department called "Other Department / Not Listed" makes no sense since we'll then have a node that serves no other purpose and will appear in all other department listings. We basically need the same functionality as the Select other component, where if someone's department isn't listed (because they aren't part of our unit) then they can enter it in the custom field. Will look into a custom code solution.

Ohh! Gotcha. Yeah I was expecting the pencil icon to be directly over the image/other media within the CKEditor body field and when you click it it would open the media entity in a modal to edit. Sorry about that, I'll see if there's another module that does what I'm looking for.

dalemoore → created an issue.

I was looking to do this just now as well, and it is confusing showing the larger # due to revisions. It also seems to crap out if you leave the thumbnail field in there which kinda isn't great, because for images having the thumbnail would be helpful.

This hasn't had any traffic in over a year, but I'm running into the same issue. I figured out how to create a migration to fix broken links when the node IDs/aliases changed from a migration a former coworker did, but the links are converted to the node/ID format, and Linkit doesn't seem to do anything with them to make them into their nicer looking alias without those extra data-attributes. I thought if I just resaved the pages it would kick in but it doesn't I guess w/o those attributes.

I just determined that the issue with this not working is due to enabling the Scheduler module for my Event content type. It appears that this patch combined with Scheduler isn't compatible...

So does this issue mean that if I set that setting to display the "Direct URL to media file entity" it should display the full path on the frontend of the site, even though the link in CKEditor using Linkit displays media/id? I've updated to the latest Linkit, and that doesn't seem to be happening.

So is one or more of the patches in this issue the solution to Group Content Menu blocks not appearing on nodes within that group? I see some others in this issue are having the same problem.

What is the more “modern” recommended way to implement these features if these are to be removed from Core? I read through the entire issue this was forked from and am not sure. Is it the Flag module? I’m preparing to launch a new site in the next few days and getting in the replacement now would be ideal considering the huge scale of content in it. I saw Flag and Entityqueue mentioned, but curious what others who aren’t using these base fields but do implement these features use. I saw on the original post that these base fields are more performant than adding a field like field_promoted manually. I’m particularly interested in the comment about how promoted and sticky are useless when more than one node is tagged with those in a Views list.

I just ran into this issue as well, and can confirm that using the "rewrite results" method is a decent workaround for now. I just set it up how I wanted in both sections, under Style Settings and under Rewrite Results. I'll be able to disable the rewrites once it's fixed in UI Patterns. 🎉

I just discovered this concept while trying to piece together my own design system.

For the design tokens, is the idea for the theme-level ones to be contained within themename.tokens.yml (or modulename.tokens.yml)?

The draft spec seems to recommend .tokens or .tokens.json, so I assume ours would be .tokens.yml

Something like this maybe what you're needing? (five years later):
{{ url('entity.node.revision', {'node': node.id, 'node_revision': node.getRevisionId()}) }}

The patch no longer seems to work for me after upgrading FullCalendar.

dalemoore → created an issue.

Agreed with @eszszabo, this should really be solved in Core. Even Microsoft Word allows you to mark images as decorative, and surely Drupal is better with accessibility than Word. 😅

I'm also against deprecating this field as I'm also using the textarea widget for text fields module for the exact same use cases: for adding strong, italics, exponents, etc. in title fields, SDC props, and other short text fields where it doesn't make sense for a full textarea/longtext field. I see I commented in the other issue 2 years ago, and just want to say it still works very well. I have custom text formats explicitly limiting the number of buttons that are used in the CKEditor for these fields.

Thanks all for the fix! I had to temporarily remove this module from my new website I'm making because I needed to upgrade to D11. I'm using it for a recipe content type. I second @drupalmind if this can be put in a stable release soon that would be awesome.

dalemoore → created an issue.

I'm personally using web components with Lit 3 and combining them with SDCs. It's been very effective!

I'm using Import Maps and this shim:

<script async src="https://cdn.jsdelivr.net/npm/es-module-shims@1/dist/es-module-shims.min.js"></script>

So that my Lit components don't have to change the path to finding Lit at the top of the individual .js files.

At the top of my html.html.twig I've included these references to the Lit libraries:

<script type="importmap">
      {
        "imports": {
	        "lit": "/libraries/lit/index.js",
          "@lit/reactive-element": "/libraries/@lit/reactive-element/reactive-element.js",
          "lit-element": "/libraries/lit-element/index.js",
          "lit-element/": "/libraries/lit-element/",
          "lit-html": "/libraries/lit-html/lit-html.js",
          "lit-html/": "/libraries/lit-html/",
          "lit/directives/class-map.js": "/libraries/lit/directives/class-map.js",
          "lit/directives/choose.js": "/libraries/lit/directives/choose.js",
          "lit/directives/style-map.js": "/libraries/lit/directives/style-map.js",
          "lit/static-html.js": "/libraries/lit/static-html.js",
          "lit/directives/if-defined.js": "/libraries/lit/directives/if-defined.js"
	      }
	    }
    </script>

In each SDC's component.yml, I add this at the bottom:

libraryOverrides:
  js:
    component-name.js: { attributes: { type: module }}

There's probably better ways to do this; if anyone has suggestions. My site is still in development. But the SDC + Web Component method I'm using works well.

Well, apparently this is a core issue, not a Gin issue. Sorry! Upgrading from Drupal 11.2.0 to 11.2.2 seems to have fixed it. Tagging what I think is a related issue.

dalemoore → created an issue.

This sounds fantastic! I posted in the #group-module channel basically looking for what I believe is this exact solution, or close enough. I'm looking at ways to use Group to grant permissions to different areas but also allow users to still use the Drupal admin UI's capability to add nodes without having to go to the group's "landing page" or whatever it's called (still learning Group terminology and functionality, sorry).

I was looking to do the exact same thing as @nicxvan.

There were a few typos in Chris' example above so I'm posting what I have here for future reference, even if just for myself.

In my_module.services.yml (should be services, plural! this got me for a bit):

services:
  media.oembed.resource_fetcher:
    class: Drupal\my_module\OEmbed\ResourceFetcher
    arguments: ['@http_client', '@media.oembed.provider_repository', '@cache.default']

In the ResourceFetcher.php:

<?php

namespace Drupal\my_module\OEmbed;

use Drupal\media\OEmbed\ResourceFetcher as CoreResourceFetcher;

/**
 * Fetches and caches oEmbed resources.
 */
class ResourceFetcher extends CoreResourceFetcher {

  /**
   * {@inheritdoc}
   */
  protected function createResource(array $data, $url) {
    if ($data['provider_name'] == 'Libsyn') {
      $data['version'] = '1.0';
      $data['thumbnail_width'] = 480;
      $data['thumbnail_height'] = 480;
    }
    return parent::createResource($data, $url);
  }

}

I had to include the two things for thumbnail above, because Libsyn includes the thumbnail URL and I was getting this error in the logs and it wouldn't save the Remote audio:

The thumbnail dimensions must be numbers greater than zero.

I honestly don't know what should be there for the thumbnail_width and height, or even what that is for, but I just put something there.

After doing that, clearing Drupal caches, clearing provider caches, whatever, I was able to save the remote audio media! And it embeds beautifully.

Hi all!

Attempting this again. Does the field actually have to be named "field_when" in the paragraph? I'm getting these errors that I'm wondering if it's because mine is called "field_date".

I've applied @jennypanighetti MR as as patch, and it seems to work, at least in the calendar view. It doesn't seem to work in the list view.

For those who have got it working with the MR/patch can you share your settings for the FullCalendar view? I'm trying to do the same thing, use a paragraph type that allows for unlimited instances on the same node for a date + location. I'd love to test as well!

Thank you! This module is really helpful with SDCs 🎉 The unneeded paragraph tags can be a pain with them if you're working directly in the Twig templates adding an SDC. There may be more people looking to use it in the future.

Is there anything else needed here? This is one of 3 modules left that are preventing me from updating to D11. There hasn't been a release in a long time.

Is this talking about the Dashboard block that gets added? I see it gets added in Drupal CMS, but on a separate site I'm using that is just Drupal Core I installed the Dashboard module and the Dashboard block isn't available to be placed into the navigation area. I'm on Drupal 10, does that matter?

Is there an updated fix for this? The module had changed in the last year or so.

If you need any help testing let me know! I'm still having the issue, and it's something I'd love to solve. But I'm not a backend guy. :\

This would be great. I'm currently setting up a photo competition section on an old site, and unfortunately the site is still on D7. The EXIF Custom module seems to work well so far, but I'm trying to setup something for next year in D10 (and to prepare redoing the entire site) and this EXIF module isn't working, the fields don't appear at all on the Media type like they do on the File type with EXIF Custom in D7.

Hi, I'm experiencing this same issue out of the box on a new Drupal 10 DDEV site. The only thing I've installed is this module so far. I have created a separate Media type, called "Competition Photo", and am not using the Core-installed Image one since I don't want all these extra EXIF fields on the default Image media type. I don't think that should be an issue though as it appears to affect the Core Image media type too looking at the screenshots from @randoTm.

I'm glad someone else opened this issue because I was confused for a good while why I couldn't find the "Show only used items" checkbox mentioned on the module homepage after using this for the first time!

@freelock is this actually in UI Patterns now or is it something you implemented in custom code? I am going to need to do something very similar soon to create a mega menu component of sorts. Thanks!

dalemoore → created an issue.

I'm getting this error too on a server we just upgraded to 8.4. Luckily the site isn't currently live.

+1 on the patch fix correcting the issue for me. Couldn't drag anything into disabled area is what made me notice.

g4mbini → credited dalemoore → .

Just tested, yep fixed! Thank you 🙇‍♂️

This partially solves the issue for me. I put the code @just_like_good_vibes included above directly into a custom module, installed it, and I no longer get ContextException errors on the front end, but I do still get them in Layout Builder.

Steps:

1. Put the code above in a custom module, or in the code for this new module, whatever you have to do to get it the codebase :)
2. Create a block type, for example, Alert, and add a field on it of List (text) type called Variant. Add some variant types to the field list, e.g., default|Default, primary|Primary, danger|Danger, etc. and save... can add other fields too like Body to populate the alert slot.
3. In the Alert block type, select an Alert component from the SDCs in the layout settings. Map the Variant field to the Variant prop.
4. Go to a content type, like Page, and enable Layout Builder and add a block of the Alert block type to it, and select one of the variants and save the layout.
5. The Alert block will have the proper variant on the frontend of the site, but in Layout Builder for the page content type, it won't. You'll still get the ContextExceptions in the logs.

Okay, I'm using Display Suite rather than Field Layout, and haven't noticed a problem with it rendering slot-less SDCs as layout for my use. Maybe the issue is only there then, or we're using it differently. Just wanted to provide a different use case.

I disagree with this if I'm understanding what you're saying. It's entirely possible to use a component that renders only with props defined in the SDC and no slots if you're using web components. The rendering logic is instead in the JS/CSS/template of the web component. In this case all of the fields will be in the "disabled" region in Manage Display, and there would be no slot region(s), with the fields being mapped to props in the component only. If this capability is taken away I would need to quit using UI Patterns. I may be misunderstanding what you're saying, though!

I tried the updated code as a patch (alongside the other issue's code which I still have patched in), switching my 'Social Links' component to use 'Rendered entity' instead of 'Components per item', then in the paragraph type mapping the fields to the props. Instead of the ContextException I now get this:

The website encountered an unexpected error. Try again later.

Error: Call to a member function get() on null in Drupal\ui_patterns\Plugin\UiPatterns\Source\FieldPropertySource->getPropValue() (line 33 of modules/contrib/ui_patterns/src/Plugin/UiPatterns/Source/FieldPropertySource.php).

Drupal\ui_patterns\SourcePluginBase->getValue() (Line: 98)
Drupal\ui_patterns\Plugin\UiPatterns\Source\DerivableContextSourceBase->getPropValue() (Line: 199)
Drupal\ui_patterns\SourcePluginBase->getValue() (Line: 91)
Drupal\ui_patterns\Element\ComponentElementBuilder->buildProp() (Line: 71)
Drupal\ui_patterns\Element\ComponentElementBuilder->buildProps() (Line: 52)
Drupal\ui_patterns\Element\ComponentElementBuilder->build()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 870)
Drupal\Core\Render\Renderer->doCallback() (Line: 432)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 44)
__TwigTemplate_9fd84133cf2adb9e74cfdc062566cfd5->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 244)
__TwigTemplate_bc21571d82fec26cc5a2a823aa2651a1->{closure}() (Line: 2058)
Twig\Extension\CoreExtension::captureOutput() (Line: 213)
__TwigTemplate_bc21571d82fec26cc5a2a823aa2651a1->macro_content() (Line: 191)
__TwigTemplate_bc21571d82fec26cc5a2a823aa2651a1->{closure}() (Line: 2058)
Twig\Extension\CoreExtension::captureOutput() (Line: 119)
__TwigTemplate_bc21571d82fec26cc5a2a823aa2651a1->macro_field() (Line: 87)
__TwigTemplate_bc21571d82fec26cc5a2a823aa2651a1->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 504)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 86)
__TwigTemplate_3150cca8781d01d314c0ea2fc77e4d3e->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 165)
__TwigTemplate_f755c51af21e4ba003b7403eadf7f91a___59522040->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 44)
__TwigTemplate_f755c51af21e4ba003b7403eadf7f91a->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 234)
Drupal\Core\Template\TwigEnvironment->renderInline() (Line: 54)
Drupal\Core\Render\Element\InlineTemplate::preRenderInlineTemplate()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 870)
Drupal\Core\Render\Renderer->doCallback() (Line: 432)
Drupal\Core\Render\Renderer->doRender() (Line: 504)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 44)
__TwigTemplate_9fd84133cf2adb9e74cfdc062566cfd5->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 152)
__TwigTemplate_bc05fafc2639a509ad8ac530045c2abd->block_content() (Line: 431)
Twig\Template->yieldBlock() (Line: 89)
__TwigTemplate_bc05fafc2639a509ad8ac530045c2abd->block_wrapper() (Line: 431)
Twig\Template->yieldBlock() (Line: 53)
__TwigTemplate_bc05fafc2639a509ad8ac530045c2abd->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 504)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 178)
__TwigTemplate_00e51af2befcc5fa6f56f8cd1ffdd83c->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 128)
__TwigTemplate_31cd56f2962c65fbb44761101472ce3c->doDisplay() (Line: 387)
Twig\Template->yield() (Line: 343)
Twig\Template->display() (Line: 358)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 176)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->makeSubrequest() (Line: 119)
Drupal\Core\EventSubscriber\CustomPageExceptionHtmlSubscriber->makeSubrequestToCustomPath() (Line: 81)
Drupal\Core\EventSubscriber\CustomPageExceptionHtmlSubscriber->on404() (Line: 109)
Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase->onException()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 239)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

a custom plugin type ("DS Field"), for this one, ui_patterns_ds is needed

To my knowledge I'm not using a DS Field, but I could be wrong. Would I have to select one of these options in the layout dropdown under Manage Display to do something like that?

Or, this option would need to be enabled maybe:

Or something on this screen?

I'm not sure what exactly a DS Field is, I haven't used the things found in the last two screenshots before. In the past I would only use what's in the first screenshot, which allows me to override the template, add attributes/classes to fields, etc.

The only thing I'm using DS in this case is to select an SDC on the Manage Display screen layout dropdown without having to rely on Layout Builder (because I don't wish to manipulate layout visually, just do mapping to the SDC) or Field Layout (this module is to be deprecated and will be removed from Core, see this issue 📌 Inform users that Field Layout is deprecated Active , this issue 📌 [META] Enable layout builder for form displays, and deprecate field_layout Postponed , and this issue 📌 Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase Needs work ). I haven't tried using Field Layout before, but I just did on a separate bare Drupal install. It doesn't seem to offer the ability to control field layout under "Manage display" any more, only under "Manage form display", so using Field Layout instead of Display Suite won't work.

I would like to co-sign this request. I first started out trying to integrate components in our new flagship site a few months ago, and started using Single Directory Components for the job. I love this new addition to Drupal, but incorporating them into the site is painful. Having to create a new Twig template every single time you want to call values from a field, block, or whatever as an SDC is cumbersome to say the least. I was finding myself repeating the same Twig code over and over across content types, fields, etc., which Twig's extend capability is helpful with, but it means what's setup in the Drupal UI under Manage Display or in Layout Builder is no longer 1:1 with what's in the Twig template. It feels very "un-Drupal"-like working this way. We really need something like UI Patterns in Core to get the most out of their use. Experience Builder is many more months away and while it seems to be able to eventually control the entire layout of a site, not just the content area like Layout Builder, it remains to be seen if everyone would adopt it. And I imagine it will take many years for it to fully replace everything if that's the goal. Putting something like UI Patterns in Core will work for now. Just my 2¢.

Here are my steps to reproduce. Some in the first steps sub-bullets may not be needed but including?

1. You will need some SDCs to use. I have a parent SDC called Social Links and a child one called Social Link. (@pdureau should already have these, they were included in the Slack conversation)
2. Make sure you have Display Suite and Display Suite Extras installed. This is used to select a component layout within Manage Display. Under Display Suite (admin/structure/ds/settings), I have these settings:
   • Enable field templates
   • Enable field templates in Layout Builder
   • Default Field Template: Expert
   • Under Extra fields, nothing selected
   • Under Other, "Use field names in templates" and "Exclude Display Suite Layouts in Layout Builder" are checked"
   • Nothing checked in BC settings
3. Create a paragraph type (in my case, it's called Social Link - this is the child component) and add whatever fields you want to it, including at least one Entity Reference field (I have a taxonomy term one called Network that references social network names, e.g., Facebook, Instagram, etc.).
4. Create a block type (in my case, it's called Social Links - this is the parent component) and add whatever fields you want, including one Entity Reference Revisions/Paragraphs field that uses the previously-created paragraph type.
5. Go ahead and add an instance of the block somewhere on your page in a region (I'm not using Layout Builder here, just the block UI).
6. Under Manage Display for the block type, make sure it's set to "Referenced entity" under Format for the Entity Reference Revisions field. That's all you need here.
7. Under Manage Display for the paragraph type, with Display Suite installed, under "Current layout" select the SDC you want to use from the dropdown list (for me, it is the child component Social Link) and save.
8. Go to "Layout settings" still in the paragraph type, and map the props to the appropriate fields. The only options to start are "Data from a field" or "Referenced entities", there is no initial "Prop: entity" available like there is when using "Components per item" in the sibling issue. 📌 Introduce a new source to get access to the current "i-th" referenced entity from a field entity reference in the context of component per item field formatter Active I choose "Data from a field" for each.
9. Once all fields are mapped, save, then go back and refresh the page to view your block.
10. I get a ContextException error message.

Sending a video of the steps in Slack.

@pdureau Indeed, following—hopefully we will see it included in some way!

I've tested the updated MR as a patch and don't see a noticeable difference, so if I'm not supposed to, I think it's good.

Hi @pdureau I'm out on personal leave today but will test first thing tomorrow! Thanks again for your and @just_like_good_vibes work on UI Patterns! It's truly something, should be in Core/Drupal CMS IMO

I believe this issue may be caused by the Admin Toolbar module if you have it installed. I did, alongside the new Navigation module that I was trying out. Once I uninstalled Admin Toolbar, the issue went away. See this issue: https://www.drupal.org/project/admin_toolbar/issues/3493798 🐛 Compatibility issue: Route update.theme_install does not exist in Drupal 11.0.x Active

Thanks for the quick fix! Working well.

Sure, I tested it and this patch fixes it!

The variables still go the same way (from Drupal template to component template), they just need to be explicitly passed instead of "magically". Is it an issue?

I can't say yet, I haven't got to the styling of my own web components in Drupal that I forsee possibly being an issue, but it has been a need outside of Drupal for my co-worker who built a custom app with web components.

The problem you and @just_like_good_vibes have been assisting with has been a blocker there :) I couldn't get the child components to output properly first, so didn't want to start styling yet until I evaluate UI Patterns!

If I run into issues, I will be sure to share in an issue. 👍

dalemoore → created an issue.

Thanks for your work on this fix (initially started on Drupal Slack here)

I just tested https://git.drupalcode.org/project/ui_patterns/-/merge_requests/320.diff as a patch, and my fields are properly output into my component now! WOOHOO!

For anyone in the future who may see this issue/doesn't have access to Drupal Slack, the issue was I was unable to output props/slots into a block type-based component that had a Paragraphs/Entity Reference Revisions field on it. I was attempting to create a Social Links component as a block type and each Socal Link was a child Paragraph (with social network, link, relationship, etc. as fields/props). I could use the "Referenced entities" option, but it would only output the first field item's values as the values (props) for all of the field items. This fix, so far, seems to correct that to where each field item has its own distinct values/props. I'll be making several more components setup similarly and test to make sure it continues to work for those!

What about if a developer actually wants to have access to a variable that's available in the parent component? As someone currently working with at least one other person who is also using native web components, we have had need of this ability a few times already. Thanks to the Shadow DOM, it's sometimes not possible to theme or get to content that's been slotted easily, instead, you have to access it from the parent element. Just something to think about here. I doubt most people will be using web components/shadow DOM, but there is a use case here for not absolutely preventing it (or erroring if you don't use this recommendation).

@pdureau Yes I think that would be helpful to indicate for newcomers or non-backend folks how they meant to use for Using your component through a render array → , if that isn't meant to be done in a theme. AFAIK everything that was supposed to go with an SDC is supposed to go in the theme in the same folder as the component, or at least done in the theme. But I don't think it's best practice to do any of that in a theme?

While continuing my quest to slowly implement SDCs, I think it would also be beneficial in the docs to include actual real-world examples of using SDCs as @pdureau has done above. On Using your new single-directory component → , all but one ( the embed example → ) use hard-coded values in the props and slots. I think most of us are going to be wanting examples of how to get data from fields into those, and folks that are more frontend (🙋🏻‍♂️) are going to be struggling to figure out how to do that. Nowhere on the page does it mention how to do that (the only ways I know of are to install Devel/Kint, and just recently learned of Xdebug and have been trying to get it working in VScode).

So far, the only ways I know of to get data out of Drupal and into these SDCs are:

• code the variable in an .html.twig file (e.g., content['#block_content'].field_name.0.value in a block.html.twig to get a prop value w/o the render bits)
• some kind of render array magic, I guess through preprocess functions in your .theme? How else would you use this method → ?
• utilize a contrib module that handles displaying the SDCS, such as SDC Display → , UI Patterns → , and the upcoming Experience Builder →

Are there other ways I'm not aware of? If so, they should be documented. If someone can help me answer these questions, I will try my first time at editing docs on here over the Christmas break. :)

I just saw this issue and wanted to mention: please don't rely that people will only be using Twig to render variant types. There are some of us who will be using Web components (done in e.g., Lit, FAST) for our SDCs and so will be making use of a variant prop to select the variant, and that is expecting a string value of the variant name (e.g., primary, secondary, etc.). The JS and constructed styles of the Web component will be the thing that determines how the variant will look, what slots each variant has, etc., the my-component.twig will only be to print stuff out into appropriate props/slots of the Web component. Similar to how I see in XB they're using the Shoelace components.

Introducing something like this:

{% embed 'my_theme:cool-component' with {
  '#variant': 'my-variant-name',
  prop1: 'foo',
  prop2: 'bar',
} %}

With the #variant prop seems to be introducing a Drupalism into a Web component that may be used elsewhere outside Drupal (that is, no other props will start with #).

As long as I can do this instead:

{% embed 'my_theme:cool-component' with {
  variant: 'my-variant-name',
  prop1: 'foo',
  prop2: 'bar',
} %}

By pulling the string value from #variant or any other method proposed I will be good though!

Thanks @pdureau! Very helpful info. Hopefully we can get some more eyes on this issue to get some more feedback from others who have been/are interested in starting to use SDCs.

Excellent, thank you @pdureau! I know you have extensive experience working on components, SDC, and design systems. Thanks for sharing your insights on here, hopefully we can get these into the docs so others like me won't be confused and we can move towards some best practices.

I'll remove the attributes prop from my components. Also, do you have examples of how you're using SDCs? I downloaded UI Patterns, but there are no SDCs in there as examples. Or if you can direct me toward how you mean with using include rather than embed? I don't get how I can do slots with include and again, the docs only say use embed with slots.

I'm very much in favor of these updates! Your help on Drupal Slack a while back related to using node/user/paragraph rather than content for props was super helpful but that isn't anywhere in the docs IIRC.

Would you also say that doing this:

attributes:
      type: Drupal\Core\Template\Attribute
      title: 'Attributes'
      description: 'HTML attributes to apply to the component.'

in the component.yml is incorrect? Because I see that being done in Umami components, and in Experience Builder components. In my own components, I am noticing some bleeding in from the parent template when then doing adding the attributes prop and doing something like:

<msu-header{{ attributes }}>....</msu-header>

Where if I include that component in my region--header.html.twig, it inherits the attributes from the parent div. If I try to use the 'only' keyword, like this:

{% embed 'msuext:msu-header' only %}
... content here ...
{% endembed %}

then I cannot include slots/blocks that aren't explicitly included in the Twig template.

dalemoore → created an issue.

Yeah, this isn't really 'fixed' per se, probably 'works as designed'. I'm running into this issue as well. I think the only alternative is to just not use this module and use |render|striptags|trim. :\ Unless the solution from SDC Display that was mentioned here can fix?: https://www.drupal.org/project/nomarkup/issues/3405446 ✨ Option to remove twig debug mark up Active

dalemoore → created an issue.

I can confirm the patch in this issue fixes the issue for me thus far.

Agreed, I can't figure out how to edit the title_attributes and content_attributes. I would think they'd be added to the YAML same as the attributes one, on the same level, but they don't appear in the block edit form.

Also, I noticed if you add "ID" to the attributes, save, and then edit the block's ID, then go back and remove the ID and save, it no longer has an ID at all. I'd think it would fall back to the ID it had before, but that may be a limitation of this YAML-based method.

I'm in favor of consistently including the leading slash, I just noticed that in this new site I am working on I've included it in some patterns and excluded it in others. As long as it silently adds it on save but continues to work for existing patterns without (or maybe updates existing ones on sav of the Patterns page, or in a module update hook) it sounds like a nice feature to improve consistency.

Like @mandclu, I've tested the MR!156 in Group 3 and it works! Though I only tested it on content that belongs to one group. Next up: to see if I can create a path based on a Group Content Menu...

I'm curious about the future of Admin Toolbar/Toolbar as well with work on Navigation in Core. There is also a submodule called "Navigation Top Bar" that isn't yet feature-complete that will offer the navigation at the top, not on the left. What Navigation can do is more advanced than what Toolbar can, allowing to add blocks into the nav area.

Ran into the same issue. composer require again variationcache and then run all updates (backing up first!), then uninstalling variationcache seems to work fine so far. But this is a new site and I haven't yet done anything with Group, so who knows if all is well.

Hi @smustgrave, that issue doesn't fully solve the issue that this issue brings up. While it will return something that isn't 200x113 if you set a maxwidth and maxheight, it only does so for the <video>. The enclosing iframe will create black bars around the video depending on the width of the viewport or width of the container the iframe is in. It's definitely better than before though!

Now that #2966656 ✨ Negotiate max width/height of oEmbed assets more intelligently Needs work is in, I think maybe the issue is the styling of the iframe's aspect ratio.

From what I can tell the only CSS that gets added by default to the iframe is:

.media-oembed-content {
  max-width: 100%;
  border: none;
  background-color: transparent;
}

That max-width: 100% keeps the iframe from breaking out of its container, making it responsive, but does nothing for maintaining the aspect ratio. If you have a 16/9 video and shrink your browser down to a mobile width size, the video becomes a square. It will still play the video itself at 16/9, but there will be two huge black bars on top and bottom. Ideally, those won't be there.

Using CSS like in #3 won't work as that will affect ALL oEmbeds, such as podcast players, 3D models, etc. Anything that can be embedded via oEmbed by the oEmbed Providers module for example. I tried it and had a too tall Podbean player.

I tested a YouTube embed in WordPress, both a 16/9 one and a different video (https://www.youtube.com/watch?v=UDIQwGb-4YQ) that isn't 16/9, but it looks like WP always embeds at 16/9 and you're just stuck with black bars. So maybe that's the answer here, you'd just need to deal with it in your theme. But if we could manually choose what we want the video's aspect ratio to be, on a per-video basis, that would be great. I'm not sure how to do that though.

For the record, changing the above code to this:

.media-oembed-content {
  max-width: 100%;
  border: none;
  background-color: transparent;
  aspect-ratio: 16/9;
  height: auto;
}

will get rid of the black bars, but then you're hard-coding the aspect-ratio for all oEmbeds. which isn't good. The only thing I can think of is a field on the media item that lets you select an aspect ratio, and then it will add CSS classes (or inline styles) to the media item somehow. 🤷🏻‍♂️

So is this issue considered closed and what's linked by @imclean is the solution (setting a maxwidth and maxheight manually in the field display)?

FYI, the solution in #62 should not be the solution, as this affects all oEmbed iframes. I tested it out and my Podbean oembed was sized to 16/9 so there was now a huge whitespace gap up under the podcast player. May work fine for YouTube videos that happen to be 16/9, but not all videos will always be 16/9.

For anyone who may wonder about this and why there is no "expert", @entropea is using the Display Suite contrib module here. Just FYI.

It seems like many websites use the idea of "pin" as mentioned previously, I'm +1 on renaming it "Pin to top of lists" or similar.

Just encountered the same error message when adding a new view mode to the Document media type; paired the allowed list in the field to "txt, rtf, doc, docx, ppt, pptx, xls, xlsx, pdf" and it bypasses for now.

I have written a tutorial that explains the steps to add Smart Date to an existing site's event system, which may be more what you need.

I just ran into this same issue, and the link goes to Schema.org Blueprints. A Google search isn't returning anything helpful. Can you link the tutorial here?

I wonder where this fits now that we have SDC, and Experience Builder is in early development?

Just tested—working for me! This just made my day for reals.

Screenshots below.

Very much in favor of this! It makes not only seeing the site hierarchy much easier and quicker, but you can also drag and drop the components in the view in a much more user-friendly manner. It doesn't work that way in Figma though unless you have auto-layout turned on.

Here's WordPress' implementation:

dalemoore → created an issue.

I don't see why we can't just stick with "Drupal" for the new product name, but refer to it as "Drupal CMS" under the hood/as developers, and "Drupal Core" for the framework/version with no extra modules/themes/recipes/whatever added. Basically what we already do?

WordPress refers to itself as "WordPress Core" for the version with no other themes and plugins installed. See here for WordPress Core. ("Never edit WordPress Core!") But generally, just "WordPress"...

If you mouseover "core" in the link, it says:

Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

That sounds like the equivalent of Drupal Core.

If it works for WordPress, the most-used CMS in the world, don't see why not also for Drupal?

Either just "Drupal", or "Drupal CMS", are the only two options that make sense. The only other thing I can think of is "Drupal XP" for Experience Platform, so that we can abbreviate it "DXP", same as digital experience platform.

I am running into the same issue. I set up two DDEV instances, one as a "test" instance, and the other as my hopefully final site after testing Group. The first time I enabled the module via Drush and had no issues. This time I decided to install it via the UI and was immediately met with the 'The "group_relationship_type" entity type does not exist' error.

I'm running into this issue after just installing Group. Tried to go and create my first group following the docs and immediately get the error. And now I get it any time I go to /admin/group.

The website encountered an unexpected error. Try again later.

Error: Call to a member function getPluginId() on null in Drupal\group\Entity\Storage\GroupRelationshipStorage->getEntityClass() (line 93 of modules/contrib/group/src/Entity/Storage/GroupRelationshipStorage.php).

Drupal\Core\Entity\EntityFieldManager->buildBundleFieldDefinitions('group_relationship', 'microsite-group_membership', Array) (Line: 353)
Drupal\Core\Entity\EntityFieldManager->getFieldDefinitions('group_relationship', 'microsite-group_membership') (Line: 1219)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables(Array, ) (Line: 503)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->mapFromStorageRecords(Array) (Line: 428)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage(Array) (Line: 394)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array) (Line: 312)
Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array) (Line: 84)
Drupal\group\Entity\GroupMembership::loadByUser(Object, NULL) (Line: 68)
Drupal\group\GroupMembershipLoader->loadByUser(Object) (Line: 58)
Drupal\group\Access\IndividualGroupPermissionCalculator->calculatePermissions(Object, 'individual') (Line: 138)
Drupal\flexible_permissions\ChainPermissionCalculator->calculatePermissions(Object, 'individual') (Line: 41)
Drupal\group\Access\GroupPermissionCalculator->calculateFullPermissions(Object) (Line: 40)
Drupal\group\QueryAccess\GroupQueryAlter->doAlter('view') (Line: 150)
Drupal\group\QueryAccess\QueryAlterBase->alter(Object, Object) (Line: 336)
group_query_entity_query_alter(Object, NULL, NULL) (Line: 545)
Drupal\Core\Extension\ModuleHandler->alter('query', Object) (Line: 495)
Drupal\Core\Database\Query\Select->preExecute() (Line: 503)
Drupal\Core\Database\Query\Select->preExecute() (Line: 520)
Drupal\Core\Database\Query\Select->execute() (Line: 266)
Drupal\Core\Entity\Query\Sql\Query->result() (Line: 84)
Drupal\Core\Entity\Query\Sql\Query->execute() (Line: 316)
Drupal\Core\Entity\Query\QueryBase->initializePager() (Line: 245)
Drupal\Core\Entity\Query\Sql\Query->finish() (Line: 83)
Drupal\Core\Entity\Query\Sql\Query->execute() (Line: 161)
Drupal\group\Entity\Controller\GroupListBuilder->getEntityIds() (Line: 88)
Drupal\Core\Entity\EntityListBuilder->load() (Line: 241)
Drupal\Core\Entity\EntityListBuilder->render() (Line: 141)
Drupal\group\Entity\Controller\GroupListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing('group')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 53)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\tracer\StackMiddleware\TracesMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Are these the same templates that will be offered in the CKEditor 5 Plugin Pack from CKSource → ? It's a premium feature in standalone CKEditor 5 but will be free via the Drupal module.

I was exploring this module and discovered it didn't support U.S. counties as well. This would be a great feature for using the module for local, regional, and state entities as well as some university units like where I work. A lot of our work is county-based at land-grant university Extension services. It would also be useful for sites related to voting, as people are restricted to only voting within their specific state, county, and city. County is missing in that scenario here.

Just tested, and working great with no error! Thanks for the fix.

dalemoore → created an issue.

I wonder if it would be possible to take a page from Layout Builder Component Attributes → and have a different setting in the contextual menu just for the block style settings? If you have that module enabled, for a block you get four options:

• Configure
• Manage attributes (this is the menu item the module adds)
• Move
• Remove block

Then you could continue to edit the block content through "Configure", which will open in a modal window, but control the Bootstrap Styles under a separate link within the contextual menu so that they're in the right-hand tray not the popup.

Thanks! Yes, that fixes it!

I guess I didn't think of that because I want the user to be able to select from options that are labeled meaningfully, so I wanted "Full content" or "Layout Builder" (really the full view mode, which is the only one Layout Builder overrides work with currently ✨ Consider supporting Layout Builder Overrides for other view modes Needs work ) to be an option they can select. Hence the making it required and wanting the "Full content" option to be selectable under "View modes allowed to switch to", so there would be no option "- No change -" which I felt was confusing. Could I perhaps configure what that "no change" option says on a per-field basis, even if in code? Maybe it could be added in the form display widget?

Thanks!

Here is a detailed description. This is on the standard profile 'page' content type.

Manage fields

1. I've added a view mode switch field labeled "View mode" with machine name "field_view_mode".
2. Under field storage, "view modes to switch", the only view mode selected is "Default". Full content is not checked because if I check it it removes it from "View modes allowed to switch to".
3. The field is set to "required"
4. Under "View modes allowed to switch to", I have selected:
   • Full content
   • Standard
   • Teaser
5. Under default value, I have it set to "Full content".

That's it for the field setup.

Manage form display

The field is just setup with the defaults here.

Manage display

1. In custom display settings, I have enabled "Full content", "Standard", and "Teaser" view modes (Standard is a view mode I manually created).
2. I have "Use Layout Builder" and "Allow each content item to have its layout customized" enabled on the Default view mode.
3. On the Standard view mode, I don't have anything Layout Builder enabled, just the normal field/label/format view.

So I just did a little testing with Twig debugging enabled.

If I only use this module, and I inspect the source code, the Twig suggestions for the node.html.twig never change on the Layout Builder-enabled content type. No matter what I select in this module's field dropdown, I always get this:

<!-- FILE NAME SUGGESTIONS:
   * node--281905--full.html.twig
   * node--281905.html.twig
   * node--page--full.html.twig
   * node--page.html.twig
   * node--full.html.twig
   x node.html.twig
-->

If I instead enable Display Suite's view mode switcher and change it to a different view mode, the Twig suggestions are updated to the new view mode's name.

<!-- FILE NAME SUGGESTIONS:
   * node--281905--standard.html.twig
   * node--281905.html.twig
   * node--page--standard.html.twig
   * node--page.html.twig
   * node--standard.html.twig
   x node.html.twig
-->

dalemoore → created an issue.

I was banging my head against the wall trying to figure out why these weren't working on a new site I'm working on, having the same issue I was having last year in No other token format available or accepted besides the default one 🐛 No other token format available or accepted besides the default one Fixed , this fixes it for me for now. Trying to use the tokens in the URL for the same as before.