Interactions with admin/themes, admin/site info, frontpage module

rc4 is no longer supported.

I still don't quite understand your reasoning. Here's why.

-- Settings for the Primary domain (domain 0) are still configured via normal forms.
-- Settings for subdomains are optional. If you don't use Domain Conf or Domain Theme -- or do not set them for a specific domain, they simply inherit the values from the base install.

Is your primary domain not the same as the base install for your site?

The issue is the {variables} table in most cases. There is one {variables} table, administered normally. Domain Conf allows the selective override of certain elements of this table on a per-domain basis.

Thinking about it -- it may just be a question of training your users. How many people do you allow to configure domains on your site?

It may be possible to allow the behavior that you expect -- it is also possible to display messages (and we do in some cases) that tell users what happens when certain forms are being used.

I suspect this issue will stay open for a while, as I'd like to know what other users think.

Closed for lack of interest.

Please do not make personal assumptions when trying to state your case. It is insulting.

I closed this issue because no one seconded your suggestion, which leads me to believe that you are the only person (or group) who feels this way.

If you implement hook_domainwarnings(), you can put a warning message on any form that you like -- see API.php for documentation.

A patch to implement hook_domainwarnings() in Domain Theme -- and perhaps to move the function into core Domain, so that it works for all modules, would be worth review.

And here is the above patch. I do like the idea of moving these warnings out of Domain Conf.

To enable this for the frontpage module -- which I do not recommend using -- you would need to implement hook_domainwarning() separately. You can also use hook_domainconf() to add additional elements to the domain-specific configuration pages.

I'm a new Drupal user, and support the reasoning of 1.kenthomas UI statement. It took me a little while to realize that I had to use the Domain-Theme menu to change the theme on the current domain, and that the 'normal' theme menu changed Site0. I certainly assumed that the 'normal' theme menu would affect the currently selected domain.

Is that a review of that patch?

No, it was meant to be a comment on the OP.

Well, the theme rules follow the rules for every other "special" domain setting. So my instinct is to go with the patch -- which simply provides a warning that the form needs to be entered from the main domain. This doesn't seem like a major issue to me, but I've never been bitten by it.

I have refactored the warnings, and added warnings to additional forms. Committed to 5.x branch.

Fixed in HEAD.

If you want this to wok with non-core modules, you need to implement the following hook in a custom module file.

/**
 *  Allows a warning message to be printed when entering specific forms that
 *  may have values that vary on each domain.
 *
 * @return
 *  An array of form_id values representing forms that require warnings.
 *
 * @ingroup domain_hooks
 */
function hook_domainwarnings() {
  // These are the forms for variables set by Domain Conf.
  return array(
    'system_admin_theme_settings',
    'system_date_time_settings',
    'system_site_information_settings',
    'system_site_maintenance_settings'
  );
}