Translate-plugin: MLRepeater not working with groups

Created on 12 Aug 2017  路  10Comments  路  Source: rainlab/translate-plugin

Expected behavior

Add a group type X in language A and a group type Y in language B. If I switch from language A to B and back to A, the group type should be X.

Actual behavior

If the language is switched from B to A the group type is Y instead of X.
Check Video: http://youtu.be/a633InT4pwo?hd=1
(ignore audio...)

Reproduce steps

  1. DB table with text columns id (PK), content (text)
  2. Model from the table, make 'content' jsonable
  3. Define columns.yaml (not important),
  4. Define fields.yaml like this:
fields:    
    content:
        label: Content
        oc.commentPosition: ''
        prompt: 'Add new item'
        span: full
        type: repeater
        groups:
          textarea:
            name: Textarea
            description: Textarea
            icon: icon-leaf
            fields:
              textarea_content:
                label: Content
                type: richeditor
          text:
            name: Text
            description: Text
            icon: icon-leaf
            fields:
              text_content:
                label: Content
  1. Make controller and backend menu
  2. Create two languages (e.g. en (default), de)
  3. Place a text in language en and set some value, place a textarea in language de and set some value -> save
  4. Refresh form, switch from language en to de (group type in de is correct -> textarea), switch back to en (group type is wrong -> textarea instead of text)

October build

(419, 420)

Note: If alle languages have the same order and types of groups, everything is working as expected.

Medium Bug

Most helpful comment

@massimomegistus Thanks dude. You have literally save my life with your solution.

All 10 comments

I investigated this issue and found out that in file modules/backend/formwidgets/Repeater.php the function

    /**
     * Returns a field group code from its index.
     * @param $index int
     * @return string
     */
    public function getGroupCodeFromIndex($index)
    {
        return array_get($this->indexMeta, $index.'.groupCode');
    }

always returns the group code of the default locale.

@munxar are you able to come up with a solution to fix it and provide a PR?

Hi guys,
i've made some tests in static pages with a group repeater and i've just noticed that removing the $this->getGroupCodeFromIndex call in processSaveValue, the group translation seems to work correctly, even if all languages don't have the same order and types of groups.

I have redefined processSaveValue in rainlab/translate/formwidgets/MLRepeater.php

protected function processSaveValue($value)
    {
        if (!is_array($value) || !$value) {
            return $value;
        }

        // if ($this->useGroups) {
        //     foreach ($value as $index => &$data) {
        //         $data['_group'] = $this->getGroupCodeFromIndex($index);
        //     }
        // }

        return array_values($value);
    }

May be it's a stupid question: do you see any side effect in this?

@massimomegistus how is the developer supposed to identify the group data where it's used then?

Hello Luke, the $value parameter passed to processSaveValue contains the right _group codes.
When switching form lang_1 to lang_2, the hidden input RLTranslate[lang_1] is updated correctly with lang_1 _group codes, and processExistingItems receives lang_2 _group codes, as expected; group codes are written in pages [viewBag] on save.
I've tested on static pages only, maybe i'm missing something.

@massimomegistus does it still work if you are populating a repeater from nothing?

Hi Luke, yes, it works.
I've also tested on a db model with a jsonable field, and groups codes are saved correctly in the database.
I'm developing a website in the next two weeks, using this fix. If i see any issue I'll let you know.

@massimomegistus Thanks dude. You have literally save my life with your solution.

This needs to be re-evaluated in lite of octobercms/october#4234 and #466

Closing as the above PRs have been merged, will reopen if anyone still has a problem after applying those fixes.

Was this page helpful?
0 / 5 - 0 ratings