Drupal CMS

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.

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

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!

Thanks - committed!

Problem/Motivation

Fix cspell & phpcs warnings, as reported by Gitlab CI.

svendecabooter created an issue. See original summary.

Sven Decabooter added a comment on drupal.org: Add support for showing that attachments were added to the mail

Thanks for the fix, and sorry for the delay in committing.

Sven Decabooter added a comment on drupal.org: Automated Drupal 11 compatibility fixes for symfony_mailer_log

Sven Decabooter added a comment on drupal.org: Error when saving Log Settings

Thanks for the fix. Committed now.

Thanks for looking into this sarvjeetsingh. It hadn't occurred to me that this could be the source of the issue. Fix in MR resolves the issue for me.

Added MR that adds this functionality + a patch file for Composer-based patching workflows. Thanks for considering merging this functionality.

Problem/Motivation

I am using the core patch #3180702: Export block UUID with custom Layout Builder blocks to store a block UUID in config, to allow Layout Builder blocks to be added via default_content export / import functionality.

This does not work together with the logic in this module. The blocks do get translated via AI, but the translation is not correctly saved.

Steps to reproduce

Try this module with the patch mentioned above applied.

Proposed resolution

Some conditional logic could be added to make this work for sites that have this patch applied, while still working as expected for most sites that wouldn't have this patch applied.

svendecabooter created an issue. See original summary.

svendecabooter created an issue. See original summary.