Problem/Motivation
As reported in #8 this came done to a UI / UX problem.
The combined realms Domain+Language provided realm selectors on the pages which are configured as domain OR language dependent settings.
See project documentation and in particular https://www.drupal.org/node/1856844 for this module too.
Original report
Hello
The Domain Variable i18n module wasn't working for me. The admin forms weren't loading nor saving the values, the whole token-variable system was messed up (perhaps variable module changed?), and overall, it seemed broken (at least for me).
I've attempted to fix it with some changes. I've provided a patch bellow.
Highlights:
- The site settings now works with language and domain, reading and saving
- The variables form in the domain module settings page reads, but doesn't yet saves data
- The variables forms in the variable module does not read or write
- The new variables get properly read on bootstrap and loaded as variables (and tokens), thus effectively working for example in metatags
Here's the fixes:
- [domain_variable] hook_domain_bootstrap_full: it was crashing my system. moved the variable real initialization to hook_language_init
- [domain_variable] hook_language_init: added variable_realm_initialize('domain') -- now the system should be loading the variables when booting (not tested without i18n support)
- [domain_variable] hook_variable_info_alter: it felt incomplete and i arranged the array to look like the ones in variable module
- [domain_variable] hook_domain_delete: it felt wrong after the code i did for admin.inc in domain_variable_i18n module (not tested)
- [domain_variable_i18n] hook_menu: added menu entry to override the domain_variable menu entry
- [domain_variable_i18n] hook_variable_settings_form_alter: added the hook to override the site settings form
- [domain_variable_i18n] hook_language_init: now the system loads the variables when booting and into the frontpages without crashing. It's working fully in the token-variable integration of variable.module, and was tested with metatags
- [domain_variable_i18n] hook_domain_delete: should now also delete domain_language keys (not tested)
- [domain_variable_i18n] added a domain_variable_i18n_admin_variables function to build the variable form on the domain settings page
- [domain_variable_i18n] added a domain_variable_i18n_get function
- [both] small documentation and coding practices improvements
Hoping for a quick review and testing =)
Thanks!
Comments
Comment #1
lpalgarvio commentednew patch, with some code cleanup and bug fixing
Comment #2
adiatisThe patch doesn't work on latest dev but I applied manually and this is a perfect solution!
Thanks a lot!
Comment #3
merilainen commentedThe patch seems to apply to the stable release, but it doesn't seem to help in my case. For example site name never seems to save per domain per language.
Comment #4
merilainen commentedI updated the patch to work with the new 1.1 branch, seems to work nicely now.
Comment #5
yoruvo commentedEDIT: I must change my initial statement; the admin settings forms such as "Site information" do work for the most part.
I was able to change the site slogan and front page to be domain- and language-specific, however the site name is not loading or saving in the "Site information" form. How to remedy this?
EDIT again: I was able to get the site name field to work by going into the Domain settings and toggling off "Override site name with name of domain." I believe this should be warned against better. The way the site name value doesn't save in the Site information form is really strange and could probably be solved better.
Comment #6
joachim commentedThat patch is far too big and complex to review! An issue, and a patch, should cover a single problem, not fix all the fixes.
Also, please don't include whitespace fixes in patches that change functionality.
Lastly, isn't this covered by Variable module's admin UI?
> [domain_variable_i18n] hook_menu: added menu entry to override the domain_variable menu entry
Comment #7
clemens.tolboomThe supplied patches are not useful for review as to many things are taken care for. I'm trying to process the patch from #4 into smaller chunked issues currently listed here
Setting back to 7.x-1.x-dev as patch applied cleanly.
- code style / white space / code documentation
- bug fixes ?
- #2826095: Delete by realmkey
Will edit this later on
Comment #8
clemens.tolboomOn a clean Drupal install I enabled domain_variable_i18n, variable_admin plus their dependencies, added a language.
Reading https://www.drupal.org/node/1856908 I should see somewhere
After some more digging and especially configuring the variables for both domain and i18n the page is on ie /admin/config/system/variable/group/site_information which are the globals(?)
Saving ie The name of this website. This is a multilingual domain variable. is not working there.
But visiting ie admin/config/system/site-information I can edit domain+language specific values and they appear nicely in the database table 'variable_store'. Switching domain + language shows the expected values.
My pitfalls were:
- Inexperienced with the combination
- I expected an config + edit link on admin/config/system/variable/realm for domain+language but that is not how combined variables work. There are integrated into the normal UI pages with selectable combinations (in this/our case for domain language)
The patch tries to add variables for the combination but the variable checks for realm combinations when they defined in both realms so it is 'automagical'.
So I state this issue is not a bug but a support request and I'll close it as works as designed.
If you disagree please open a new issue with a descriptive bug and reference this issue.
Comment #9
clemens.tolboomAdded link to doc page.
Related question with similar answer in #1714474: How do I get this working