I noticed another problem today, but I can not quote the error message because I returned the site to a previous backup.
I had a default post content type with the setting "Multilingual support" "Enabled" but not "Enabled, with translation".
I created Post-type content in Bulgarian language. Then I changed "Multilingual support" from "Enabled" to "Enabled, with translation".
And when I tried to translate this post from Bulgarian to English it was impossible, it appeared error message that there was no some table connected to module i18 - probably something from the old Drupal code. Moreover, even editing of the Bulgarian post became impossible and the same error was displayed.
I returned the site to a previous state from an backup archive where there was not a single post of the post content type. I made a settings of the default post content type even before I publish anything of this type to be "Enabled, with translation".
Then I created a post in Bulgarian, translated this post into English, and everything worked as expected and error-free.
The problem I see is that you can't change "Multilingual support" from "Enabled" to "Enabled, with translation" if some content of that type has already been created.
This can be very unpleasant if a significant amount of posts of a certain content type have already been created and the customer later decides that they want multilingual support and translation of existing content.
Comments
UPDATE!
After installing in the restored site, as I described above again (as in previous attempt) the module multiselect-1.x-1.0.1, activate it and set as a Widget type the same error appears again. This time I made a record of that error:
Error
Call to undefined function
i18n_taxonomy_allowed_values()
This appears on white screen.
Otherwise, the site works, the pages are accessible, but when you try to edit a page or translate, this error occurs.
To remove this error I had to delete the database and import it from a previous backup, as well as delete and restore the config folder (active / staging) also from a backup made before installing the multiselect-1.x-1.0.1.
Now I will try to do the post again and its translation without this module, if there are new problems I will share them here.
I have used the module multiselect-1.x-1.0.1 successfully before, but not on a multilingual site.
Hi amilenkov,
these might be unrelated problems.
1. Problem when switching from "Enabled" to "Enabled, with translation".
I'd suggest that you open an issue in the core issue queue.
Can you reproduce it on a plain install (without any contrib modules)?
Regarding "Call to undefined function i18n_taxonomy_allowed_values()".
At least multiselect does not call i18n_taxonomy_allowed_values anywhere. It must be another module. Can you do a recursive grep to figure out the module that causes this? (I suppose you have shell access?)
Looks like one of your modules didn't properly declare a dependency on i18n_taxonomy or doesn't catch the error with a "module_exists" before calling i18n_taxonomy_allowed_values().
You're right, this has nothing to do with multiselect module.
After restoring the site from an archive backup without the multiselect module, today I get the same problem and error message after setting the Tags taxonomy (which is installed by the system default for Post content type) to be "Multilingual support - Enabled" and changed the Widget type for this field to Select list.
Then when I try to edit or translate a Post publication, a white screen appears with the same error: Call to undefined function i18n_taxonomy_allowed_values ().
I don't have the knowledge (I'm more of a website designer and copy righter than a programmer or a developer and do not have shell access) to do what you offer, but I did something else:
I downloaded the entire contents of the public folder from my hosting on the site folder on my computer, as well as the config folder, and used Adobe Dreamweaver to search by program code in the folder files.
The only thing similar to this error message I found in the field.field.field_tags.json file in the configuration folder, namely line "options_list_callback": "i18n_taxonomy_allowed_values"
I remind you, the error was Error
Call to undefined function
i18n_taxonomy_allowed_values ()
At the end, however, the problem was solved in a completely different and easy way.
I deleted the default Tags field of the Post content type, that comes with the system installation, and re-created it identically with the same name and Term reference field type.
And now everything works fine, the terms in posts type content are translated, tagged and I even I installed the multiselect-1.x-1.0.1 module and it works without errors.
Strange, but even before, when working with Drupal 6 and 7, I sometimes had fields that do not work normally, as well as content types, and after they are deleted and re-created with same configuration new elements work without errors.
I did not understand the reason for this error, but I share this information here because I guess it is useful for system developers to know what problems happen to users.
I also apologize for not writing in github - I have a registration there, but I have a hard time navigating the rules for working with github and I also don't have time to study a new profession yet, because working with github is a real art and I guess it requires years of training.
I also assume that systems like Backdrop CMS are intended to be accessible to people without very in-depth knowledge of programming and software development, for which I am grateful for the existence of this forum, in which people with other training and education can write and learn how to use Backdrop CMS.
Thanks for the help and time spent on my problem!
Hi amilenkov,
I'm glad you sorted things out.
Contributing on Github is completely optional. If you feel more comfortable to post here in the forum - that's fine, too.
Regarding the options_list_callback setting in the field.field.field_tags.json file:
Could it be that your Backdrop install had i18n_taxonomy enabled in the past? Possibly for testing purposes? Has it been installed as Backdrop or has it been upgraded from Drupal?
had i18n_taxonomy enabled in the past?
I don't think so, but I'm only 80% sure. I remember testing github.com/backdrop-contrib/i18n once but I think it was on another test site.
It may have been this site as well, because I need much better multilingual support for that site, but during the test I saw that the i18n is not ready for secure operation yet. I may then have restored from an archive version without i18n by deleting and replacing the database with the archived one, but only recently I realized that for a real recovery from an archive, the configuration folder must also be overwritten.
The site is original with Backdrop, it is not an upgrade of Drupal, its initial version, with which it started is 1.15.1, yesterday I updated it to 1.16.2.
I checked and saw that in many archive copies of my other sites in the field.field.field_tags.json file there is no such record "options_list_callback": "i18n_taxonomy_allowed_values"
May be it is best to reinstall the site again and cleanly by transferring the little content available . So far I have spending more time on the theme design, but it is easy to move the theme to a new installation.
I know from experience that when such errors occur, it is a sign of errors in the system, usually from experimenting with different modules and changes in settings, which are not always canceled without leaving traces and which later deteriorate and lead to bigger troubles.