This first module (domain_variable) should be a drop-in replacement for the other domain modules handling variables per domain. Features:

- Provide a 'Domain' realm using variable_realm API which has a key for each domain.
- Select which variables should be configurable per domain (In domain_admin module atm).
- Provide some UI (For now following 'Multilingual variables' example) to configure such variables per domain.
- Replace any other variable related API funcion currently provided by domain_conf or domain_settings

Implementation:
- About run time replacement of variable values we should be ok with the current funcionality provided by variable_realm module.
- For the UI part we need the variable_realm module to handle the form_alter() of forms containing variables that are configurable for different realms so there are no clashes between different realm modules.
- Two options here are using form_alter() for existing settings forms and providing a full separated form for that realm variables. Maybe the second would be easier and cleaner.

For this case if we consider realms 'independent' of each other, we just need to take care or realm weights to decide which realm (language, domain) overrides the other. Two cases this module should handle:

1. No multilingual variables. Simple variables per domain. We have only one realm (domain).

2. We have several domains, each of them with a single language, though there are several languages. This would be mostly about not needing to repeat for each domain the variables that are language dependent. Domain overrides language and variables should be either per domain or per language but not both.

For more complex cases where we have different values per domain per language we'll consider a different module (variable_realm_union, domain_i18n_variables)

Comments

bforchhammer’s picture

bforchhammer commented

Two options here are using form_alter() for existing settings forms and providing a full separated form for that realm variables. Maybe the second would be easier and cleaner.

  • form_alter() for system forms can be found in variable_realm_admin/include/system.forms.inc :-) As you said in the other issue, this should possibly be moved into the variable realm module.
  • full separate form is provided by variable_domain.admin.inc.

2. We have several domains, each of them with a single language, though there are several languages. This would be mostly about not needing to repeat for each domain the variables that are language dependent.

I am not sure what you mean by the 2nd sentence. From how I see it, the user should just declare those variables as "domain specific" instead of "multilingual" in this case, even if they variable values are in different languages... no?

I'll try to write up a list of remaining tasks and issues some time during the week... What comes to mind at the moment:

  • Fix "special variables" (or check that they still work as domain specific), e.g. default language, theme settings, etc.
  • Add support for batch editing (hook_domain_batch())
  • Migrate existing values from domain_conf and domain_settings
jose reyero’s picture

jose reyero commented

This is almost done, most of the code is in variable_realm (dev). So we can now:
- Select which variables will be configurable per domain.
- Set values for that variables using (3 methods): on settings forms, on each domain config tab, using variable_realm_admin

What else do we need here?

bforchhammer’s picture

bforchhammer commented
Assigned: bforchhammer » Unassigned
  1. List of variables available as domain variables (select form) is currently not limited and shows all variables; in my initial patch I added a "domain" key to the variable array but I'm also open to other solutions...
  2. Add support for changing language_default variable (see hook_domain_bootstrap_full, domain_variable_js_maintain etc.)
  3. Check that "domain menu blocks" still work (see domain_variable_block_info and domain_variable_block_view).
  4. Remove _domain_variable_load_primary (?)
  5. If site_frontpage is a domain variable; adjust the label to the proper domain url
  6. Reimplement/fix domain_variable_domain_batch, i.e. make the domain batch update pages work again...
  7. Domain variables page is missing a "reset" button to delete domain specific varibale values
  8. Add drush command back in, for setting domain specific variables (?)
  9. Add migration path for existing users of domain_conf module; we should also something to ensure that domain_conf is disabled when domain_varibale is enabled to avoid conflicts.
  10. Check/fix domain-specific theme variables/settings
  11. Rebuild realm keys when new domain is created or existing domain deleted.
bforchhammer’s picture

bforchhammer commented
Assigned: Unassigned » bforchhammer

I'm going to work on some of the issues above now...

bforchhammer’s picture

bforchhammer commented

Done for today. Fixed points 1., 3. and 5.; had a go at 2 (see below).

2. Add support for changing language_default variable (see hook_domain_bootstrap_full, domain_variable_js_maintain etc.)

Problem 1: Current value is not selected on variable form (no radio button selected). This seems to be a problem with the variable module, as it also happens with domain_variable and variable_realm disabled. See #1585946: language_default form element ignores existing value.

Problem 2: The reason why domain_variable_js_maintain etc. were initially added, is because the "javascript hash" for javascript translation files is also stored in the language_default variable. This means, that the language_default variable needs to be updated whenever the javascript hash changes... (background: #1271810: Default language gets changed).

There is no hook which gets invoked when the javascript hash changes. So the easiest way may be to only store the langcode in the language_default variable, and only load the language object when the list of current variables is built... is there something like a "variable load callback"?

3. Check that "domain menu blocks" still work (see domain_variable_block_info and domain_variable_block_view).

I decided to completely remove domain menu blocks, as they seem to be a relic from D6; in D7 we can either let the theme output primary/secondary links directly, or let a different module do the job. Turning "menu_main_links_source" or "menu_secdonary_links_source" into domain specific variables is working fine either way.

jose reyero’s picture

jose reyero commented

About the language_default variable, I think we should keep it as an object because otherwise it will clash with any other module using this variable directly.

What we can do is changing this 'js hash' property on the fly wherever it is needed as default language is an object stored in the global $conf array.

jose reyero’s picture

jose reyero commented

About which variables can be selected for this realm, I think it doesn't make too much sense to restrict the list of variables (unlike i18n, for which there are usual variable types that need to be translatable, like string variables..).

However, if you think there's a top list of variables per domain that will do for most cases, I'm ok with that, as it will be easier to handle.

Thinking it could be interesting to have one option or maybe one more module (domain_variable_all?) that when enabling would allow all variables to be set for the realm.

Thinking also about how we could improve that variable select page so it is usable when all the variables are available...

bforchhammer’s picture

bforchhammer commented

Well, some variables don't make sense to have as domain variables (e.g. realm related ones), and other variables like language_default need special treatment. My thinking was that the user should only see variables which have been tested and confirmend to work... Hmm, maybe a negative list is easier. Not sure what's better in the long run.

If we stick to the restricted list, then I'd leave it up to developers to implements hook_variable_info_alter() for adding more variables.

Thinking also about how we could improve that variable select page so it is usable when all the variables are available...

I think sorting functionality (by name, by group, my module) would be a good start... :-)

bforchhammer’s picture

bforchhammer commented
Status: Active » Fixed

Basic functionality done, tested and working. :-)

I have created separate issues for remaining tasks:

jose reyero’s picture

jose reyero commented

Great, thanks, I'll follow up on each of them.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.