Hello Bao & Joseph,
Icon API has landed in Drupal 11.1: https://www.drupal.org/node/3490350 →
If you have questions about how to use it, don't hesitate to ask. I would also be pleased to meet you in Paris if neeeded.
Hello,
Icon API has landed in Drupal 11.1: https://www.drupal.org/node/3490350 →
If you have questions about how to use it, don't hesitate to ask.
Hello,
Icon API has landed in Drupal 11.1: https://www.drupal.org/node/3490350 →
If you have questions about how to use it, don't hesitate to ask.
Hello,
Icon API has landed in Drupal 11.1: https://www.drupal.org/node/3490350 →
If you have questions about how to use it, don't hesitate to ask.
Hi Gregory,
Do you use UI Patterns ? You need to install ui_icons_patterns sub-module.
In a SDC component, if you have a prop schema like this:
type: object
properties:
pack_id:
"$ref": "ui-patterns://identifier"
icon_id:
type: string
settings:
type: object
required: ['pack_id', 'icon_id']
Or, more simply, like this:
"$ref": "ui-patterns://icon"
Your prop will be recognize as an icon and managed by UI Icon (with the icon picker).
Then, inside the Twig template, you can use the Drupal Core's icon() Twig function with this mapping's values.
Is it clear?
Look Ok to me:
- the select list close on selection
- no weird behaviours noticed
- the diff is small
Thansk you. Indeed, we need to implement CategorizingPluginManagerInterface in StoryPluginManager and use ::getSortedDefinitions() in ::getComponentStories()
Hi guys,
Things are taking shape, that's great.
In toolbar-button.twig
{% if icon is empty %} does not work
{% if icon|render is empty %} works
Early rendering must be avoided in a template, so no |render() filter here (maybe we need to deprecate this filter one day).
Let's not merge until {% if icon %} is enough. Is there something we need to change in the Icon API side?
1.1.x MR
https://git.drupalcode.org/project/ui_suite_dsfr/-/merge_requests/148
Looks OK. Have you checked if {% if attributes.storage() %} works as expected?
1.0.x MR
https://git.drupalcode.org/project/ui_suite_dsfr/-/merge_requests/150
Done: https://git.drupalcode.org/project/ui_suite_dsfr/-/merge_requests/153
Let's be careful and do some tests before merging.
It will be a breaking change
I take it. And I will also move bottom menu and content menu from to slot to prop
I am still not very confortable, but I have to admit... it looks OK ;)
So, what do we do in sdc_devel side ? Do we allow defined tests by removing it from "Not needed in Drupal because strict_variables=false." warning ?
Only for boolean (may be hard to detect) ?
Or maybe we adopt a more liberal approach of Twig tests where we only forbid the one we know to be very harmful:
-
constant: related to Drupal installtion -
empty: same as just testing the variable -
null: same as just testing the variable -
same as: too strict for templating, confusing if used with Jinja
https://git.drupalcode.org/project/sdc_devel/-/blob/1.0.x/src/Plugin/Twi...
Check usage of " is not defined" when Twig is used with strict_variables = false (which is the default value in both Twig and Drupal, and expected setting in a component templating point of view):
If set to
false, Twig will silently ignore invalid
variables (variables and or attributes/methods that do not exist) and
replace them with anullvalue. When set totrue, Twig throws an
exception instead (default tofalse).
And how it fit or not with default() filter.
According to the results, we may need to update sdc_devel rules and documentation
Mikael ?
Talked with Christian. If we find a drupal contrib module already providing any content entity (with display mode selection) as a block plugin, we can use the existing BlockSource and we will only need the new context (for filtering).
So, let's have a look. Michael, do u want to investigate?
By the way:
- Ctools is providing a simialr block byt only for displaying another view mode of the same content entity
- Media Library source of UIP Settings 3.0 will also need this new "content" context
FYI Christian is planning a Media Library source in UI Patterns Settings 3.0: https://git.drupalcode.org/project/ui_patterns_settings/-/blob/3.0.x/src...
Grimreaper, I don't reproduce in local. Do you? if yes, what is your setup? How different it si from drupal.org CI?
it may be an sdc_devel error
it is normal for {% set header_length = header|length ? header : 0 %} to be converted into {% set header_length = header ?: 0 %} by Twig when loading as an AST and analysed by sdc_devel
But i don't understand why it is the case for {% set header_length = header ? header|length : 0 %}
grimreaper → credited pdureau → .
if i understood well what you told me during the meeting:
- more stories for components
- update ui-patterns-stories-full.html.twig template override with somethign like that:
--- a/templates/ui_patterns_library/ui-patterns-stories-full.html.twig +++ b/templates/ui_patterns_library/ui-patterns-stories-full.html.twig @@ -10,20 +10,22 @@ <div class="ui_patterns_story__story"> {% if variants and not story.props.variant %} {% for variant_id, variant in variants %} - {{ _self.render_variant(component_id, story_id, variant_id, variant) }} + {{ _self.render_variant(component_id, story_id, story, variant_id, variant) }} {% endfor %} {% else %} {{ component_story(component_id, story_id, {}, {}, true) }} + <pre><code>{{ story|json_encode(constant('JSON_PRETTY_PRINT')) }}{% endif %}
{% endmacro %}
-{% macro render_variant(component_id, story_id, variant_id, variant) %}
+{% macro render_variant(component_id, story_id, story, variant_id, variant) %}{{ variant.title }} (
{{ variant_id }})
{% if variant.description %}
{{ variant.description }}
{% endif %}
+{{ story|json_encode(constant('JSON_PRETTY_PRINT')) }}{{ component_story(component_id, story_id, {}, {variant: variant_id}, true) }}
{% endmacro %}
See https://project.pages.drupalcode.org/ui_patterns/2-authors/1-stories-and...
name: In latin
library_wrapper: '<div class="card">{{ _story }}</div>'
slots:
title: "Dapibus ac facilisis"
subtitle: "Cras justo odio"
props:
heading_level: 5
Beware of the underscore in _story.
2 things to take into account:
- Users may be annoyed when data will start to be automatically injected into their components although this was not the case for 2 years
- It is nice to keep all logic, including default values replacement, into a single unit of code: the Twig template. YAML definition are declarative.
Thanks so much @smovs
However, I’m not entirely sure about the performance impact of this approach.
Hi Christian, can you check this?
Thanks you for your contribution, Fabien.
SDC is not processing https://www.drupal.org/docs/develop/theming-drupal/using-single-director... →
tertiary:
type: string
title: Tertiary
# Provide a default value. It isn't used in Twig template.
default: success
And we agree with that in UI Patterns 2: https://project.pages.drupalcode.org/ui_patterns/2-authors/0-authoring-a...
UI Patterns 2 uses default when building the component form, as #default_value.
default must not be used in the rendering process (sending default value if prop value is missing or empty) because:
- sometimes we want a default value in forms while allowing the user to set empty or missing value
- the |default() Twig filter is the expected tool for such an enforcement
Is it clear? Do you agree?
Work has started
Thanks so much. Can you do a MR?
Oh my god, already one year! I am so sorry. We were so busy on UI Patterns 2.0 development. 2.0.0 was released last week.
Abdullah Yassin, do you still have this issue?
Thanks Tim
@pdureau: finish the editorial work
@mogtofu33: add mkdocs build
Hi Grimreaper,
This is the opportunity of reoganizing our logic: https://git.drupalcode.org/project/ui_examples/-/merge_requests/21/diffs
The MR is not tested and is a bit too verbose and clunky, I will finish the job, but it is a good base for discussion for us.
(Let's not forget this logic must be duplicated in UI Patterns 2, so let's keep it lean).
(Is it the opportunity of supporting #theme => table ?)
It may be because of type: primary which is part of ::RENDER_KEYS
you are proposing to skip both slots and props but may be more complicated (and related to this Core issue: 📌 Compatibility between SDC and the Form API Active )
I will do a little test
will be done in Drupal Core. I will create the issue soon
Let's hope this change will allow {% if attributes %} to resolve to false in twig template when empty
it works with "drush rs"
~/Projects/Drupal/ui_patterns_2/ $ vendor/bin/drush st
Drupal version : 11.1.2
Site URI : http://default
DB driver : sqlite
DB port :
DB username :
DB name : db.sqlite
Database : Connected
Drupal bootstrap : Successful
Default theme : ui_suite_bootstrap
Admin theme : claro
PHP binary : /usr/bin/php
PHP config : /etc/php.ini
PHP OS : Linux
PHP version : 8.3.16
Drush script : /home/pierre/Projects/Drupal/ui_patterns_2/vendor/bin/drush.php
Drush version : 13.3.3.0
Drush temp : /tmp
Drush configs : /home/pierre/Projects/Drupal/ui_patterns_2/vendor/drush/drush/drush.yml
Install profile : standard
Drupal root : /home/pierre/Projects/Drupal/ui_patterns_2/web
Site path : sites/default
Files, Public : sites/default/files
Files, Temp : /tmp
i have http://127.0.0.1:8888/ui_styles/stylesheet?prefix=.ck-content&srblbb without the .css extension:
HTTP/1.1 200 OK
Host: 127.0.0.1:8888
Connection: close
X-Powered-By: PHP/8.3.16
Content-Type: text/css; charset=UTF-8
Cache-Control: must-revalidate, no-cache, private
Date: Fri, 07 Feb 2025 15:50:12 GMT
X-Drupal-Dynamic-Cache: MISS
Content-language: en
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Drupal-Cache-Tags: http_response
X-Drupal-Cache-Contexts: url.query_args:prefix user.permissions
X-Drupal-Cache-Max-Age: 31536000
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-Generator: Drupal 11 (https://www.drupal.org)
Content-Length: 45259
X-Drupal-Cache: MISSI am a afraid this data is not available in a ViewStyle plugin, but we can try
So given that as you say, it's not a display builder, what would this look like?
It provides SDC components for the existing display builders:
- Block Layout: as blocks
- Manage Display: as field formatters
- Layout Builder: as blocks, layouts and field formatters
- Views: as styles, rows and field formatters
So, it doesn't offer a brand new "experience". It just plugs SDC to the existing UI tools. That why I believe it will be a nice and softer transition from old school display building.
UI Patterns 2.0.0 was released yesterday by the way. Here is the documentation: https://project.pages.drupalcode.org/ui_patterns/
Thanks for the feature request.
We will release 2.0 today, so planned for 2.1.
However, let's try to avoid hook_theme(). and anything related to the crufty ThemeManager::render()
Reviewed by @e0ipso.
Reviewed by @grimreaper on behalf of @pdureau
Ok for us
pdureau → created an issue. See original summary → .