Problem/Motivation
Overall cause: The samlauth module
- has one big config (non-entity) object with a gazillion settings, among which are three translatable labels;
- installs only default minimal config, with no default values for those labels.
- does not set a langcode with the installed config. (Which is fine in this case, AFAICT, but I'm not 100% sure.)
Effects / issues arising from this later:
- On a single-language EN site, after setting one of those labels, Configuration Inspector reports an error:
The samlauth.authentication config object must specify a language code, because it contains translatable values.. (No practical effects observed from this error yet.) - On a single-langage non-EN site, a strange bug appears in the config translation screen, until (e.g.?) another module is installed.
I wasn't sure if 1. is an issue with samlauth or Core. I'm pretty sure 2. is a Core issue, but trying to determine what the precise cause was... sent me down a rabbit hole of interrelated Core issues.
Proposed resolution
I don't see any way to 100% effectively solve issue 1, except code that ensures a default language is set during Config::save().
Luckily, the current proposed in-progress MR for #3337864-41: Introduce a dedicated "Configuration default language" different from "Site default language" does just that!
So: postpone.
(I was testing all kinds of permutations to figure out whether I should e.g. always set langcode = en on install, and what effects that would have. But stopped when I saw the related issue.)
Steps to reproduce
Issue 1:
drush si; drush en samlauth # works the same, regardless whether config_translation is enabled too-
drush en config_inspector drush config:inspect --only-error --detail samlauth.authentication -> no errors drush cset samlauth.authentication login_link_title 'SAML login' # works the same if we swap 2 and 3 commands-
drush config:inspect --only-error --detail samlauth.authentication ➜ 🤖 Analyzing… Legend for Data: ✅❓ → Correct primitive type, detailed validation impossible. ✅✅ → Correct primitive type, passed all validation constraints. --------------------------- --------- ------------- ------------------------------- Key Status Validatable Data --------------------------- --------- ------------- ------------------------------- samlauth.authentication Correct 61% 1 errors samlauth.authentication: Correct Validatable The samlauth.authentication config object must specify a language code, because it contains translatable values. --------------------------- --------- ------------- ------------------------------- -
drush cdel samlauth.authentication login_link_title drush config:inspect --only-error --detail samlauth.authentication -> no errors
Issue 2:
drush si --locale=de; drush en samlauth config_translation config_inspectordrush config:get / config:export: no language code (and no defaults for values that were not explicitly set)- "Übersetzungen für SAML link titles" tab (admin/config/people/saml/translate) DOES NOT show / is inaccessible.
drush cset samlauth.authentication login_link_title 'SAML login'(or do same through UI)drush config:get / config:export: still same as 2a.- admin/config/people/saml/translate tab shows, screen shows 2 languages:
Deutsch (with 'add' button)andUnbekannt (en) (Original)(Note in admin/config/regional/language, only "Deutsch" is enabled) - If you at this moment try to add DE translations through the UI, there's a fatal error, because in
ConfigTranslationFormBase::buildform()
( $langcode = $this->mapper->getLangcode() ) === 'en' ( $this->sourceLanguage = $this->languageManager->getLanguage($langcode) ) === NULLwhich causes a fatal PHP TypeError in the
$form_element->getTranslationBuild($this->sourceLanguage, ...call.
drush en ban # or any module:- admin/config/people/saml/translate shows 1 language: "Deutsch (Original)"
drush config:inspect --only-error --detail samlauth.authentication: no errordrush config:gethas langcode=de now. Set by:
public function batchUpdateDefaultConfigLangcodes(array|\ArrayAccess &$context): void { $this->localeConfigManager->updateDefaultConfigLangcodes();(#2905295: Configuration language being overwritten during module install would change this code, but is not progressing.)
At this point I stopped trying to reproduce things + testing whether adding 'langcode = en' on install would solve everything... and didn't try multi-language situations, because I read the code from #3337864-41: Introduce a dedicated "Configuration default language" different from "Site default language".
If that goes through: close this. If not: reevaluate.
Comments
Comment #2
roderikComment #3
roderikComment #4
roderik