Een hart voor de Drupal Community

Fons added a comment on drupal.org: Admin toolbar height is not 100% since upgrading to Drupal 11.2

As reported in #3526471: [5.0.0-alpha3] Menu items do not get is-active class, this MR fixes the issue for me in ui_suite_daisyui for me, after adding some extra logic in the menu component of that theme.

I think having active menu items is pretty basic expected behaviour for a theme, so would be good to get this included sooner rather than later. Having to patch both a module and theme to get a visual indicator of the active menu item, isn't the best situation for getting adoption IMHO. Therefor I took the liberty to increase the priority of this issue. Feel free to lower priority if you disagree.

I fixed this by applying the patch in #3508748: [2.0.x] Add ability to track active menu items in menu source and adding the following to the ui_suite_daisyui:menu component:

(...)
  {% for item in items %}
  <li{{ (not item.url and loop.first) ? ' class="menu-title"' : '' }}>
    {% set item_attributes = item.attributes|default(create_attribute()) %}
    {# Start adding class for menu active trail #}
    {% if item.in_active_trail %}
      {% set item_attributes = item_attributes.addClass('menu-active') %}
    {% endif %}
    {# End adding class for menu active trail #}
    {% if item.url %}
(...)

Not sure if this logic can already be incorporated into ui_suite_daisyui, while waiting on its commit in ui_patterns. It would be good to have this already in place by the time ui_patterns gets updated, but not sure what the policy is there...

Thank you for testing, i’ll leave it on needs review for now and see if we can have an extra pair of eyes on this one.

Fons added a comment on drupal.org: Notice: Debug: Drupal\Core\Render\Renderer::render with $is_root_call is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. After upgrading to Drupal 11.2

I found two occurences and altered these to renderRoot(). This fixes the issue for me.

https://git.drupalcode.org/project/leaflet/-/merge_requests/59.patch

Problem/Motivation

After upgrading to Drupal 11.2 I get the following notice:

Debug: Drupal\Core\Render\Renderer::render with $is_root_call is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. Use Drupal\Core\Render\Renderer::renderRoot() instead. See https://www.drupal.org/node/3497318. in Drupal\Core\Render\Renderer->render() (line 218 of core/lib/Drupal/Core/Render/Renderer.php).

Steps to reproduce

Upgrade to Drupal 11.2 and visit a page that uses the drupal/leaflet module.

f0ns created an issue. See original summary.

Fons added a comment on drupal.org: Admin toolbar height is not 100% since upgrading to Drupal 11.2

I've added the css to fix this:

https://git.drupalcode.org/issue/drupal-3531516/-/commit/8fda91d0d4805a5...

I've patched my sites with it and everything works as expected now.

Problem/Motivation

When upgrading to Drupal 11.2 I noticed the admin sidebar height is not 100% anymore, before the upgrade this wasn't an issue.

Steps to reproduce

Upgrade to Drupal 11.2 on a website that uses the Core (Experimental) Navigation module.

f0ns created an issue. See original summary.

I'm not sure if this is the right place for this feature request, but I would propose to add an alter hook to the getFeaturedPageActions() method. In my case, I want a custom entity to have another "featured action", rather than the edit form. Currently I don't see a way to achieve this. IMHO core should provide sane defaults, but allow the option for contrib / custom module to change the default behaviour.

EDIT: Just noticed this is a "TopBarItem" plugin, so I can probably achieve this with a custom plugin. Looking into that now.

Sven Decabooter added a comment on drupal.org: Add support for AI submodule "ai_translate" FieldTextExtractor plugin

Sven Decabooter added a comment on drupal.org: Add support for AI submodule "ai_translate" FieldTextExtractor plugin

The logic in the MR now seems to work for most of the custom_field property types I have tested. Still WIP:

• Link field is a challenge. The link itself gets translated currently, since it's a string. However source link https://google.com gets translated in my OpenAI instance to \nhttps://google.com\n, where the extra newline characters mess up the data. Ideally the link itself shouldn't go to translation...
• Image alt / title texts do not get translated yet, because their property is not a string DataType, but rather an entity reference...

Thanks for the commit!

We use Single Directory Components in our themes, so using a custom template override allows us to render the custom_field through a SDC component. E.g.:

{{ include('themename:card', {
  label: item['label'],
  title: item['title'],
  subtitle: item['subtitle']
  body: item['body'],
}, only) }}

Sven Decabooter added a comment on drupal.org: Use property keys for custom_field theming

Problem/Motivation

The custom_field template has an "items" variable, which contains an array of subfield / property render arrays. The default implementation of templates/custom-field.html.twig just loops over each subfield / property and renders it.

When trying to create an override template, we might want to render some subfields specifically, but that is currently not possible (except by doing some inspection of the array, not that easy to do in Twig), because the items array just has numeric keys.

Preferably the "items" array would not have numeric keys, but use the subfield / property key. This way, specific properties can be correctly extracted from the "items" array, to specifically render it (e.g. when using SDC, each custom_field property could be an SDC "prop" or "slot".

Steps to reproduce

- Create a custom_field named "field_something" (unlimited values) with 2 properties, e.g: - "heading": Text (plain) 255 - not required - "text": Text (formatted) - not required - Override the specific Twig template for this field - e.g. custom-field--field-something.html.twig:

<h2>{{ item[0] }}</h2>
<p>{{ item[1] }}</p>

- Use this field somewhere (e.g. on a node type), and fill in both properties. It works as expected. - Use this field somewhere else. and just fill in the "text" property. --> Now the body text is printed within the h2 tag...

Proposed resolution

Allow writing the example above as follows:

<h2>{{ item['heading'] }}</h2>
<p>{{ item['text'] }}</p>

svendecabooter created an issue. See original summary.

As per conversation in #ai on Slack, moving this to 1.2.x branch, since it's a new / extra feature.

As per conversation in #ai on Slack, moving this to 1.2.x branch, since it's a new / extra feature.

I'm encountering the same issue when using Heroicons.

Could a new release be tagged with this improvement?

Patch file included for composer-based patching workflows.

OK I think this should be doable, but it would require the patch in #3529802: Don't hardcode 'value' key for textual field translation to be committed first. Not sure how fast that can happen, so this extra plugin probably won't be committed into custom_field, before that issue is resolved. I'll try to get the MR here working in combination with that issue, and hopefully keep it as simple as possible.

Currently there is some logic that checks if a custom_field subfield / property is translatable or not. But ideally that should check if that subfield is textual or not. Is there some mechanism in place to do that? I guess just doing checks on CustomFieldType plugin instances? I.e. StringType & StringLongType?

Problem/Motivation

I am using the "custom_field" module, for custom fields within Layout Builder blocks. To get those translated via the AI Translate module, the following patch is needed: #3529802: Don't hardcode 'value' key for textual field translation. Once this patch is applied, this works with this module, except for one code check, where the hardcoded 'value' property is checked.

Proposed resolution

Do not rely on the hardcoded 'value' property to be present.

svendecabooter created an issue. See original summary.

Created a merge request that abstracts out the hardcoded 'value' logic. If the FieldTextExtractor plugin returns an array of type ['value' => 'Some text'] in their extract() method, everything should keep working as before. But if the FieldTextExtractor plugin returns more dynamic properties, e.g. via the custom_field module, this would now work. Example data in the extract() method for a "custom_field" FieldTextExtractor would then be:

['question' => 'Some question'. 'answer' => 'Some answer']

The changed logic applies both to the translation via the UI (Controller class) or via Drush. Ideally, both should be refactored to abstract out logic that is the same in both implementations, to allow less code duplication, but that seems out of scope for this issue.

Thanks for giving this some thought / review.

Sven Decabooter added a comment on drupal.org: Don't hardcode 'value' key for textual field translation