Battle plan / Progress

Open question: How will all this affect domain's batch updating functionality?

Just committed a first change:

• Introduces a new settings form for specifying domain-specific variables at admin/structure/domain/variables. Only variables which have the "domain" property set to TRUE (in variable info) are shown in the list.
• Other modules can add variables by declaring their variables and setting info[domain] to TRUE. Added an implementation of hook_variable_info_alter() to mark system variables as being "available" as domain-specific variables (only exemplary atm).
• Replaced the domain settings page with a new page showing only domain-specific variables at admin/structure/domain/view/%domain/variables
• Introduced function domain_variable_switch which switches the active domain realm to a given domain and loads required variables if necessary; this is required for showing correct values if the current domain does not match the domain being edited

Next: fix original forms (i.e. system settings forms). Not sure yet how to resolve conflicts with the i18n module.

Added work done + more thoughts

Commited the 2nd major change, which makes domain variables work within system settings forms. A lot of code is based heavily on respective parts of i18n_variable module.

Next I'm going to try to get the Realm combination working for the site_slogan variable; I'm going to approach this via a new sub-module (domain_variable_i18n) for integrating both modules.

Hm, i18n_variable implements hook_module_implements_alter() to push its own implementations of hook_form_alter to the end of the list. Trying to override that, by implementing the same hook in a different module and pushing a different modules hook to the end of the list, does not seem to work, because hook_module_implements_alter() does not seem to be executed in the order of module weights (??).

This is a mess, and more realms/more modules will only make it worse... I'm considering going for generalized "variable realms ui" module.

Hm, I kindof skipped that first step...

I have created a new branch "7-x.1-x.-generalized", which contains four modules: domain_variable, domain_i18n_variable, variable_realm_admin and variable_realm_union.

• variable_realm_admin: provides a generalized admin interface for realms...
  • realm overview page: lists all realms, including keys, selected variables etc.
  • realm configuration pages: allow the selection of variables which belong to a realm
  • all systems forms are modified: each realm variable is annotate with something like "This is a domain variable", and for each realm which is used in a form a "info block" is added, which includes links for switching between the realms (essentially what i18n_variable offers at the moment applied to multiple realms).
  • to make all this work, there are a number of new keys for the "realm info array"... see variable_realm_admin.variable.inc
• variable_realm_union: allows the combination of realms
  • combined realms are defined by adding a new realm (hook_variable_realm_info) and by specifing the "union" key.
  • combined realms automatically take over variables from children, i.e. override their realm within forms
  • switching between realms with the realm switcher also affects combined realms
• domain_variable: provides "domain" realm
  • provides a form for editing only domain variables on each domain (incl. "reset")
  • declares which variables are available as domain variables (some don't work yet or may require special treatment)
• domain_i18n_variable: provides a "domain_language" realm
  • basically an example for how to use the variable_realm_union module
  • provides the combined realm (weight 100) and loads respective variables at hook_language_init()

Now we have multilingual, domain-aware page slogans :-)

There is a lot of todos in the code, and integrating this properly with i18n_variable and domain_conf will require a lot of testing...

The "realm admin" part is more or less the basis for getting the other parts working properly... IMO it should be part of the variable module, I have therefore created a separate issue for it: #1564462: Admin UI for variable_realm module

Edit: here's the todo list, which I posted on the other issue...

Variable Realm Admin: Remaining ToDo's / Open Questions:

• Fix system_theme_settings form: i18n_variable provides special treatment for theme settings -- I am not sure why or whether that needs to be generalized, and therefore haven't added it yet...
• API Documentation: extend documentation for hook_variable_realm_info() with description of new keys (see variable_realm_admin_variable_realm_info_alter()). There are also new hooks which should be added to API docs.
• Move hook_variable_realm_switch() into variable_realm, to allow other modules to act on realm switching. It is currently part of the realm admin module and only called when the realm-switcher block is used.
• Possibly improve the "realm overview" page: I added only what was useful to me during development, but users may want to see something else (?)
• Testing with i18n_variable module: I think most of it should work but I haven't tested it extensively... the theme settings form is one point on the list of things that might be broken now.
• Fix string translation in hook_variable_realm_info_alter(); I am not sure how to properly translate strings in the info hook, because the results do not seem to be cached per language. (Separate issue?)

Follow up tasks for the i18n_variable module, if this patch gets added to the variable module:

• Declare variable_realm_admin as new dependency
• Add new variable realm information (currently in variable_realm_admin.variable.inc)
• Remove i18n_variable_form_alter() and i18n_variable_module_implements_alter()
• Remove admin code for variable selection; reuse variable_realm_admin_realm_settings() for admin/config/regional/i18n/variable

The variable_realm_admin module has been committed so we can drop it from this other module. Also could you merge back everything into 7.x-1.x? (Just to avoid confussion if someone else joins in).

Done and done. Back to development on the main branch.

About realm_admin module, the idea for the 'variable_admin' module is that it is kind of an advanced module for people who wants to really hack variables, but not needed for normal operation, so I think we should stick to that idea, and move the 'realm API' part to variable_realm itself. I will take a look a the module to see which parts can go on each side if you don't mind.

Makes sense. The parts which would probably be moved are:

• The *_list variables which define the variables per realm (*_conf should only be required for configuration, so it can stay)
• parts of include/realm.info.inc
• probably all of include/system.forms.inc
• anything related to realm switching in the main module file
• hook_variable_realm_switch() hook invocation

[...] I still need to wrap my mind about realm_union module. Maybe domain_i18n could just use some hook_realm_alter() to merge that two realms into one. There's some room to build a lot more features on the Variable_Realm classes introduced in the last version of variable.

I was going to write up my thoughts on that separately. The basic idea is to modify the lists of available variables for each realm. Example:

• User selects the "page slogan" as a domain variable as well as a multilingual one.
• When saving respective selection pages the *_conf, and *_list variables get updated respectively, i.e. the page slogan is added.
• When the *_conf variables are updated, the union module checks if language and domain realms have any shared variables. If yes, it removes the shared variable (slogan in this case) from the respective *_list variables (domain + language), and adds it to the list of variables for the shared realm (union realm).

This means that the union realm is just another realm with a higher weight, i.e. something that's being handled quite well already :-)

The rebuild process (variable_realm_union_variables_rebuild()) is currently only triggered when a respective *_conf variable is updated, but we could also trigger it in other cases... e.g. anytime realm information is rebuilt, or cache cleared...

I have to admit that I have not looked at the Variable Realm classes at all...

Closing this issue; I think all remaining tasks are captured in #1565268: Step 1 - Provide a replacement for domain_conf, domain_settings (domain_variable), or can go into separate issues now.