Een hart voor de Drupal Community

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

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

Thanks for the feedback. I'm working on a fix. Might take me a few days to push some code though...

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

Linking issue in AI module, that complicates this functionality.

svendecabooter created an issue. See original summary.

Problem/Motivation

Currently, the logic in AI Translate module assumes all textual content to be translated is in the fields 'value' property. See \Drupal\ai_translate\Controller\AiTranslateController::translateSingleText().

There are scenario's where text-to-be-translated will not be stored in the 'value' property though. Some examples:

• Issue for link field translation: #3529669: Handle link field translation as well - although this works around the limitation by putting the link title into the 'value' property upon extraction. Only works if there is 1 property to be translated though.
• #3529794: Add support for AI submodule "ai_translate" FieldTextExtractor plugin: Custom Field module, which allows any arbitrary name to be used for the subfield / property that gets defined.

Proposed resolution

Make the property name to extract part of the metadata, and set it dynamically, instead of hardcoded 'value' property? I haven't dug deeper into the full architecture, to know if this is possible...

Problem/Motivation

The AI module's submodule "ai_translate" provides content translation service through AI. It provides a plugin called FieldTextExtractor, which allows it to extract textual data from different kinds of field types, in order to pass those to an AI service for translation.

Textual subfields provided by the custom_field module do not get translated through that mechanism, because there is no support for it in this module.

Steps to reproduce

- Install custom_field, ai & ai_translate modules - Set up a custom field with textual data - Try to translate an entity containing this field, via the AI translation mechanism

svendecabooter created an issue. See original summary.

Thank you for picking this up this quick!

Fons added a comment on drupal.org: When building a webform and saving elements the succes message is rendered behind the drupal sidebar

I've added a merge request that fixes the problem for me.

The message is rendered above the sidebar, it disappears after a few seconds so this behaviour is more desirable than an unreadable message.

f0ns created an issue. See original summary.

Problem/Motivation

When building a webform and saving elements the succes message is rendered behind the Drupal sidebar.

This is the topic for another discussion but I've always wondered why Webform has it's own way of showing messages instead of using the standard way that is provided in Drupal.

Steps to reproduce

Build a webform, add some form elements and click the save elements button.

I applied the MR logic from #3508748: [2.0.x] Add ability to track active menu items in menu source. Then in ui_suite_daisyui:menu component, I add a check:

{% if item.in_active_trail %}
      <!-- Try adding extra class here -->
{% endif %}

That doesn't seem to work... Maybe I'm missing some additional context

svendecabooter changed the visibility of the branch 3528586-support-drupal-core to hidden.

OK it should be possible after all I think.

Say we can integrate with the contrib Default Content module, to produce output as follows:

field_logos:
    -
      logo:
        entity_type: 'media'
        entity: eab657e0-3320-41d2-ab4e-53a09b397758
      link: 'https://google.com'
      link__title: ''
      link__options: { }

(if not possible, worst case we need to document the exported YAML files have to be manually edited).

Then in CustomFieldEntityReference::setValue(). we can do something like:

  /**
   * {@inheritdoc}
   */
  public function setValue($value, $notify = TRUE): void {
    $entity = $value['entity'] ?? NULL;
    // START ADDED LOGIC.
    if (is_array($value)) {
      if ($value['entity_type'] && Uuid::isValid($value['entity'])) {
        $entity = \Drupal::entityTypeManager()->getStorage($value['entity_type'])->loadByProperties(['uuid' => $value['entity']]);
        $entity = !empty($entity) ? current($entity) : NULL;
      }
    }
    // END ADDED LOGIC.
    if ($entity instanceof EntityInterface) {
      ...
   }

I can spend some time to look further into this, but am currently time restrained, so just doing some braindump here. Will try to elaborate on it next week. Let me know if it would be a workable solution to extend the setValue() logic, for the use case of default content exports / imports.

Did some more digging, and it seems the datatype used in custom_field module is "CustomFieldEntityReference", which does not inherit from core "EntityReference" data type, so guess this will never work :'(

Problem/Motivation

I have created a custom_field instance with the following properties: - logo: entity reference to Media entity - link: link field

In a recipe, I'm using the Drupal core DefaultContent API to add default content upon application of the recipe. However, this does not work well with the custom_field I have.

When I export the node containing this field (with the contrib Default Content module), I get something like:

field_logos:
    -
      logo: 14
      link: 'https://google.com'
      link__title: ''
      link__options: { }

Obviously directly linking to media ID 14 won't work, because the recipe will be installed on a site that might have different auto-increment IDs.

I tried editing this to use the entity UUID, like other entity references exported via Default Content module:

field_logos:
    -
      logo: eab657e0-3320-41d2-ab4e-53a09b397758
      link: 'https://google.com'
      link__title: ''
      link__options: { }

This doesn't work either.

Looking deeper into the core Importer class (\Drupal\Core\DefaultContent\Importer::setFieldValues()), I notice this only works for EntityReference data types: if ($property instanceof EntityReference) { ... } (full namespace = Drupal\Core\Entity\Plugin\DataType\EntityReference)

I'm not familiar enough with the data model of custom_module, but I assume this uses something custom, instead of the core EntityReference data type, and thus does not set the value correctly. Would there be any way to make this work (without hacking core I presume)?

svendecabooter created an issue.

1.2.2 has been released now

Sven Decabooter added a comment on drupal.org: Fix GitlabCI cspell + phpcs warnings

Thanks a lot!