Remove hook_form_alter from Domain Conf

It is very likely that we can leverage hook_domainbatch() to provide the definitions of each setting. Then we would dynamically build the form based on the elements defined by that hook.

And the attached patch (committed) does just that!

There's one UI issue this new patch creates. Primary domain options appear twice in the selection - once as "Use primary domain settings" and the second time as the value of primary domain setting e.g. if there's three languages enabled on the primary domain (EN, ES, RU and EN is marked as default) then in the language selection there's 4 options (primary domain setting, EN, ES, RU). There is no way to tell in subdomain settings if EN was selected because it uses primary domain setting or it was set to EN.

Just my 2 cents.

Suggested fix? I am open to ideas here. What we need, though, is a means to say 'do not set a value for this variable for this domain'.

I think all we really need to do here is to eliminate duplicates in the UI eg. hide the default language if the variable is set to "primary domain" which also translates into "do not set a value for this variable for this domain".

This method should apply to all select elements not just language.

Attached patch is one way around it.

I wonder if we should apply this, in fact, to all form elements here.

Perhaps a better approach is (thinking from UI perspective):
- show two radio options. let's call them "Use primary domain settings" and "Apply custom settings"
- if "apply custom settings" is selected show all available values for selects (w/o "Use primary domain settings") and textfield/textarea/radios etc for the rest as it stands at the moment
- if "use primary domain settings" is chosen hide selects/textfields/textareas/radios for custom settings.

Some jQuery magic can take care of hiding form elements depending on radio option value.
Doing it this way would require creating an additional form element with #type = radios though...

Any other ideas?

I don't know about the patch in #5, since that would make the Domain Conf form out of sync with the batch update form. Perhaps we just leave it alone?

On the topic of this overall issue, I just committed the attached.

I think we can leave this as is in HEAD atm unless there are any comments?

The problem left is with Domain batch operations, which inherit the default variable values from the domain the form(s) are entered on, which is undesireable and (at least) needs to be noted in the UI and the docs.

I simply added a warning. Patch attached.

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