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
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
October build
(419, 420)
Note: If alle languages have the same order and types of groups, everything is working as expected.
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.
Most helpful comment
@massimomegistus Thanks dude. You have literally save my life with your solution.