VersionControl icon indicating copy to clipboard operation
VersionControl copied to clipboard

Multi-language textfields - database is not filled with the original values at module installation time

Open happy-kaseem opened this issue 7 years ago • 3 comments

VersionControl does at the moment of its installation not store the initial values of TextareaLanguage (Textarea [Multi-language]) fields. To be specific probably all fields which store there data with the class LanguagesPageFieldValue. I have been testing it again on the latest release version 1.2.9 by installing VersionControl on my test site and activating it for two fields on one template. The two fields are of type:

  • Textarea (normal single language text)
  • TextareaLanguage (multi-language) When I check the table "version_control__data" I find only entries for the field of type "Textarea" whereas there are no entries at all for the field of type "TextareaLanguage". As far as I can tell, there is an issue with the function used to find the data of fields of type "TextareaLanguage" at the time of installation of the module: $data->getChanges() will only return changes made to the data of the instance of $data at run-time which is the case when this code finds changes to a field of type "TextareaLanguage". But when the module is newly installed the function $data->getChanges() will return nothing since the field data is in it's original state as stored in the database table.
                } else if ($data instanceof LanguagesPageFieldValue) {
                    foreach ($data->getChanges() as $key) {
                        if ($key == 'data') continue;
                        $data_array[$key] = $data->getLanguageValue(str_replace('data', '', $key));
                    }
                } else {

(see code on github here)

I have done some research on how the data is stored internally at run-time and on the database and I hope that my patch addresses the problem correctly: Every language value, including the default language, is stored under a key 'data'.$language->id, the same way the function getChanges() returns the keys.

I have made a suggestion for how to changes this on my fork. There is a pull request available.

happy-kaseem avatar Apr 11 '17 05:04 happy-kaseem

Thanks. I'll take a closer look at your PR soon!

teppokoivula avatar Apr 12 '17 14:04 teppokoivula

True multilanguage support would be so great. Right now on a restore the content of one language is filled into both language areas, the correspondent language gets overwritten and lost.

tbba avatar Apr 19 '18 20:04 tbba

Thanks for the feedback, @tbba. Could this be related to the multi-language issue reported via forums?

https://processwire.com/talk/topic/6333-version-control/?do=findComment&comment=165018

Note: as far as I can tell, this is not related to the first post in this issue. This issue is about the module not pre-populating initial values for multi-language fields during installation.

teppokoivula avatar Apr 20 '18 09:04 teppokoivula