Odd behaviour on multi lingual sites during replace in certain circumstances

Created on 18 April 2024, 12 months ago

Problem/Motivation

Im seeing some strange behaviour on multi lingual sites when replacing a string, but appending a value rather than replacing part of the existing string. It could be that it wasn't intended to be used this way, as replacing values in the middle of strings seems to be OK.

Steps to reproduce

1. Fresh D10.2.4
2. Latest version of Scanner
3. Enable the Scanner module
4. Add 2/3 plain text, short fields to the basic page content type
5. Configure Scanner to use the new fields, all other settings leave as standard
6. Add a new language, any
7. Add a new basic page
8. Add the same text for all 3 of the fields added in step 4 (My string)
9. Run a Scanner search for the string in step 7
10. Append a value to the end of the string, say - updated, so the replace value is (My string - updated)

Expected: New values are My string - updated
Actual: New values are My string - updated - updated

Proposed resolution

Understand if this use case is valid and fix if so

🐛 Bug report
Status

Active

Component

Code

Created by

🇬🇧United Kingdom aaron.ferris

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @aaron.ferris
  • 🇬🇧United Kingdom aaron.ferris

    Looking at this some more, it's perhaps odd in the end result but logically it's correct, based on the current code. When we loop through the languages we search once again for the original string, which in this example it still exists and thus replaces it again. I'll need to try and pick my way through the multi lingual aspect of this.

              foreach ($other_languages as $langcode => $languageName) {
                if ($node->hasTranslation($langcode)) {
                  $node = $node->getTranslation($langcode);
                  $nodeField = $node->get($fieldname);
                }
                $fieldValue = $nodeField->getValue()[0];
                // Replace the search term with the replace term.
                $fieldValue['value'] = preg_replace($conditionVals['phpRegex'], $values['replace'], $fieldValue['value']);
                $node->$fieldname = $fieldValue;
              }

    Run 1 - English

    My string

    Updated to My string - updated

    Run 2 - Welsh

    My string - updated (My string obviously still there)

    Updated to My string - updated - updated

  • 🇩🇪Germany Anybody Porta Westfalica

    This very much sounds similar to 🐛 Paths incorrectly replaced Active - maybe that one should be closed as duplicate as it's less documented.

    As this is an effect, which can have unexpected and wide results, I think we should mark it major. What's your suggestion to fix this @aaron.ferris? Would you prepare a MR maybe?

  • 🇬🇧United Kingdom aaron.ferris

    Apologies for not responding @anybody, I haven't had a chance to look at this properly yet. Ill hopefully get some time over the holidays.

  • 🇪🇸Spain xurdep Gijón

    Hi to all!

    @smustgrave
    I have made a patch that (I think and I hope) to solve the problem.

    The problem I have seen is that when a site has several languages, the replacement is done as many times as languages the site has.

    Example:
    Searched word: “WORD_TO_TEST”
    Replace with: “WORD_TO_TO_TEST1”
    Result: “WORD_TO_TO_TEST11111111”

    With this patch, result is “WORD_TO_TEST1”.

    I have tested in a site with 27 languages and in a site with only the default language.

    An auxiliary function is included in the patch to avoid code duplication. The patch applies only to the Drupal plugin. I would be checking this behavior for Paragraph plugins as well, but I don't have much time.

    B.R.

  • 🇪🇸Spain xurdep Gijón

    Sorry, I resubmit a second version of the patch for version 2.0.0-beta1, since the previous version of the patch was not in the 2.0.0-beta1 branch.

Production build 0.71.5 2024