🇦🇺Australia @NicolasH

I went through exactly the same issue, including VBO and ajax not resolving this. Only thing to add that I started with an embed display, same thing, then switched to block.

Also agree with richarddavies that "by design" is a bit of a stretch. I have not come across other situations where different displays inherit properties without there being a way to overwrite it per display. I get that there is no page path on a block or embed where I could possibly overwrite it, but in that case it should be implied, not borrowing from another display without any indication that it's doing so.

IF a redirect path is required in scenarios like exposed filters and VBO, maybe this could be a setting with replacement patterns? And even if ajax is solving the exposed filters case, most users will see ajax as an option, not a requirement I'd say.

Thanks for clearing that up. Trying to maintain the emphasis on the original request, which is that the current description easily leads to the assumption that this utilises the site configuration system. Don't think this needs to get into layout storage comparison at this point, but might be useful in some more detailed doc?

Anyway, leaving it for others to refine this further if needed.

gargsuchi → credited NicolasH → .

Kristen Pol → credited NicolasH → .

Yep, fine with me. Just noticed there's test failures, but they don't seem to be related to any of these changes. Not sure if it's due to how the MR was set up.

I was initially confused by the description as well. It's correct, just that "configuration" is a bit ambiguous in this context. Took a stab at clarifying that it's concerning block configuration/settings.

This hopefully makes it clear that it's quite lightweight and essentially content on the entity, rather than something that from then on needs to be managed via Drupal config commits.

NicolasH → made their first commit to this issue’s fork.

FWIW, outcome was still as in #7. I ended up with the same twig filter workaround and agree with Idiaz that it doesn't feel like a good solution.

None of the suggestions solve the issue when needing to map a URL in a view with twig debug on AFAICT. But not sure what further info can be provided.

Update on my comment above...

I checked whether any different selectors are applied on the VBO checkboxes in a DT display, but doesn't look like it. And then I realised that the very first time a DT display is loaded, the select-all and shift-select works just fine. It's only after filtering the DT display that those stop working.

My guess it's more an issue with how VBO runs these, but need to look into it more.

I know this is an old issue, but I also wanted to run a bulk operation on a set of data from a DT display. At least I assume that this issue is about that, rather than some deeper merging of functionality.

AFAICT there is only one UI bug preventing these from working seamlessly together right now, and that is that the VBO "Check all" box on top of a table display does not work. Neither does shift-selecting a range of table rows.

However, selecting checkboxes individually per row makes the VBO part behave just as it would with a standard table display, so there's no inherent incompatibility between the 2, just a front-end mismatch.

Right, I see, thanks for that. I stumbled across this by accident myself when putting in some settings like any other field and it just worked.

My only comment would be that the twig function reads a bit nicer with the settings in their own array, especially is there are a large number of fields and settings. It also makes more sense when using it both in the UI as well as twig.

Also, I've been using a separate #settings array key in render arrays and it works fine. I can't remember whether I just tried it out or whether it's somewhere in the documentation. After reading your comment I tried to just move them into the #fields array and yes, works just the same. Again, the readability will have me probably leaving them separate.

$build[['register_link'] = [
      '#type' => 'pattern',
      '#id' => 'dialog_button',
      '#fields' => [
        'url' => $create_account_url,
        'text' => t('No account? Sign up'),
      ],
      '#settings' => [
        'link_type' => 'button_primary',
        'size' => 'm',
        'icon_classes' => 'fa-solid fa-user-plus',
      ],
    ];

This worked for me.

Just a note that the other issue mentioned above ( https://www.drupal.org/project/video_embed_field/issues/3371353 🐛 VideoEmbedWysiwyg::getValidMatches() does not detect two videos next to each other Needs review ) actually does fix the rendering of multiple videos in one field, at least for me. I did not apply the patch, I just manually replaced that one line after applying the work in this issue.

Nice! Can confirm it's working here.

Yes please, this makes perfect sense. I wouldn't use UI Patterns at all if it wouldn't have the option to use it in render arrays and twig files apart from the UI options...as this allows to use the same patterns in more complex scenarios as well and still keeps it consistent.

I actually thought this was already built in here and was looking for documentation on it.

I've tested the patch on only one scenario for now and it works well. Will update if I find anything with more scenarios.

Thanks, I will use that module anyway eventually, so just tested it for this.

I chose the attributes type with this definition:

settings:
    href:
      type: attributes
      label: href
      expose_as_field: true

I need to use the expose_as_field option, as otherwise I can't map it in the view, I don't have a token.

Unfortunately I end up with the same result.

Now I think it would be reasonable to strip html comments in something like an attribute setting, so it still might be the best option to follow up in that module. Just posting this here as well in case I've missed something about your suggestion.

Patch worked fine here.

NicolasH → created an issue.

Yes, can confirm as well. Pasting full output below:

Additional uncaught exception thrown while handling exception.
Original
PDOException: SQLSTATE[HY000] [2002] Connection refused in Drupal\Component\DependencyInjection\PhpArrayContainer->createService() (line 79 of /code/web/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php).

Drupal\Component\DependencyInjection\PhpArrayContainer->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 212)
Drupal\Component\DependencyInjection\PhpArrayContainer->resolveServicesAndParameters() (Line: 62)
Drupal\Component\DependencyInjection\PhpArrayContainer->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 565)
Drupal\Core\DrupalKernel->getCachedContainerDefinition() (Line: 942)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 487)
Drupal\Core\DrupalKernel->boot() (Line: 716)
Drupal\Core\DrupalKernel->handle() (Line: 19)
Additional
Error: Class "Drupal\error_page\ErrorPagePhpErrorLogger" not found in Drupal\error_page\ErrorPageErrorHandler::logError() (line 179 of /code/web/modules/contrib/error_page/src/ErrorPageErrorHandler.php).

Drupal\error_page\ErrorPageErrorHandler::logError() (Line: 102)
Drupal\error_page\ErrorPageErrorHandler::handleException()

Just a quick note that the patch in #18 just worked for us. This was on a view using ajax filters. An additional problem was that it wasn't obvious without using the filters, arriving at the default page looked completely fine, it only happened once using the filters.

Our setup is a bit unusual, as we're using an admin theme as both front-end and admin theme. The patterns themselves are provided by a module.

Kristen Pol → credited NicolasH → .