Een hart voor de Drupal Community

Randal added a comment on drupal.org: Problems when uninstalling the module

Together with the patch to default_content mentioned above, this MR allows custom_field data to be exported by default_content, and imported by default_content import OR core's DefaultContent API, used by recipes.

Attached is a patch file for the current state of the MR, useful for Composer based patching workflows.

A patch has been added to default_content module, to make sure the Default Content exported YML files use the UUID identifiers of referenced entities within a custom_field field, rather than their (numeric) entity ID. The patch can be found at #3532596: Add support for custom_field module

Sven Decabooter added a comment on drupal.org: Add support for custom_field module

On the import side of things, there is a patch for custom_field that makes this work: #3528586: Support Drupal core DefaultContent API.

Created an MR that updates custom_field data in the Default Content export for referenced entities.

Original output without this MR:

field_my_custom_field:
    -
      label: 'Exported label'
      image: 21 # Some random file ID
      image__width: 1024
      image__height: 1024
      image__alt: Sunset
      image__title: ''
      file: 22 # Some random file ID
      term: 4 # Some random taxonomy term ID

After applying this MR. this becomes:

  field_my_custom_field:
    -
      label: 'Exported label'
      image: aa6340f0-0006-4f31-9f2d-5595f5cce028
      image__width: 1024
      image__height: 1024
      image__alt: Sunset
      image__title: ''
      file: c36ea199-cd17-4fe5-bec7-beef1ffb51b4
      term: 78ae1ee7-f2d4-4fc0-871e-1af92730df3b

The referenced UUIDs also get added as a dependency to the "_meta" definition.

Problem/Motivation

Add support for the custom_field module, so entities using that field can be exported and imported using Default Content (or Drupal core recipe importer).

Export functionality for most custom_field data types are working out of the box, but the ones referencing entities will export the entity target IDs, rather than UUIDs used by the importer.

Steps to reproduce

- Install Default Content & custom_field - Set up a custom_field field, containing (amongst others) an image field or entity reference field. - Try export / import functionality.

Proposed resolution

- Add support for custom_field entity references in the Normalizer class.

svendecabooter created an issue. See original summary.

Sven Decabooter added a comment on drupal.org: sourceEditing plugin no longer gets enabled automatically in 1.1.x - followup

Problem/Motivation

This is a followup to #3527899: sourceEditing plugin no longer gets enabled automatically in 1.1.x. Not sure if I missed this previously, or the code has changed in the meantime, but the sourceEditing CKEditor plugin gets enabled for the "Completion" AI CKEditor plugin, but is still throwing errors for other plugins, e.g. Spellfix.

Steps to reproduce

- Same as in #3527899: sourceEditing plugin no longer gets enabled automatically in 1.1.x, but use Spellfix instead of Completion

Proposed resolution

- Fix this by enabling the sourceEditing CKEditor for the "response_text" form element in the AiCKEditorPluginBase class.

svendecabooter created an issue. See original summary.

Can you try if the patch in #3531983: Set block entity values via FieldTextExtractor plugins resolves this issue for you?

A better fix for this issue is implemented in #3531983: Set block entity values via FieldTextExtractor plugins

Tested with the changed that got committed into the ai_translate module. Everything seems to work now!

Hi @a8w4,

Thanks for your report! I'm unable to reproduce this issue though, would it be possible to share the exact steps / paths where this issue occurs? As well as let me know if it's reproduceable on a clean D11?

Thanks in advance!

The suggestion indeed also fixes the problem and seems to me that this is a better solution (delete one line of CSS instead of adding one line of CSS).

Please review!

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

MR added for this functionality. Also attaching as a patch file, for Composer based patching workflows.

svendecabooter created an issue. See original summary.

Problem/Motivation

Currently there is logic in LbAsymmetricExtractor that, for each cloned Layout Builder block, loops over the translated data, and sets the values for all fields on the cloned block, via the default Field API ->set() method.

However, a more robust solution would be to use the appropriate FieldTextExtractor plugin for each of the fields to set their value, given their original data was extracted using this plugin, so it would make sense to have the value also being set by the same plugin. This allows each plugin to take care of their own special cases.

This would for example add support for the custom_field module, where a Layout Builder block could contain a custom_field field. The FieldTextExtractor plugin for custom_field (being worked on in #3529794: Add support for AI submodule "ai_translate" FieldTextExtractor plugin would then take care of setting the current values.

Seems related to #3529669: Handle link field translation as well

Thank you sir and sorry for the extra hassle. Have a great day and thank you for the new release.

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

You might be right, I did not notice this css at first.

I’ll test this and get back on this.

Can you test with the provided patches if it also fixes it for you? Here everything works now. Thanks!

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

@xjm it should be fixed now. Thanks!

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...