Problem with SDC on component with multiple inputs, solved by using [] on name in the component.
We tried to create a lat/lon component with geofield, not working because of applicative
logic into the field type.
Checkbox in form API directly: OK
Checkboxes in form API directly: OK
Usage of names to handle multiple inputs.
Problem of unchecked checkbox currently handled in Checkbox.php form element, workaround in field widget in UIP 2.
TODO:
- field storage and field setting mapping into the component
- test checkboxes as field widget
- test with multiple values fields in field widget
- handle data type constraints?
With the fix from 🐛 Incorrect render structure in Navigation PageContext Active , the proposed changes in Renderer and ComponentElement do not break existing tests.
grimreaper → created an issue.
Demo gif in #3508641-12: Define form elements from SDC → .
Pushing current work state before cleanup.
Before cleaning my workspace, here is the result of friday at the end of DDD 2025.
grimreaper → made their first commit to this issue’s fork.
Ok, we found a way to get rid of the #name. Just need to ensure no numeric key.
Before:
$form['component_card'] = [
'#type' => 'component',
'#component' => 'core_sdc_form:card',
'content' => [
'#type' => 'component',
'#component' => 'core_sdc_form:card_body',
'content' => [
[
'#type' => 'textfield',
'#title' => $this->t('Textfield in content'),
],
],
],
];
After:
$form['component_card'] = [
'#type' => 'component',
'#component' => 'core_sdc_form:card',
'content' => [
'#type' => 'component',
'#component' => 'core_sdc_form:card_body',
'content' => [
'foo' => [
'#type' => 'textfield',
'#title' => $this->t('Textfield in content'),
],
],
],
];
#name is not usable as it is right now because of Ajax.
Currently poking a field widget which will be able to use components, the settings form is broken.
In MR https://git.drupalcode.org/project/drupal/-/merge_requests/11866, I removed what is only for 📌 Define form elements from SDC Active so that in this issue, we can focus only on SDC and Form API compatibility.
MR created from https://git.drupalcode.org/project/drupal/-/merge_requests/11866, so now in this other issue MR, I can remove what is purely to have form element as SDC component.
When you have time, to get your opinion on this beginning of integration.
Yesterday session is online: https://www.youtube.com/live/6AvlzYN17Rs?t=25741s
Until presentation support is posted somewhere you can go give a look.
From @nod_ feedbacks, I am:
- creating another branch with containing only core changes.
- creating a dedicating plugin instead of altering ComponentElement
- need to find a way to make submitted values work without using #name
Suggestion added.
Thanks!
Please give more details of what is your usage.
PageTop->alter() is just an OOP wrapper around hook before Core had the ability to declare hooks in classes with PHP attribute. So its signature should match the hook one. It is not intended to be reused anywhere in the code.
What can be done is part of PageTop->alter() could be extracted in a service or put directly into the UiSkinsUtility class.
grimreaper → made their first commit to this issue’s fork.
grimreaper → created an issue.
Hello,
Stuff like item.in_active_trail is already possible.
When using a pattern with menu source. Active trail is present but not set properly.
Tested the MR and it fixes the issue.
Thanks.
Not merging because main UIP2 maintainers are now @just_like_good_vices and @christian.wiedemann, so maybe needs automated tests.
Hello,
As you are unblocked for your projects by using MR/patch, like you mentioned a global/generic solution should be put in UI Patterns. So closing this issue.
grimreaper → created an issue.
Discussed with @pdureau,
"Need to be able to handle background image on block contents by adding a media field on the block type and so view displays could use it with tokens."
Need Display Builder, or another source doing complicated stuff with tokens for that need.
Let's discuss if it is needed and if current state could be merged.
Ok,
Thanks for your feedback.
Do no hesitate to reopen if needed.
Should it be done in the menu source or in the links prop type?
Currently the active trail is put as attribute in Links prop type, then I would say you play with that in your templates.
In UI Suite Bootstrap, I kind of follow what core does with either JS for authenticated user or event subscriber for anonymous users (need the companion module in 🌱 [Discussion] blocked implementations and generic stuff Active )
g4mbini → credited grimreaper → .
grimreaper → changed the visibility of the branch 10.1.x to hidden.
grimreaper → created an issue.
- Delete news content type
- add listing bloc of blog posts
- carousel of blog post
- tag exposed filter as button links
- default content
MR rebased.
Patch for Composer.
It seems that this had never been merged.
Updated patch regarding 🐛 LB: Filter by block name broken Active and fix removal of .
Split properly overrides for Layout Builder, Layout Builder Browser and Section Library support between UI Suite Bootstrap and UI Suipte Bootstrap Companion in 🌱 [Discussion] blocked implementations and generic stuff Active
Hello,
Could you provide the example code to reproduce the bug please?
And try to provide a MR based on what you spotted in the other Bootstrap theme?
will put LBB specific stuff in companion module.
For LBB, it needs the ui_suite_bootstrap_companion module from 🌱 [Discussion] blocked implementations and generic stuff Active
Same with Layout Builder Browser
grimreaper → created an issue.
Hi,
@catch, this is something I have been thinking about too to avoid loading unused CSS on all pages.
-
✨
Add Bootswatch themes
Active
-
📌
Starterkit: split Bootstrap CSS per component
Active
Like with UI Icons or UI Skins, adding a "library" key to a style declaration could be possible. Then is a style of this declaration is used, the library could be automatically attached.
Problem would be in some "free" areas not connected to UI Styles like WYSIWYG, or link class attributes, (same problem regarding components BTW), to detect automatically that a class is used then search for matching style and so library... This can quickly become tricky. Especially if sometimes the same CSS class is declared in multiple style declarations.
Funny that you mention "clearfix, container-inline", those classes are also in Bootstrap, and in UI Suite Bootstrap I have removed them:
libraries-override:
...
system/base:
css:
component:
css/components/clearfix.module.css: false
css/components/container-inline.module.css: false
...
And the case you mentioned, would this mean that Core should have declared libraries with one small CSS file only and properly attach only when needed?
Shown to @pdureau before creating the issue.
grimreaper → created an issue.
grimreaper → created an issue.
Hi,
Thanks both of you for your replies.
Then in case I will adapt my code to only manipulate the body.
grimreaper → created an issue.
Thanks a lot for the followup.
I put one review comment.
Hi,
Changing of project as this is not UI Suite Bootstrap related.
Currently, you can define a block content type with an image field or a media field and then use it. But that's not necessarily the best way. Or use the "data from a field".
It depends on your site structure. And not sure that it is the best experience for editors to access component directly. I think it is better to prepare block types (that will use the components with fields) and so the editors only can place blocks.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
Also need to be able to handle background image on block contents by adding a media field on the block type and so view displays could use it with tokens.
TODO:
- refactor display processing
- Form to control which media bundle is available and with which field.
- UI Patterns attributes plugin source
Between:
-
https://www.drupal.org/project/search_api_exclude →
-
https://www.drupal.org/project/search_api_exclude_entity →
Selecting https://www.drupal.org/project/search_api_exclude_entity → because not related to node and much more flexible.
grimreaper → made their first commit to this issue’s fork.
MR rebased.
Here is a new patch from MR to add for projects.
Marking as postponed until ✨ Allow changing the layout of an existing section in Layout Builder UI Needs work is fixed.
grimreaper → created an issue.