Below "API Key" there's only
"Geb Sie Ihren API-Schlüssen ein." (which I am happy to translate correctly if the English string is final, German is my mother tongue).
The original "Enter your API key." does not state you have to do so for the free tier as well, either.
It seemed to me like you only need to enter one if you the check the box above. This could be made clearer.
I'd suggest something like
Enter your DeepL Free, Pro or DeepL for Business API key.
And I'd also suggest to change the string below the check box:
If checked, the DeepL Pro API will be used. If unchecked, the free version of DeepL will be used.
to
If checked, the DeepL Pro API will be used. If unchecked, the free version of DeepL will be used. You need an API key in either case.
If I use the bulk translation option, all nested paragraphs do get successfully translated, so this really seems to be very related to the way the form gets created when editing a node manually.
This somehow seems to say that my configuration should not be too far off, right?
I'll try to reduce the test case.
Or could you maybe provide a working config export so I can see what differs to my setup?
Added more logging, the function now looks like this:
private function processParagraphTranslation($paragraphEntity, &$form, $d_lang, $t_lang, $excludedFields) {
if (!$paragraphEntity instanceof \Drupal\paragraphs\ParagraphInterface) {
return;
}
\Drupal::logger('autotranslate')->debug('Processing paragraph translation for entity: @entity', ['@entity' => $paragraphEntity->id()]);
foreach ($paragraphEntity->getFields() as $field_name => $field) {
\Drupal::logger('autotranslate')->debug('Field: @field_name', ['@field_name' => $field_name]);
if ($field->getFieldDefinition()->isTranslatable() && !in_array($field_name, $excludedFields)) {
if (isset($form[$field_name]['widget'])) {
\Drupal::logger('autotranslate')->debug("$field_name is a widget");
$this->translateField($paragraphEntity, $form[$field_name]['widget'], $field_name, $field->getFieldDefinition()->getType(), $d_lang, $t_lang);
} else {
\Drupal::logger('autotranslate')->debug("$field_name widget is not set");
}
}
if ($this->isParagraphReference($field)) {
\Drupal::logger('autotranslate')->debug("$field_name is a reference to paragraphs");
$nestedItems = $paragraphEntity->get($field_name);
foreach ($nestedItems as $idx => $nestedItem) {
if ($nestedItem->entity instanceof \Drupal\paragraphs\ParagraphInterface) {
\Drupal::logger('autotranslate')->debug('Processing nested paragraph: @nested_entity', ['@nested_entity' => $nestedItem->entity->id()]);
if (isset($form[$field_name]['widget'][$idx]['subform'])) {
\Drupal::logger('autotranslate')->debug('Subform is set for nested paragraph');
$this->processParagraphTranslation($nestedItem->entity, $form[$field_name]['widget'][$idx]['subform'], $d_lang, $t_lang, $excludedFields);
} else {
\Drupal::logger('autotranslate')->debug('Subform is not set for nested paragraph');
}
}
}
}
}
}And the output, if I click "Add translation":
481565 31/Mar 14:54 autotranslate Debuggen field_sign_lang_link is a widget
481564 31/Mar 14:54 autotranslate Debuggen Field: field_sign_lang_link
481563 31/Mar 14:54 autotranslate Debuggen field_reading_link is a widget
481562 31/Mar 14:54 autotranslate Debuggen Field: field_reading_link
481561 31/Mar 14:54 autotranslate Debuggen content_translation_changed widget is not set
481560 31/Mar 14:54 autotranslate Debuggen Field: content_translation_changed
481559 31/Mar 14:54 autotranslate Debuggen Field: content_translation_outdated
481558 31/Mar 14:54 autotranslate Debuggen Field: content_translation_source
481557 31/Mar 14:54 autotranslate Debuggen revision_translation_affected widget is not set
481556 31/Mar 14:54 autotranslate Debuggen Field: revision_translation_affected
481555 31/Mar 14:54 autotranslate Debuggen Field: revision_default
481554 31/Mar 14:54 autotranslate Debuggen Field: default_langcode
481553 31/Mar 14:54 autotranslate Debuggen Field: behavior_settings
481552 31/Mar 14:54 autotranslate Debuggen Field: parent_field_name
481551 31/Mar 14:54 autotranslate Debuggen Field: parent_type
481550 31/Mar 14:54 autotranslate Debuggen Field: parent_id
481549 31/Mar 14:54 autotranslate Debuggen Field: created
481548 31/Mar 14:54 autotranslate Debuggen Field: status
481547 31/Mar 14:54 autotranslate Debuggen Field: type
481546 31/Mar 14:54 autotranslate Debuggen Field: langcode
481545 31/Mar 14:54 autotranslate Debuggen Field: revision_id
481544 31/Mar 14:54 autotranslate Debuggen Field: uuid
481543 31/Mar 14:54 autotranslate Debuggen Field: id
481542 31/Mar 14:54 autotranslate Debuggen Processing paragraph translation for entity: 681
481541 31/Mar 14:54 autotranslate Debuggen field_text_editor_field widget is not set
481540 31/Mar 14:54 autotranslate Debuggen Field: field_text_editor_field
481539 31/Mar 14:54 autotranslate Debuggen content_translation_changed widget is not set
481538 31/Mar 14:54 autotranslate Debuggen Field: content_translation_changed
481537 31/Mar 14:54 autotranslate Debuggen Field: content_translation_outdated
481536 31/Mar 14:54 autotranslate Debuggen Field: content_translation_source
481535 31/Mar 14:54 autotranslate Debuggen revision_translation_affected widget is not set
481534 31/Mar 14:54 autotranslate Debuggen Field: revision_translation_affected
481533 31/Mar 14:54 autotranslate Debuggen Field: revision_default
481532 31/Mar 14:54 autotranslate Debuggen Field: default_langcode
481531 31/Mar 14:54 autotranslate Debuggen Field: behavior_settings
481530 31/Mar 14:54 autotranslate Debuggen Field: parent_field_name
481529 31/Mar 14:54 autotranslate Debuggen Field: parent_type
481528 31/Mar 14:54 autotranslate Debuggen Field: parent_id
481527 31/Mar 14:54 autotranslate Debuggen Field: created
481526 31/Mar 14:54 autotranslate Debuggen Field: status
481525 31/Mar 14:54 autotranslate Debuggen Field: type
481524 31/Mar 14:54 autotranslate Debuggen Field: langcode
481523 31/Mar 14:54 autotranslate Debuggen Field: revision_id
481522 31/Mar 14:54 autotranslate Debuggen Field: uuid
481521 31/Mar 14:54 autotranslate Debuggen Field: id
481520 31/Mar 14:54 autotranslate Debuggen Processing paragraph translation for entity: 1921
481519 31/Mar 14:54 autotranslate Debuggen Subform is not set for nested paragraph
481518 31/Mar 14:54 autotranslate Debuggen Processing nested paragraph: 2114
481517 31/Mar 14:54 autotranslate Debuggen Subform is not set for nested paragraph
481516 31/Mar 14:54 autotranslate Debuggen Processing nested paragraph: 2111
481515 31/Mar 14:54 autotranslate Debuggen Subform is not set for nested paragraph
481514 31/Mar 14:54 autotranslate Debuggen Processing nested paragraph: 2113
481513 31/Mar 14:54 autotranslate Debuggen Subform is not set for nested paragraph
481512 31/Mar 14:54 autotranslate Debuggen Processing nested paragraph: 2119
481511 31/Mar 14:54 autotranslate Debuggen field_accordion_list_content is a reference to paragraphs
481510 31/Mar 14:54 autotranslate Debuggen Field: field_accordion_list_content
481509 31/Mar 14:54 autotranslate Debuggen content_translation_changed widget is not set
481508 31/Mar 14:54 autotranslate Debuggen Field: content_translation_changed
481507 31/Mar 14:54 autotranslate Debuggen Field: content_translation_outdated
481506 31/Mar 14:54 autotranslate Debuggen Field: content_translation_source
481505 31/Mar 14:54 autotranslate Debuggen revision_translation_affected widget is not set
481504 31/Mar 14:54 autotranslate Debuggen Field: revision_translation_affected
481503 31/Mar 14:54 autotranslate Debuggen Field: revision_default
481502 31/Mar 14:54 autotranslate Debuggen Field: default_langcode
481501 31/Mar 14:54 autotranslate Debuggen Field: behavior_settings
481500 31/Mar 14:54 autotranslate Debuggen Field: parent_field_name
481499 31/Mar 14:54 autotranslate Debuggen Field: parent_type
481498 31/Mar 14:54 autotranslate Debuggen Field: parent_id
481497 31/Mar 14:54 autotranslate Debuggen Field: created
481496 31/Mar 14:54 autotranslate Debuggen Field: status
481495 31/Mar 14:54 autotranslate Debuggen Field: type
481494 31/Mar 14:54 autotranslate Debuggen Field: langcode
481493 31/Mar 14:54 autotranslate Debuggen Field: revision_id
481492 31/Mar 14:54 autotranslate Debuggen Field: uuid
481491 31/Mar 14:54 autotranslate Debuggen Field: id
481490 31/Mar 14:54 autotranslate Debuggen Processing paragraph translation for entity: 2115Note how "subform is not set for nested paragraph".
If I click the edit button of a paragraph in the node edit form that's now open:
481575 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481574 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481573 31/Mar 14:56 autotranslate Debuggen Field: created
481572 31/Mar 14:56 autotranslate Debuggen Field: status
481571 31/Mar 14:56 autotranslate Debuggen Field: type
481570 31/Mar 14:56 autotranslate Debuggen Field: langcode
481569 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481568 31/Mar 14:56 autotranslate Debuggen Field: uuid
481567 31/Mar 14:56 autotranslate Debuggen Field: id
481566 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2115
481865 31/Mar 14:56 autotranslate Debuggen field_sign_lang_link is a widget
481864 31/Mar 14:56 autotranslate Debuggen Field: field_sign_lang_link
481863 31/Mar 14:56 autotranslate Debuggen field_reading_link is a widget
481862 31/Mar 14:56 autotranslate Debuggen Field: field_reading_link
481861 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481860 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481859 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481858 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481857 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481856 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481855 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481854 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481853 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481852 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481851 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481850 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481849 31/Mar 14:56 autotranslate Debuggen Field: created
481848 31/Mar 14:56 autotranslate Debuggen Field: status
481847 31/Mar 14:56 autotranslate Debuggen Field: type
481846 31/Mar 14:56 autotranslate Debuggen Field: langcode
481845 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481844 31/Mar 14:56 autotranslate Debuggen Field: uuid
481843 31/Mar 14:56 autotranslate Debuggen Field: id
481842 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 681
481841 31/Mar 14:56 autotranslate Debuggen field_text_editor_field is a widget
481840 31/Mar 14:56 autotranslate Debuggen Field: field_text_editor_field
481839 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481838 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481837 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481836 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481835 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481834 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481833 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481832 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481831 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481830 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481829 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481828 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481827 31/Mar 14:56 autotranslate Debuggen Field: created
481826 31/Mar 14:56 autotranslate Debuggen Field: status
481825 31/Mar 14:56 autotranslate Debuggen Field: type
481824 31/Mar 14:56 autotranslate Debuggen Field: langcode
481823 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481822 31/Mar 14:56 autotranslate Debuggen Field: uuid
481821 31/Mar 14:56 autotranslate Debuggen Field: id
481820 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 1921
481819 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_title is a widget
481818 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_title
481817 31/Mar 14:56 autotranslate Debuggen field_one_link is a widget
481816 31/Mar 14:56 autotranslate Debuggen Field: field_one_link
481815 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481814 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481813 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481812 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481811 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481810 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481809 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481808 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481807 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481806 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481805 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481804 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481803 31/Mar 14:56 autotranslate Debuggen Field: created
481802 31/Mar 14:56 autotranslate Debuggen Field: status
481801 31/Mar 14:56 autotranslate Debuggen Field: type
481800 31/Mar 14:56 autotranslate Debuggen Field: langcode
481799 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481798 31/Mar 14:56 autotranslate Debuggen Field: uuid
481797 31/Mar 14:56 autotranslate Debuggen Field: id
481796 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2117
481795 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481794 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2117
481793 31/Mar 14:56 autotranslate Debuggen field_text_editor_field is a widget
481792 31/Mar 14:56 autotranslate Debuggen Field: field_text_editor_field
481791 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481790 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481789 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481788 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481787 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481786 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481785 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481784 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481783 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481782 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481781 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481780 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481779 31/Mar 14:56 autotranslate Debuggen Field: created
481778 31/Mar 14:56 autotranslate Debuggen Field: status
481777 31/Mar 14:56 autotranslate Debuggen Field: type
481776 31/Mar 14:56 autotranslate Debuggen Field: langcode
481775 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481774 31/Mar 14:56 autotranslate Debuggen Field: uuid
481773 31/Mar 14:56 autotranslate Debuggen Field: id
481772 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2116
481771 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481770 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2116
481769 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_conte is a reference to paragraphs
481768 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_conte
481767 31/Mar 14:56 autotranslate Debuggen field_accordion_flag is a widget
481766 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_flag
481765 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481764 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481763 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481762 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481761 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481760 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481759 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481758 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481757 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481756 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481755 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481754 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481753 31/Mar 14:56 autotranslate Debuggen Field: created
481752 31/Mar 14:56 autotranslate Debuggen Field: status
481751 31/Mar 14:56 autotranslate Debuggen Field: type
481750 31/Mar 14:56 autotranslate Debuggen Field: langcode
481749 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481748 31/Mar 14:56 autotranslate Debuggen Field: uuid
481747 31/Mar 14:56 autotranslate Debuggen Field: id
481746 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2114
481745 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481744 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2114
481743 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_title is a widget
481742 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_title
481741 31/Mar 14:56 autotranslate Debuggen field_text_editor_field is a widget
481740 31/Mar 14:56 autotranslate Debuggen Field: field_text_editor_field
481739 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481738 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481737 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481736 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481735 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481734 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481733 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481732 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481731 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481730 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481729 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481728 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481727 31/Mar 14:56 autotranslate Debuggen Field: created
481726 31/Mar 14:56 autotranslate Debuggen Field: status
481725 31/Mar 14:56 autotranslate Debuggen Field: type
481724 31/Mar 14:56 autotranslate Debuggen Field: langcode
481723 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481722 31/Mar 14:56 autotranslate Debuggen Field: uuid
481721 31/Mar 14:56 autotranslate Debuggen Field: id
481720 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2110
481719 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481718 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2110
481717 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_conte is a reference to paragraphs
481716 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_conte
481715 31/Mar 14:56 autotranslate Debuggen field_accordion_flag is a widget
481714 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_flag
481713 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481712 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481711 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481710 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481709 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481708 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481707 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481706 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481705 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481704 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481703 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481702 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481701 31/Mar 14:56 autotranslate Debuggen Field: created
481700 31/Mar 14:56 autotranslate Debuggen Field: status
481699 31/Mar 14:56 autotranslate Debuggen Field: type
481698 31/Mar 14:56 autotranslate Debuggen Field: langcode
481697 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481696 31/Mar 14:56 autotranslate Debuggen Field: uuid
481695 31/Mar 14:56 autotranslate Debuggen Field: id
481694 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2111
481693 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481692 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2111
481691 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_title is a widget
481690 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_title
481689 31/Mar 14:56 autotranslate Debuggen field_text_editor_field is a widget
481688 31/Mar 14:56 autotranslate Debuggen Field: field_text_editor_field
481687 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481686 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481685 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481684 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481683 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481682 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481681 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481680 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481679 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481678 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481677 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481676 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481675 31/Mar 14:56 autotranslate Debuggen Field: created
481674 31/Mar 14:56 autotranslate Debuggen Field: status
481673 31/Mar 14:56 autotranslate Debuggen Field: type
481672 31/Mar 14:56 autotranslate Debuggen Field: langcode
481671 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481670 31/Mar 14:56 autotranslate Debuggen Field: uuid
481669 31/Mar 14:56 autotranslate Debuggen Field: id
481668 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2112
481667 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481666 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2112
481665 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_conte is a reference to paragraphs
481664 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_conte
481663 31/Mar 14:56 autotranslate Debuggen field_accordion_flag is a widget
481662 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_flag
481661 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481660 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481659 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481658 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481657 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481656 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481655 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481654 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481653 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481652 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481651 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481650 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481649 31/Mar 14:56 autotranslate Debuggen Field: created
481648 31/Mar 14:56 autotranslate Debuggen Field: status
481647 31/Mar 14:56 autotranslate Debuggen Field: type
481646 31/Mar 14:56 autotranslate Debuggen Field: langcode
481645 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481644 31/Mar 14:56 autotranslate Debuggen Field: uuid
481643 31/Mar 14:56 autotranslate Debuggen Field: id
481642 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2113
481641 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481640 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2113
481639 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_title is a widget
481638 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_title
481637 31/Mar 14:56 autotranslate Debuggen field_text_editor_field is a widget
481636 31/Mar 14:56 autotranslate Debuggen Field: field_text_editor_field
481635 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481634 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481633 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481632 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481631 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481630 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481629 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481628 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481627 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481626 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481625 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481624 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481623 31/Mar 14:56 autotranslate Debuggen Field: created
481622 31/Mar 14:56 autotranslate Debuggen Field: status
481621 31/Mar 14:56 autotranslate Debuggen Field: type
481620 31/Mar 14:56 autotranslate Debuggen Field: langcode
481619 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481618 31/Mar 14:56 autotranslate Debuggen Field: uuid
481617 31/Mar 14:56 autotranslate Debuggen Field: id
481616 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2118
481615 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481614 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2118
481613 31/Mar 14:56 autotranslate Debuggen field_accordion_list_entry_conte is a reference to paragraphs
481612 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_entry_conte
481611 31/Mar 14:56 autotranslate Debuggen field_accordion_flag is a widget
481610 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_flag
481609 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481608 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481607 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481606 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481605 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481604 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481603 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481602 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481601 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481600 31/Mar 14:56 autotranslate Debuggen Field: parent_field_name
481599 31/Mar 14:56 autotranslate Debuggen Field: parent_type
481598 31/Mar 14:56 autotranslate Debuggen Field: parent_id
481597 31/Mar 14:56 autotranslate Debuggen Field: created
481596 31/Mar 14:56 autotranslate Debuggen Field: status
481595 31/Mar 14:56 autotranslate Debuggen Field: type
481594 31/Mar 14:56 autotranslate Debuggen Field: langcode
481593 31/Mar 14:56 autotranslate Debuggen Field: revision_id
481592 31/Mar 14:56 autotranslate Debuggen Field: uuid
481591 31/Mar 14:56 autotranslate Debuggen Field: id
481590 31/Mar 14:56 autotranslate Debuggen Processing paragraph translation for entity: 2119
481589 31/Mar 14:56 autotranslate Debuggen Subform is set for nested paragraph
481588 31/Mar 14:56 autotranslate Debuggen Processing nested paragraph: 2119
481587 31/Mar 14:56 autotranslate Debuggen field_accordion_list_content is a reference to paragraphs
481586 31/Mar 14:56 autotranslate Debuggen Field: field_accordion_list_content
481585 31/Mar 14:56 autotranslate Debuggen content_translation_changed widget is not set
481584 31/Mar 14:56 autotranslate Debuggen Field: content_translation_changed
481583 31/Mar 14:56 autotranslate Debuggen Field: content_translation_outdated
481582 31/Mar 14:56 autotranslate Debuggen Field: content_translation_source
481581 31/Mar 14:56 autotranslate Debuggen revision_translation_affected widget is not set
481580 31/Mar 14:56 autotranslate Debuggen Field: revision_translation_affected
481579 31/Mar 14:56 autotranslate Debuggen Field: revision_default
481578 31/Mar 14:56 autotranslate Debuggen Field: default_langcode
481577 31/Mar 14:56 autotranslate Debuggen Field: behavior_settings
481576 31/Mar 14:56 autotranslate Debuggen Field: parent_field_nameNow the "Subform is set".
I switched to the Bartik theme on the frontend now as well, to rule out possible hooks messing with the form, to no avail.
Is it possible to force load this form somehow? It does not seem to be populated the moment I need it, only later.
Apart from that, I think there should be an else-branch (with the reference-to-a-paragraph code) when detecting whether we have a widget. It can't be both, I guess?
Tested the newest 1.4.21, did a drush updb and drush cr, but I still don't have translations for nested paragraphs.
I'll try to debug this, but bear with me, I am not a proper developer!
If I change the following in ./src/Utility.php:
1059 private function processParagraphTranslation($paragraphEntity, &$form, $d_lang, $t_lang, $excludedFields) {
1060 if (!$paragraphEntity instanceof \Drupal\paragraphs\ParagraphInterface) {
1061 return;
1062 }
1063
1064 // Iterate over each field of the paragraph.
1065 foreach ($paragraphEntity->getFields() as $field_name => $field) {
1066 // If the field is translatable and not among the excluded ones, proceed.
1067 if ($field->getFieldDefinition()->isTranslatable() && !in_array($field_name, $excludedFields)) {
1068 if (isset($form[$field_name]['widget'])) {
1069 \Drupal::logger('autotranslate')->debug("$field_name is a widget");
1070 $this->translateField($paragraphEntity, $form[$field_name]['widget'], $field_name, $field->getFieldDefinition()->getType(), $d_lang, $t_lang);
1071 }
1072 }
1073 // If the field is a reference to paragraphs, handle it recursively.
1074 if ($this->isParagraphReference($field)) {
1075 \Drupal::logger('autotranslate')->debug("$field_name is a reference to paragraphs");
1076 $nestedItems = $paragraphEntity->get($field_name);
1077 foreach ($nestedItems as $idx => $nestedItem) {
1078 if ($nestedItem->entity instanceof \Drupal\paragraphs\ParagraphInterface) {
1079 var_dump($form);
1080 if (isset($form[$field_name]['widget'][$idx]['subform'])) {
1081 $this->processParagraphTranslation($nestedItem->entity, $form[$field_name]['widget'][$idx]['subform'], $d_lang, $t_lang, $excludedFields);
1082 }
1083 }
1084 }
1085 }
1086 }
1087 }
The log states:
field_accordion_list_content is a reference to paragraphs
which is expected.
However, the var_dump($form) gives me:
array(2) {
["#attributes"]=>
array(1) {
["class"]=>
array(1) {
[0]=>
string(18) "paragraphs-subform"
}
}
["#access"]=>
bool(true)
}$form[$field_name] is therefore not set.
Does this ring a bell for you?
That does not seems to differ from my setup here, strange.
I see another effect, maybe this is related as well?
When I click edit on one paragraph and trigger the translation but not on another one and save the article, I cannot make auto translation work anymore, i.e. the next time I edit the article. Paragraphs just stay in their original language.
But that's probably expected as that should not happen in the first place as your setup would never leave you with untranslated paragraphs.
I just thought I'd note this down as it might ring a bell for you.
I'm still on Drupal 10.3.x, but just tried with an updated instance on 10.4.x, same story.
Are you on 11 already?
I'm somehow running out of ideas where to debug further.
We might need deepl.com translations so I am considering to take a look at tmgmt but find the problem here would have been nice, still.
Just tried with 1.3.7, no change.
By uncollapsed, do you mean they are already editable? I have an "edit" button next to each paragraph:
If I click it, the translation gets triggered and works as it should.
I use the "seven" admin theme, tried claro now as well, that didn't seem to make a difference.
I searched quite a bit now, but I seems you always have to click edit to start editing a paragraph, this does not seem to be configurable?
Do you already see translations *before* clicking the edit button?
This is a config I took over, so I don't know the exact details of why it is configured like this. "Legacy" sounds ... outdated :-)
Maybe it's just that the "stable" mode has not been available back then?
This is how it looks like:
Title: Paragraph
Plural title: Paragraphs
Edit mode: Open
Add mode: Dropdown button
Form display mode: default
If I change the widget to "Paragraphs (stable)" and/or the "Edit mode: Closed, show nested", I see the same problem.
Would I have to create a specific "Form display mode" ?
This seems to be fixed, yes! Thanks a lot!
I fixed the issue below by correctly configuring the translatable paragraphs as per
https://www.drupal.org/docs/contributed-modules/paragraphs/multilingual-... →
(I had some unsupported fields checked, which I removed, and then had to select a "dummy" field ("Authored on") to enable translations of nested paragraphs as these were the only (untranslatable) fields in these paragraphs).
Still, I don't understand how this could have worked with other languages I haven't used <1.3.3 on before, but that's irrelevant.
I am leaving this here if anyone runs into the same problem:
==
I still see the same behavior for one node I used auto_translate <1.3.3 on before (which did not work with nested paragraphs).
The referenced nested paragraphs are simply gone when I try to add a translation (to the same language I tried before with <1.3.3 which seemed to have corrupted the translation).
I tried the following to bring back the ability to translate them:
- Rebuilt cache
- Reinstalled the module
- Reverted to an older revision of the node (in its original language)
- Made a change to the paragraphs and saved them (in the node's original language)
- Uninstalled the module and tried to add a translation (even then I get the same "no paragraphs added yet"; I can't even add or delete one, regardless of the module being installed or not)
- Truncated the key_value_expire table (as I assumed there might be some unsaved change from before that causes it)
- Used another user to try it
- Added some dummy value in the target language in paragraph__field_text_editor_field in the DB (still not shown when editing the node; another reference to the actual paragraph seems to be missing as well)
Nothing helped, this one node seemingly has some lingering defective translation data somewhere in the DB. I couldn't quite get down to the actual relations and where this dangling (NULL) reference is.
See the solution at the very top for how I fixed this.
Added a note that describes what needs to be selected if a nested paragraph is the only (untranslatable) field (which produces an error).
tgoeg → created an issue.
Thanks for the quick fix again!
I thought I'd write:
I still see literal HTML tags with 1.3.6-beta1, though they get away once I edit the respective paragraphs. I see them (and the translated strings) as soon as I edit the node, even before editing the paragraphs themselves (all done in preview mode when editing an article).
Now I saved the translation with its visible HTML tags and deleted the translation afterwards.
When I add a new translation now, I don't get any HTML tags nor do I get any translation of paragraphs when initially editing the new translation. As soon as I click "edit" on a paragraph, it does get translated and HTML tags are correctly parsed.
So I think this can be considered fixed and there might have been some caching issue from the version before. Just wanted to note this down if its ever relevant for anyone seeing the same.
Thanks again!
Added info to use a dedicated taxonomy as not doing so can cause utter breakage (link to issue included).
Seeing this as well but only on a production site although its dev site works flawlessly.
The prod site did so until recently as well, so I don't know what happened.
I may not view /taxonomy/term/1 anymore, either, not even as administrator.
This is really weird.
However, the changes in your commit do seem to solve it for me (at least I think I placed them in the right place (line 200 in src/Service/AccessCheck.php right now).
I also see the following in the log:
Path: /taxonomy/term/1. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: in Drupal\permissions_by_term\Listener\KernelEventListener->handleAccessToTaxonomyTermViewsPages() (line 217 of /var/www/drupal/web/modules/contrib/permissions_by_term/src/Listener/KernelEventListener.php).
It only happens to this one term and I cannot seem to change that, even if I manually allow only one user to use this term (the settings just don't get saved).
Found the problem, finally.
We have a mixed taxonomy that defines the roles and possible other tags used for tagging pages. Now I know this is a bad idea.
It seems some user mod assigned the term 1 as a role (although it is just a tag for promoting content to the front page in my case).
This caused hell to break lose.
I finally fixed it by
- delete from permissions_by_term_user where tid=1;
- Rebuilding node access permissions from the status page
- Rebuilding cache
This may be a different issue than the one described by OP, but a very similar outcome.
The patch attached fixes this (my) aspect, though not in a configurable way. But at least translatable.
I think this should be part of the solution presented further above (it is just an addition that should not interfere with the other aspects changed).
See
🐛
A11y: aria-label approach to improve label accessibility, remove hardcoded heading levels
Active
. The DOM-update case seems to fixed there.
Building on that and thanks to your code I can now see where to adapt things.
I'll attach a little patch just for showing this introductory text. However, it builds upon the other mentioned issue, so I don't want to create a MR yet (but can do so once it is merged).
Please test with
"drupal/admin_feedback": {
"Improve a11y": "https://git.drupalcode.org/project/admin_feedback/-/merge_requests/10.patch",
"Add intro text": "patches/admin_feedback_intro_text.patch"
},for the time being.
I added a MR that incorporates your changes (thank you very much for your contribution!) and improves on the way the label is inserted (aria-label), as that seems to be best practice now from what I gathered.
Additionally, the strings are also configurable now.
I am unsure how these strings could be made translatable as I am no real dev at all.
But for the time being, I can at least localize these strings by entering them in the admin config (and I guess they should be configurable anyway, as all other strings are, as well).
I did not want to delay merging b/c of the translation aspect. Let's get this reviewed/merged first and then probably open another issue for the translation.
If anyone wants to quickly test this in their composer.json, this is the magic sauce:
"drupal/admin_feedback": {
"Improve a11y": "https://git.drupalcode.org/project/admin_feedback/-/merge_requests/10.patch"
},tgoeg → made their first commit to this issue’s fork.
I am not an a11y pro - my initial description stems from an a11y certification authority that suggested to solve it that way.
https://stackoverflow.com/questions/22039910/what-is-aria-label-and-how-... mentions bad support for aria-label. The referenced page seems quite dated. Do you know whether things have changed to the better in the meantime?
The description of `aria-label` indeed seems to fit better than adding a label that has to be hidden anyway.
Looks good to me, perfect!
You chose "visually-hidden" and it seems to work well on a bootstrap-based theme. I wonder if this is universally applicable to all templates? It seems to be inherited from the "stable" theme in my case. I am not 100% we can rely on this to exist anywhere?
Thanks for the improvement!
I'm not an a11y pro but I think this might not be enough. As stated in the original description, screen readers would not know the DOM has changed otherwise. Sorry for not providing these additional details initially.
Gathering from https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut..., I think the new introductory text should be wrapped in something like this:
<div role="alert" aria-live="assertive" aria-atomic="true" id="feedback-live-region" class="sr-only"></div>
However, sr-only is bootstrap only, and, depending on the theme used, other classes might be necessary.
I'm OK with showing this message to everyone, but maybe there are use cases where this should only be shown to impaired users.
Do you know of a standardized way in Drupal to style screenreader-only elements?
A checkbox in the config to enable this would be enough, then. I'm just a sysadmin, sorry I can't provide any more info here..
A more general approach would be to define a configurable CSS class, so admins can easily set one that gets used in the theme.
(I know styling via an id would be an option, too, but using a class is easier and defining a custom class for an element is used in e.g. views as well, so it is a rather known concept in Drupal already).
I needed to adapt the patch a little to apply to 10.2.11
Attaching it.
I found an additional solution in my notes.
--- web/modules/contrib/glossify/templates/glossify-link.html.twig 2023-05-08 12:03:53.000000000 +0000
+++ web/modules/contrib/glossify/templates/glossify-link.html.twig 2024-05-08 16:54:06.872025951 +0000
@@ -11,4 +11,4 @@
* @ingroup themeable
*/
#}
-<a href="{{ tipurl }}" {% if tip %}title="{{ tip }}"{% endif %} class="glossify-tooltip-link">{{ word }}</a>
+<a href="{{ tipurl }}" {% if tip %}title="{{ tip }}"{% endif %} class="glossify-tooltip-link">{{ word }}</a>{# this or any comment here removes the erroneous newline that causes spaces when enabling twig debugging, noticeable when terms are right before non-blank characters like punctuation - see https://www.drupal.org/project/glossify/issues/3363487 #}
However, I cannot tell you how or why this works.
I definitely had a bright moment when implementing this :-)
This is needed additionally to the fix in core mentioned above for this edge case (the very bug OP describes; sorry, we drifted away to more general cases).
The fact that debugging mode does not lead to problems when terms are followed by space characters is caused by the browser reducing multiple space chars to one.
As we have an official release that already works with 10.x, I think this can be closed?
tgoeg → created an issue.
Chiming in, as an accessibility check of one site showed that glossified links should have an "aria-label attribute set that shows the purpose of the link", so something like "Glossary definition for " I guess.
This string should be customizable and translatable, as implementations might differ. Some might call it glossary, some dictionary, other lexicon, etc.
You can also use tokens, e.g. [webform_submission:webform_score] on the confirmation page.
See https://git.drupalcode.org/project/webform_score/-/commit/765d39f5c7c66e... for details.
I don't know if you addressed me, but IMHO the problem lies within core's way of inserting debugging comments itself.
There is an ongoing debate of whether enabling debug mode can be expected to give the same (rendered) results as when disabling it. And some core devs seem to be reluctant to accept any changes regarding the current markup as a site is expected to possibly fail when debugging is enabled.
I'd change core's debugging functionality as I showed above, as it doesn't hurt but fixes a few issues (on my side at least).
Depending on whether this is the way to go there is either nothing to do here or some additional workaround has to be implemented to get rid of those extraneous newlines.
Although I don't see
🐛
Twig debug mode causes parse error in appendXML
Needs work
in my installation, it seems very much related and both ways of fixing it outlined above may be a possible solution for it as well.
I can't reproduce this anymore, seems to work with the stock .htaccess config in the composer package.
It also has a different rewrite rule than the one mentioned above.
See 🐛 Apache shows 403 forbidden when "destination=" contains url encoded question marks (%3F) (CVE-2024-38474) Closed: works as designed for details.
If others can confirm that a current 10.2 or 10.3 also fixes this, we can close this issue.
tgoeg → created an issue.
Be aware that in case of choices 9.0.1 (contrary to the current master), which gets included by webform, the URL is *not* cdn.polyfill.io but <script src="https://polyfill.io/v3/polyfill.min.js?features=es5%2Ces6%2CArray.prototype.includes%2Cfetch%2CCustomEvent%2CElement.prototype.closest"></script> as mentioned by OP.
If you use some kind of search & replace mechanism, it should rather be something along these lines:
"scripts": {
"drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
"post-install-cmd": [
"sed -i 's#https://polyfill\.io/#https://polyfill-fastly\.io/#g' web/libraries/choices/public/index.html"
]
},
As already mentioned in [
🐛
polyfill.io Library is no longer considered safe to use
Fixed
], I'd very much favor that composer.libraries.json included this or some other form of patching the file without user interaction for the time being. Users should get a secure setup by just running composer update for their drupal installation, at least that's my way of thinking.
We can update to a fixed version later on (or switch to a better maintained lib as mentioned above) anyway.
I understand all of that, and yes, there are transitional mitigations available, but why not change the root cause and stop composer.libraries.json from downloading libraries that pull in the malware-ridden version in the first place?
I don't want code in my codebase that is known to cause trouble (even if it gets an override).
This issue is closed/fixed, so I just want to raise awareness that the root cause is not fixed in my opinion.
Choices seems to be unmaintained anyway. Pull requests for fixing the issue (and others) are there, unanswered.
What about adding https://github.com/alanhamlett/Choices/commit/0dae0283740f4f619c7589e7b1... as a (local) patch in composer.libraries.json?
This would be the kind of fix I'd think of.
Is it expected after an upgrade to webform-6.2.3 to still have these JS libraries source polyfill.io?
$ grep -lr "polyfill\.io" web/libraries/
web/libraries/algolia.places/src/navigatorLanguage.js
web/libraries/algolia.places/dist/cdn/places.js
web/libraries/algolia.places/dist/cdn/placesAutocompleteDataset.js
web/libraries/algolia.places/dist/cdn/placesInstantsearchWidget.js
web/libraries/algolia.places/dist/cdn/places.js.map
web/libraries/algolia.places/dist/cdn/placesAutocompleteDataset.js.map
web/libraries/algolia.places/dist/cdn/placesInstantsearchWidget.js.map
web/libraries/choices/README.md
web/libraries/choices/public/index.html
The current composer.libraries.json at https://git.drupalcode.org/project/webform/-/blob/6.2.x/composer.librari... still sources an old https://github.com/Choices-js/Choices/archive/refs/tags/v9.0.1.zip and https://registry.npmjs.org/places.js/-/places.js-1.19.0.tgz
I guess this issues should be re-opened and these dependencies removed, as well!
I guess this can be closed, then.
I am not sure whether this solves all the problems people face here, but I have a completely different approach that solves it for me with views at least and does not introduce any additional logic.
When I check for empty fields, the problem is not the added XML-commented debug output per se, but the added whitespace/line breaks that are not inside the comments and therefore lead to twig believing there is content indeed.
I first thought that removing the line breaks would mess up the generated markup (but I wanted to live with it, as long as it would solve the initial problem of seeing different rendered things with and without debug mode enabled).
But as it turns out, both firefox and chromium take care of adding linebreaks themselves when using developer tools in the browser and the markup looks just the same as with the patch. And it makes checks in twig whether fields are empty truely true :-)
I am not a developer so please improve as you see fit. Just posting here as it fixes it for me and seems less intrusive.
Applies against 10.1.x and 10.2.x.
Hi and thanks for your quick patch!
It will take some time to check this, as I am currently buried in work with no end in sight, can @hexabinaer probably jump in for the time being?
I think the algorithm is legit and most likely a better approach as it keeps the numeric fields in their correct form and allows sorting, etc. and only converts to strings for the purpose of facetting, which I think should be OK for values with different digits.
This should definitely be tested, as I also had to workaround this problem recently as I had a numeric field indexed as string for faceting to work properly, but also wanted to use it to sort results. That didn't work out properly, as it was 0<value<100 and so the single digit values were sorted in the wrong way, i.e. alphanumerically, 9 > 80, which is not what visitors expect.
As you only add a numeric field for faceting, this should be cleaner.
When looking at the patch, this line jumped out:
- $facetResults = $this->getFacetData($query->getIndex()->id(), array_keys($facets), [$filters], $keys);
+ $facetResults = $this->getFacetData($index, array_keys($facets), [$filters], $keys);
In all the other locations
$index=$query->getIndex()
but not
$index=$query->getIndex()->id()
You know I am no real dev so this might be totally OK, just wanted to mention it.
Meilisearch itself and the PHP SDK/API allow for providing effective relevancy. It's just that this very module does not yet implement this and I guess a relevancy of 1 is the default, then.
I tend to say we should transform this into a feature request?
I am also trying to track down relevancy problems as my boosts don't seem to cause any difference (but I think that the API key I use - intentionally not the master key - has some permission problems).
Relevancy is also always 1, in my case (in the view display for anonymous users). However, I do not get these errors in the log.
Do you have any custom twig involved that's possible typecasting to int here?
Or maybe this is a bug and my relevance is always 1 indeed (which won't cause any typecasting errors :) ). Which makes me wonder, I'd definitely like to see different relevancy. Your output seems to imply there is some relevancy that's not 1, which puzzles me.
I don't think this module reports any relevancy at all, yet, however.
https://php-sdk.meilisearch.com/classes/Meilisearch-Contracts-SearchQuer... says it would be $showRankingScore.
I don't see any mention of this in the code, should be in some $meiliOptions I guess.
Chiming in here and adding another case where this causes problems:
🐛
newline on glossify-link.html.twig causes extra space
Active
.
I also had this in a custom theme when checking whether a field is empty (which it was, but not when the debug code inserts newlines).
This does not only cause problems in non-HTML output as the RSS output might imply.
All of my problems got fixed by the following patch and I think it does more good than bad, so I think it could be included in core.
Current firefox and chromium add newlines to comments in developer tools anyway, so this does not really cause any disadvantage for developers, I think, and it really fixes problems on a lot of places (in my case).
Applies against Drupal 10.1
--- /core/themes/engines/twig/twig.engine.org 2024-05-08 16:37:50.990994524 +0000
+++ /core/themes/engines/twig/twig.engine 2024-05-08 16:38:47.900186459 +0000
@@ -63,8 +63,8 @@
throw $e;
}
if ($twig_service->isDebug()) {
- $output['debug_prefix'] .= "\n\n<!-- THEME DEBUG -->";
- $output['debug_prefix'] .= "\n<!-- THEME HOOK: '" . Html::escape($variables['theme_hook_original']) . "' -->";
+ $output['debug_prefix'] .= "<!-- THEME DEBUG -->";
+ $output['debug_prefix'] .= "<!-- THEME HOOK: '" . Html::escape($variables['theme_hook_original']) . "' -->";
// If there are theme suggestions, reverse the array so more specific
// suggestions are shown first.
if (!empty($variables['theme_hook_suggestions'])) {
@@ -106,17 +106,17 @@
$prefix = ($template == $current_template) ? 'x' : '*';
$suggestion = $prefix . ' ' . $template;
}
- $output['debug_info'] .= "\n<!-- FILE NAME SUGGESTIONS:\n " . Html::escape(implode("\n ", $suggestions)) . "\n-->";
+ $output['debug_info'] .= "<!-- FILE NAME SUGGESTIONS:\n " . Html::escape(implode("\n ", $suggestions)) . "-->";
if (!empty($invalid_suggestions)) {
- $output['debug_info'] .= "\n<!-- INVALID FILE NAME SUGGESTIONS:";
- $output['debug_info'] .= "\n See https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/function/hook_theme_suggestions_alter";
- $output['debug_info'] .= "\n " . Html::escape(implode("\n ", $invalid_suggestions));
- $output['debug_info'] .= "\n-->";
+ $output['debug_info'] .= "<!-- INVALID FILE NAME SUGGESTIONS:";
+ $output['debug_info'] .= " See https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/function/hook_theme_suggestions_alter";
+ $output['debug_info'] .= " " . Html::escape(implode("\n ", $invalid_suggestions));
+ $output['debug_info'] .= "-->";
}
}
- $output['debug_info'] .= "\n<!-- BEGIN OUTPUT from '" . Html::escape($template_file) . "' -->\n";
- $output['debug_suffix'] .= "\n<!-- END OUTPUT from '" . Html::escape($template_file) . "' -->\n\n";
+ $output['debug_info'] .= "<!-- BEGIN OUTPUT from '" . Html::escape($template_file) . "' -->";
+ $output['debug_suffix'] .= "<!-- END OUTPUT from '" . Html::escape($template_file) . "' -->";
}
// This output has already been rendered and is therefore considered safe.
return Markup::create(implode('', $output));I think the whitespace is introduced by Html::serialize($html_dom) on line 199 of GlossifyBase.php a process which by default inserts space between the strings being recombined
I don't think that's correct. $html_dom or even $word before already has that extra space.
If you enable twig debugging, that is.
At least that's the problem in my case. Disabling debug mode makes the problem go away.
It is caused by the ending tag
<!-- END OUTPUT from 'modules/contrib/glossify/templates/glossify-link.html.twig' -->.
And I explicitly added a newline here, before the comment, as that is what Drupal core does as well.
This very newline causes the whitespace to be inserted.
The following patch for Drupal core fixes it for me (as it does in several other cases where debug mode manipulates the DOM in such a way that it causes differences in rendering.
--- /core/themes/engines/twig/twig.engine.org 2024-05-08 16:37:50.990994524 +0000
+++ /core/themes/engines/twig/twig.engine 2024-05-08 16:38:47.900186459 +0000
@@ -63,8 +63,8 @@
throw $e;
}
if ($twig_service->isDebug()) {
- $output['debug_prefix'] .= "\n\n<!-- THEME DEBUG -->";
- $output['debug_prefix'] .= "\n<!-- THEME HOOK: '" . Html::escape($variables['theme_hook_original']) . "' -->";
+ $output['debug_prefix'] .= "<!-- THEME DEBUG -->";
+ $output['debug_prefix'] .= "<!-- THEME HOOK: '" . Html::escape($variables['theme_hook_original']) . "' -->";
// If there are theme suggestions, reverse the array so more specific
// suggestions are shown first.
if (!empty($variables['theme_hook_suggestions'])) {
@@ -106,17 +106,17 @@
$prefix = ($template == $current_template) ? 'x' : '*';
$suggestion = $prefix . ' ' . $template;
}
- $output['debug_info'] .= "\n<!-- FILE NAME SUGGESTIONS:\n " . Html::escape(implode("\n ", $suggestions)) . "\n-->";
+ $output['debug_info'] .= "<!-- FILE NAME SUGGESTIONS:\n " . Html::escape(implode("\n ", $suggestions)) . "-->";
if (!empty($invalid_suggestions)) {
- $output['debug_info'] .= "\n<!-- INVALID FILE NAME SUGGESTIONS:";
- $output['debug_info'] .= "\n See https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/function/hook_theme_suggestions_alter";
- $output['debug_info'] .= "\n " . Html::escape(implode("\n ", $invalid_suggestions));
- $output['debug_info'] .= "\n-->";
+ $output['debug_info'] .= "<!-- INVALID FILE NAME SUGGESTIONS:";
+ $output['debug_info'] .= " See https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/function/hook_theme_suggestions_alter";
+ $output['debug_info'] .= " " . Html::escape(implode("\n ", $invalid_suggestions));
+ $output['debug_info'] .= "-->";
}
}
- $output['debug_info'] .= "\n<!-- BEGIN OUTPUT from '" . Html::escape($template_file) . "' -->\n";
- $output['debug_suffix'] .= "\n<!-- END OUTPUT from '" . Html::escape($template_file) . "' -->\n\n";
+ $output['debug_info'] .= "<!-- BEGIN OUTPUT from '" . Html::escape($template_file) . "' -->";
+ $output['debug_suffix'] .= "<!-- END OUTPUT from '" . Html::escape($template_file) . "' -->";
}
// This output has already been rendered and is therefore considered safe.
return Markup::create(implode('', $output));Adding this to 🌱 [META] twig debug can break parts of site Active as well.
Created a page in the cookbook for the time being, currently in review.
I still feel encoding options as raw values (my solution #3) should be the default behavior OOTB, as it would render the manual workarounds obsolete.
Still seeing this on a 10.1 site on a page where a subnavigation is put into one block as well as a Webform into another. The additional ID is only added when loading the second page of the form (which is not configured to use AJAX).
Changing CSS to target the class and not the ID (as advised above) solves it for me, but still this seems like a lurking bug.
This seems to be https://github.com/meilisearch/meilisearch/issues/4060 as we have a numerical field in this index.
Switching it to string for this field fixes it for us.
I see two issues:
- This very issue. We know there are only a handful of users using v1.x. They also have to have a numerical field and facets. If they upgrade, they will see this issue (i.e., have a working setup, upgrade, have a broken setup). For the time being and the probability of this to actually happen, I think this issue here is enough for documentation purposes.
- The other part however is the general problem that this poses. As this does not stem from upgrading at all, I will open another issue: 🐛 Using facets on numerical fields makes them disappear Active
If maintainers feel this is good enough then this issue can be closed.
Not saying that your patch might not be beneficial, the way I solved this is the following:
- Drupal multisite setup (so yes, multiple sites on prod and dev)
- A dev and a prod Meilisearch instance (on separate servers, but this could be on the same server with different ports as well
- Config split switches between the two instances based upon where the site lives
I would however never advise to run dev and prod on one server, be the website as small as it may, considering you get a VPS instance for 3 EUR/USD a month.
No need to justify yourself, and don't feel patronized, your patch might very well be useful.
I just wanted to note this down for anyone looking to set this up similarly.
Works on 10.1 for me, I'll see whether it does so on 10.2, as the needed core patch 📌 Add a 'machine_name' widget for string field types with a UniqueField constraint Needs work does not seem to be in good shape.
Yes, as stated in my original report, the GUI setting you show works indeed as it should.
However, drush does not produce anything useful when using --exporter=json or --exporter=yaml !
Tested with current v6.2.2
Do you get any meaningful output when you issue the following?
$ vendor/bin/drush wfx myform --exporter=json > /tmp/exporttest
> [notice] Exported 441 of 441 submissions…
$ file /tmp/exporttest
/tmp/exporttest: gzip compressed data, extra field, has comment, last modified: Thu Feb 7 16:27:08 2019, max compression, from Unix, original size modulo 2^32 173806772
$ gzip -dc /tmp/exporttest | less
gzip: /tmp/exporttest has flags 0x5c -- not supported
If I substitute the 0x5c in the file with 0x00 I can tar xzf /tmp/exporttest and get a file submission-3.json which is half broken, but still it shows it is JSON in (broken) .tar.gz
1) The output is unusable
2) The output is compressed when the option/usage info does not say so. Either do output JSON/YAML as one would expect or state you get a .tar.gz (which should not be corrupt :-) )
I'm OK with a separate module, though I feel this should be the standard (secure) way of setting things up (and installed by default, then?). Maybe adding a note on the module's front page that using the submodule providing key management is strongly recommended for those not seasoned with manual key/index setups can help.
You mentioned
API and Search key
.
Haven't thought of search keys at all until now. The concept sounds good - a search client (Drupal frontend) only gets the least privilege, i.e. only permissions for searching. However, as the backend lives on the same installation, it is kind of limited here. When ingesting/indexing content is done on one machine and searching only on another, that absolutely makes sense. But yeah, why not, it doesn't hurt. And in case there's some vulnerability in the search code only, the index's contents are not at risk at once.
It should not be too hard to solve the backward compatibility I think: Let's take this over to ✨ Change master key to API and search key for improved security Active
If this issue at hand is available as a submodule, I think I can offer testing. It's just that I am currently stuck on 1.x, as the upgrade to 2.x breaks my facetted searches, even when I add the new facetting submodule. No errors whatsoever, I just don't get any results, but that's a different story. Just so you know this might be delayed quite a bit.
Just tested with current stable and I cannot reproduce it anymore - at least not the problem I mentioned above.
I think I am of no big help, then.
If that's the case, the option should be added to the help output, together with an info that it is only available if the module is installed.
As it is now, no-one knows of it except when they read this ticket.
I cannot reproduce my initial issue in 10.1.x anymore, nor do I see the AJAX errors mentioned in
#3033849-8: Rewrite / Replacement pattern not working for (date?) fields in revisions →
Everything works as expected.
Therefore, I'll close this issue.
Thanks for the update!
$ drush pm:enable webform_submission_export_import
> [notice] Updated default configuration to de
> [warning] No configuration objects have been updated.
> [notice] Message: Es wurden keine Konfigurationsobjekte aktualisiert.
>
[success] Successfully enabled: webform_submission_export_import
$ drush wfx --help | head -n7
Exports webform submissions to a file.
Arguments:
[webform] The webform ID you want to export (required unless --entity-type and --entity-id are specified)
Options:
--exporter[=EXPORTER] The type of export. (delimited, table, yaml, or json)
$ drush pm:list | grep "Submission Export/Import"
Webform Webform Submission Export/Import Enabled 6.2.2
Is this a hidden parameter option or is there something wrong with my installation?
I don't see --exporter=webform_submission_export_import as a possible option here.
I also get "attribute search_api_datasource is not filterable" when I
- create an index
- also use "node grants" in the filters (in hope of not indexing e.g. unpublished content)
- search as an anonymous user
It's hard to tell for me whether this is related? Or shall I raise a separate issue?
I could not find a solution but managed to solve all other conflicts and upgraded to CKEditor5 and it is working again.
For anyone who wants a quick but more or less proper fix without touching code for the time being:
Export your site's config, grep for "offset: null" in the view config .ymls and edit it to say "offset: 0" (or whatever valid value you want).
Reimport config. Site running again.
I lost track of the original cause/error for this as this is so long ago, but I think this also happens/triggers a similar error when setting up a search API view/search with facets placed above the search in a views_block_area and enabling AJAX.
In this situation, I get
{"message":"No facet link or facet blocks found."}', name: "AjaxError"
I found a note stating:
The problem is that the "block-facets-ajax" class is not being added to the rendered block.
Sorry for being so vague, but maybe that helps in tracking this down somewhat.
tgoeg → created an issue.
So is most likely also something that Meilisearch itself should provide better messages and error codes for.
For the situations where we do get code 0 back, this is definitely a better error message.
I wonder whether there might be explicit cases of an unreachable server which the old message should still be shown for.
But on the other hand, looking into the logs is never a bad idea, so setting this RTBC.
OK, RTFM'ing sometimes really helps :-)
That key derivation first irritated me, but after reading the reasoning behind it, it totally makes sense.
This also means it's of no use to file a feature request, as API keys simply cannot be changed.
It also rules out situations where people might probably change API keys on the Meilisearch server but forget to keep it in sync with Drupal, which could be considered an advantage.
All of this might be too theoretical anyway. I think the way you did it right now makes for 99% of the setups. At that's what this issue was all about at first. To remove the master key from the config and have a convenient way of managing the keys from Drupal itself so one can have a secure setup.
This seems fulfilled to me.
Let's wait for other use cases if there are any.
I could think of one, btw :-)
This is an actual project that might see the light of day next year probably. I'd want to have one central Drupal instance to feed an index and have multiple web sites to be able to search through subsets of this index (based on given filter criteria).
It would mean one default setup with the routines you laid out to initially create the index on the central instance. Nothing fancy yet.
On the other instances, I would manually enter prefixes and keys, as I would very likely want them to not be able to delete the index, add or delete documents, etc. One could probably prepare for such a scenario by adding an additional checkbox "read-only access", which would create the API key with a reduced set of permissions.
I am still not sure how to get the actual content from the central Drupal site, then, if search_api can handle non-local content for indexed data at all and if this is a good idea. Or if this module needs to be the one that indexed the data itself to be able to use it again (maybe not anymore since the fix in
📌
Remove entity id mapping config
Fixed
?)
But this would probably be one application for another kind of key generation.
All of this sounds reasonable to me!
I think a warning should be added that keys will get deleted (haven't looked at the actual code yet, maybe it is like this already). Most of the time this will be desired, but there may be cases where an index+key may be used from multiple Drupal instances or even different frontends.
Taking care of every hypothetical setup should not be the aim here, however. I'd expect admins of complex setups to be able to handle them manually, for themselves. A warning/note however should protect from unexpected accidents.
> Sadly how key management works, every time the prefix gets changed we'd have to generate a new key.
Yes, that's something that irritated me as well already. Should we probably file a feature request for an UPDATE feature of the /keys endpoint to allow both changing the index and/or the key?
Comments overlapped.
Yes, a confirmation and deletion of the generated key totally makes sense. I do already have a lot of unused keys from development tries. This would definitely make setups cleaner and mean less manual admin work on the Meilisearch backend.
Yeah! That looks good to me as well! Probably re-use some of my description texts to make it clearer.
Would I be able to deliberately delete the key and re-activate "Generate API key"?
There might be situations where I want to have a new key when one is configured already. Maybe when a new/empty Meilisearch server gets used and I want to start anew.
Or probably do not deactivate the checkbox and only show a red warning when it is selected and a key is already configured?
No!
And sorry, I seem to not have been clear.
I DO think it's a good idea for Drupal to setup keys. Something along the workflow depicted in the mockups.
It's just that the usage of prefixes (which is a good design decision IMHO) will not always be backwards compatible with existing setups. Only in the case of existing indexes that do NOT conform to a prefixed namespace will an admin have to manually manage keys outside of Drupal.
And that will be a very small percentage of users, if they exist at all.
Even if people have existing indexes, I - for one - would advise to drop them, generate a key like in the mockups and create the indexes anew, now conforming to the prefixed setup.
I think what needs additional attention is the creation of new indexes.
When a prefix (and accompanying key) is setup, only indexes starting with the prefix can be created. So misconfiguration can technically be ruled out as wrong indexes will not be able to be created anyway.
However, it might be helpful if it were possible to restrict new index creation to names starting with the prefix.
If that's too complicated, the error message when trying to create an index with a different prefix should state state the index does not start with the prefix. Not just that index creation failed because of missing permissions.
Seems I did not push save the last time I wrote an answer to this, sorry.
I didn't know about the wildcard option. But I like the idea very much. Do you know why? My indexes already have a prefix, the domain they are being used on :-)
So yes, this feels pretty natural to me and I guess it will to anyone having a multisite setup.
I am unsure about the consequences when deleting an index. If a wildcard API key exists, it will most likely continue to exist. I think I remember that API keys vanish when their index gets deleted (but I may be wrong). Creating an index should also be fine, as - as long as the prefix is correct - there is no additional key needed (which would otherwise be the case; a per-index key needs to exist to be able to use the index, and therefor creating a new index would not make too much sense).
I currently get an error "Index already exists" if drush cim a config with an existing index. Would this be "fixed" then? I do not think an index should then be deleted, even if that would be possible now.
But that's a different issue actually, which I think needs a little modification as well.
There might be applications where protecting an index from getting deleted might make sense. My current (manually-created-key-)setup does just that. Drupal may in fact only really add and remove documents, and search through them, which feels adequate for a production instance. No way to really destroy anything.
I think people who want just this can however still lock down keys manually. This module should probably not break if people do it, however.
This way, I think this could be added to the core functionality right away. It does not really seem to have the potential to bring disadvantages to anyone, and it would prevent people from using a master-key based setup. I think that's something that should never be possible. It feels like saving your root password into some configuration in plain text.
If this shall be a separate submodule then there should be a big fat warning that running without it is not at all recommended.
I might be a little biased but I think prepopulating the (editable) prefix with the transliterated domain of the page, e.g. my-website.co.at will become my_website_co_at_ as a prefix) could help beginners a lot to get a clean setup.
Regarding your questions:
> The first one is if there is already an existing active server with indexes. For this, I think we should just set the prefix to an empty string and leave the master_key as was set.
Yes and no. It will keep legacy setups running, yes. But I'd like to see an upgrade path for this. It would be great if one could provide a prefix (that's already in use) and a key, basically just like the new algorithm layed out above would do, just that the key would not be created, but an existing one could be entered.
If the algorithm would just fill in the prefix and the (generated) key upon clicking some "generate" button (that also needs to have the master API key supplied), then those fields could be editable as well (with a warning stating that the key and prefix either need to exist already (for upgrades) or one should better use the generator, if a new key/prefix (and probably index) is preferred.
> The second is removing of submodule. So if the API key stays there searching, modifying, and deleting existing indexes should not be a problem, but if someone tries to add a new index to the server it will only work if the admin adds the prefix that works with the API key when naming the index.
Yes. And a note for this would need to be added. Which makes part of this functionality appear in the main module again. I think this should go into the main module (did I already mention that?). But, as I stated above, using a submodule is a possibility as well. The big fat warning™ from above would need an additional info that exactly those problems will arise if anyone decides to remove the submodule. I can't think of any meaningful setup that would need this, though.
Here are two mockups and the HTML that generates them.
I am unsure whether this should probably better be put into a separate tab. The double "generate key" buttons are no good solution yet. Probably just add a link to the second tab and do the key generation there.
Alternatively, it could be fit right into the basic configuration page already as well, should not be too long.
As you can see my screenshots are partially German. I am from Austria, so I can provide translations as well (later on).
Is there anything open that prevents releasing this as a stable/supported version? Drupal 9 will soon reach EOL, so a stable release for D10 would be important.
I'd say we should restrict the scope here to whether error handling makes sense, regardless of how/where errors originate, to potentially give a better clue for admins/devs if they occur.
Having differing data sources sounds like a useful addition that will have its application but should probably be created as a separate feature.
It does have a way!
If you request the index' details with
xidel -s -e '$json' -H 'Content-Type: application/json' -H "Authorization: Bearer mypass" 'http://127.0.0.1:7700/indexes/mydomain'
(might as well use curl, I use xidel because it understands and formats JSON and XML, can use xquery/xpath, etc.)
you get some fields back, one of them being the primary key:
{
"uid": "mydomain",
"createdAt": "2023-07-12T13:48:59.640002336Z",
"updatedAt": "2023-08-24T12:03:38.907236139Z",
"primaryKey": "id"
}
I am however not sure whether meilisearch_php exposes that, but gathering from https://php-sdk.meilisearch.com/classes/Meilisearch-Endpoints-Indexes.html it seems so.
Also not a dev, but I think I can at least clear up things a little.
First, this is not a decimal (as strange as it may sound). Your number is a float (mathematically) and SQL stores it as an exact data type DECIMAL with a given precision (which in fact is a float). There is an explicit FLOAT data type in SQL, but that is not guaranteed to be exact.
The basic underlying problem is that computers "think" binary and not decimally. Representing an arbitrary number with lots of places after the decimal point will inherently produce errors (depending on which number it is, as some ("machine numbers") map cleanly to binary base and some do not. That's why people here see this only with select numbers). See https://en.wikipedia.org/wiki/Round-off_error for details.
The internal representation of a number 0.123456 might be 0.123456789 because of rounding errors. That's why rounding to the exact given scale does make sense. It's no actual rounding of the given number in the human sense. It just makes sure the number is exactly the one entered and has exactly that many decimal places as configured.
Does the patch in #2230909-292: Simple decimals fail to pass validation → not fix it for you? That would be an important information.
Didn't I fix this in
🐛
Primary key inference fails for Meilisearch >=1.x and fields ending in "id" (includes patch)
Fixed
already? This is part of the current 1.1.0 release (and I guess in 2.0 as well, did not have the time to check, yet) at least. It's hard coded to id.
Directly handling the problem at hand does not really make sense, yes.
I just think the error handling is not ideal, this might be improved.
I could imagine situations (that was part of the discussion in some other issue as well) where an existing index might get attached to a setup running this module. This could pretty easily hit the error described here, if the primary key differs. And I think it should get caught cleanly.
Our posts overlapped. Yes, your diagnosis is absolutely correct!
Did a full DB and site files clone to a dev instance.
Restored to 1.1.0-rc1.
The second site works flawlessly.
The first one breaks again with the error in the title Document doesn't have a `search_api_document_id` attribute.
If I index with the older SearchApiMeiliSearchBackend.php and then switch to the current version, at least I have a version that somehow works for both sites. Indexing new (special?) nodes however will not work in this setup I guess.
Something's off.
The error
Drupal\search_api\SearchApiException while adding Views handlers for field on index mydomain Node Index: Could not retrieve data definition for field '' on index 'mydomain Node Index'. in Drupal\search_api\Item\Field->getDataDefinition() (line 482 of /var/www/drupal/web/modules/contrib/search_api/src/Item/Field.php).
is also back again.
I'm pretty convinced at this point that is a bug indeed and not a configuration/environment problem on my end.
Finally found it!
Due to some previous version, I had a primary key search_api_document_id in the first page's index.
Dropped all items from the index and changed the primary key with
curl -X PATCH 'http://localhost:7700/indexes/myindex' -H 'Content-Type: application/json' --data-binary '{ "primaryKey": "id" }' -H "Authorization: Bearer mypass" directly in Meilisearch.
I am unsure whether this warrants some error handling to be included somewhere around createField() in src/Plugin/search_api/backend/SearchApiMeiliSearchBackend.php
This seems to be the cause for the successive error stating field '', i.e. a field that never got created.
400 protected function getSpecialFields(IndexInterface $index, ItemInterface $item = NULL): array {
401 $fields = parent::getSpecialFields($index, $item);
402 $fields['id'] = $this->getFieldsHelper()->createField($index, 'id', [
403 'type' => 'string',
404 'original type' => 'string',
405 ]);
406
407 if ($item) {
408 $fields['id']->setValues([MeilisearchUtils::formatAsDocumentId($item->getId())]);
409 }
410
411 return $fields;
412 }
createField() comes from Search API's src/Utility/FieldsHelper.php, which has no error handling either. It in turn calls new Field() which I was unable to track down further.
Why exactly I got the error only for two nodes is still a mystery to me.
Unsure what to do with this ticket now. This will most likely never hit anyone.
Please decide whether some of the errors presented should get some better handling and/or tests.
tgoeg → created an issue.
tgoeg → created an issue.
Regarding
#3311063-34: Add support for Ckeditor 5 →
: I created a patch over at
#3371353-5: VideoEmbedWysiwyg::getValidMatches() does not detect two videos next to each other →
.
@loopy1492: Can you please try to apply both patches and report whether that fixes it for you? It's not really related to this issue at hand, but I'd like to get rid of this negative feedback here so we can push this (and the other ticket) to RTBC.
Here is a patch for the above MR. It would be great if we could set ✨ Add support for Ckeditor 5 Needs review to RTBC, but that means that #3311063-34: Add support for Ckeditor 5 → (though not related to that ticket but to this one) should probably be fixed as well, as this patch here seems to do.
No worries, thanks for the quick fix.
Drupal 9 is on its way out anyway, we're just not quite there, yet.
Sorry I did not mention the Drupal version used.
I'll close this as it is fixed for me and already pushed to 2.0.1.
Removing the default export options will likely cause unexpected regressions for other people.
No, it won't, as they are not removed.
As already laid out,
src/Commands/WebformSubmissionCommands.php
calls
172 $submission_exporter->setExporter($export_options);
(Additionally to
171 $export_options += $submission_exporter->getDefaultExportOptions();)
This in turn, in setExporter() in
src/WebformSubmissionExporter.php:
calls
$export_options += $this->getDefaultExportOptions();
So you end up calling getDefaultExportOptions(); twice (and adding it to the $export_options).
As also laid out and tested, the default options do get set with only one call (which should be no surprise).
Yours to decide.
I can open up a second issue as well, if you like.