Closed (fixed)
Project:
Domain
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
14 Jun 2010 at 20:52 UTC
Updated:
10 Oct 2011 at 22:11 UTC
Jump to comment: Most recent file
Comments
Comment #1
agentrickardPatches welcome.
New features go in 7.x.3.
In the interim, you can do this quite easily in template.php. Just read the global $_domain value or use domain_get_domain().
Comment #2
iantresman commentedThanks for the pointer.
Comment #3
agentrickardLet's add a token-based element to BODY that can be either an ID or a CLASS, as a setting.
Comment #4
espirates commentedHas this been implemented yet ? It's a great idea.
Comment #5
agentrickardNope.
Comment #6
iantresman commentedIn retrospect, the only time this would be useful, is if two domain alias each other, and serve the same Drupal installation. I currently use the multi-site set-up, where all sites share the same Drupal core, but each domain has its own subdirectory and settings, and so I think that each one has its own instance of Domain Access.
The other option is to add your own class/id in your theme's template.php template file, which usual specifies the HTML <body> tag. eg. something like this:
<body <?php echo 'class="'.$body_classes.'"'; id='$_SERVER["HTTP_HOST"]'; ' ?> > //(not checked for syntax).However, I'm not sure where id/classes can have all the characters allowed by a domain, eg. id="www.mydomain.com", in which case you'll have to filter out the dots with some extra PHP.
Comment #7
agentrickardThere are a few other cases where this is useful, especially if your domains share a common theme and you just want to change a background color.
Comment #8
doublejosh commentedSame use case here.
I use the same theme on a few domains, but have different content.
Would like to have a body class to make more subtle changes and not maintain a few themes.
Comment #9
escoles commentedHere's a use case:
We are using Domain Access to centralize administration for ad-campaign landing pages at "vanity" domains.
Landing pages must frequently have highly-customized presentation -- i.e., custom entries in the stylesheet that pertain only to that domain (e.g.
http://ourproductistasty.com/). [can also use Code Per Node or something like that, but that can be a maintenance headache.] Typically (in the theme we use) this is done by prefixing style rules withbody.[page-identifying class]-- e.g.,body.partner-landing-page.In some cases, we need to set one of these landing pages as the home page. In the example case,
body.partner-landing-pagewould not be present when that page is rendered as the home page ofhttp://ourproductistasty.com/. The simple workaround is to usebody.front, which is available - but that would affect the home pages of all other landing page "vanity" domains (e.g.,http://ourproductisSAVORY/).That's just one use-case. But this is just generally the kind of thing you'd find people using all the time if they had it. As noted, we can add it in any one of several ways in our themes, but if it's just there by default, even better -- less migration work when updating/upgrading themes, fewer maintenance issues.
Comment #10
doublejosh commentedI did it at the theme layer in template.php (Drupal 6)...
Comment #11
agentrickardHere's a patch for 7.x.3. Needs a test.
The patch exposes the following settings form (see attached). These values are returned as CSS-safe class names.
Comment #12
agentrickardAnd a patch with tests. Committed.
I don't know how portable this is back to d6, but if someone wants to try, I can commit it.