WYSIWYG theme variable (%t) is not replaced with Domain Theme

What do you mean by "afford it"?

Do you mean the stylesheet used inside the editing area? It should use the current domain you're on, since it does not explicitly select a specific domain. Wysiwyg grabs the stylesheets added to the theme group using drupal_add_css(), unless you tell it to only use the default editor stylesheet or define your own files.

Which CSS settings are you using in your editor profile(s)?
Which editor are you using?
Which Drupal theme are you using (if you've set the profile to use the active theme's styles).

I have no idea what you mean by "principal domain theme", all multisite sites have their own individual theme settings as far as I know, and they never request anything from any other domain than their current one (the sites will in practice not know about any other multisite even existing).

Getting the "current" theme is a bit tricky in Drupal, especially when used in combination with the Overlay. Anything opening in the Overlay will think your admin theme is the current theme, despite a different theme being used when viewing nodes etc. Therefore we try to do the path substitutions like this:

%b gets replaced by the value of base_path().
%t gets replaced by the value of drupal_get_path('theme', variable_get('theme_default', NULL)).
Unless your sites area in subfolders of the domain, that should roughly translate to /themes/bartik if you're using Bartik, or /sites/all/themes/mytheme/ if you're using something else.

CKEditor will take that path and put the current domain in front of it when performing requests inside the editing area. It gets the domain from the baseHref setting, which Wysiwyg sets to $GLOBALS['base_url'] . '/'.
Note: This part was accidentally removed from the latest Wysiwyg release, but is fixed in 7.x-2.x-dev. It not being there may confuse the editor about where the base folder is if JavaScript Aggregation is enabled in the Performance settings. Upgrade to 7.x-2.x-dev if you notice this issue.

In your example, with Bartik being the default in Drupal 7, you should be seeing requests to http://yourdomain.com/themes/bartik/css/wysiwyg.css.

If you want to request the stylesheets from a specific domain, you could maybe add the domain in front of the path like http://yourotherdomain.com%b%t/css/wysiwyg.css, but I'm not sure that's what you're asking for.

No Wysiwyg settings (or other Drupal settings) should be shared between domains in a multisite installation unless you use some tool to explicitly do that, like sharing database tables or using some sync module.

Sounds to me like both sites are set to use themeone as the admin theme? Not sure how %t oils end up the same on both sites otherwise.
You could try moving themeone to sites/domainone.com/themes/themeone (clear both site caches right after or things will get weird), domaintwo.com should have no access to it then.

I'm having the same issue.

When using the domain module, one can set a different theme per domain.
In my case, I have two domains with theme1 and theme2.

For content editing, I use Seven. In the WYSIWYG settings, I've entered %b%t/styles/wysiwyg.css. I'm expecting this to result in /sites/all/themes/theme1/styles/wysiwyg.css when editing content on domain1 and /sites/all/themes/theme2/styles/wysiwyg.css when editing content on the other domain.

I see that the WYSIWYG changes the theme with this line of code:

<?php
$settings['contentsCss'] = strtr($config['css_path'], array('%b' => base_path(), '%t' => drupal_get_path('theme', variable_get('theme_default', NULL))));
?>

So it used <?php variable_get('theme_default') ?> which should be fine. Let's move this issue to the Domain thread, as I think it belongs there.

Better title and Component

I think the problem is that variable_get('theme_default') is returning the wrong value. Please verify.

That could happen if:

* WYSIWYG runs before Domain Theme.
* Domain Theme isn't settings that value. (Which apparently it is not, because that would violate how hook_custom_theme() is defined.)

The problem here, actually, is that calling 'default_theme' seems to be unreliable. It does not account for hook_custom_theme(). See drupal_theme_initialize() for the gory details.

The same problem should appear if a menu item declares a custom theme.

The proper fix may be to call the $theme global instead of the variable_get. I say that because of the core logic here:

  // Only select the user selected theme if it is available in the
  // list of themes that can be accessed.
  $theme = !empty($user->theme) && drupal_theme_access($user->theme) ? $user->theme : variable_get('theme_default', 'bartik');

  // Allow modules to override the theme. Validation has already been performed
  // inside menu_get_custom_theme(), so we do not need to check it again here.
  $custom_theme = menu_get_custom_theme();
  $theme = !empty($custom_theme) ? $custom_theme : $theme;

That is, theme_default is not a reliable way to read the active theme for a page.

Another problem is that we don't need the current theme. This is mostly Seven, and we need to use the front-end theme in the back-end WYSIWYG.

What if WYSIWYG uses a piece of code like this to fetch the current theme instead of relying on variable_get alone?

<?php
/**
 * Helper function to retrieve the current theme.
 */
function wysiwyg_get_theme() {
  $theme = variable_get('theme_default', NULL);
  drupal_alter('wysiwyg_theme', $theme);
  return $theme;
}
?>

Then Domain Access could implement

<?php
function hook_wysiwyg_theme_alter(&$theme) {
  // Change the theme depending on the domain.
}
?>

Well, I'd like to avoid that, because it's module specific and therefore brittle. Besides, any other module that implements hook_custom_theme() will do the same.

I think the only way to retrieve the current theme is from the global $theme.

But isn't global $theme returning Seven when we are in the admin interface? That's not what we want, as the WYSIWYG should use the front-end theme.

Ugh. Perhaps, then, I should set $conf['theme_default'], but I'm afraid that might confuse other modules. We've had similar issues with Features and Display Suite.

So, should we set this back to the Domain Access module then?

No. I think you can do this in WYSIWYG module. That will let the module mirro what core is doing without having to ask other modules to handle a special case.

/**
* Helper function to retrieve the current theme.
*/
function wysiwyg_get_theme() {
  global $user;
  $theme = !empty($user->theme) && drupal_theme_access($user->theme) ? $user->theme : variable_get('theme_default', 'bartik');
  $custom_theme = menu_get_custom_theme();
  $theme = !empty($custom_theme) ? $custom_theme : $theme;
  return $theme;
}

menu_get_custom_theme() static caches, so the performance penalty is minimal.

Hi Ken,

I've tried the approach you suggest but it doesn't seem to work. The theme that is returned by this function is 'seven' instead of the theme that is used on the current domain. Any other suggestions?

I had this same issue and created a workaround. It's hackey enough that I think it should be its own module, but for the time being here's the idea:

My environment:
Drupal 7.x
Domain Access 7.x-3.10
WYSIWYG 7.x-2.2+33-dev

2 domains
each with their own separate theme
I moved the theme style sheets into the same directory heirarchy (/sites/all/themes/THEME_NAME/css/global.css) to try and resolve the above issue, but didn't work. For the purposes of this fix though I kept them in that spot.

In a custom module I had already built I added the workaround functionality in this way:

function MY_MODULE_menu() {
  $items = array();

  $items['MY_MODULE_load_domain_css/%MY_MODULE_css'] = array(
    'title' => 'Fix Domain Access wysiwyg css issue',
    'page callback' => 'MY_MODULE_return_domain_css',
    'page arguments' => array(1),
    'access arguments' => array('access content'),
    'load arguments' => array('%map', '%index'),
    'type' => MENU_CALLBACK,
  );
	
  return $items;
}

function MY_MODULE_css_load($arg, $map, $index){
  // Grab everything in the path starting with the CSS value (second argument)
  $css_path = implode('/', array_slice($map, $index));
  return $css_path; 
}

function MY_MODULE_return_domain_css($my_css_path){
  global $theme;
  $style_path = drupal_get_path("theme",$theme)."/".$my_css_path;
  if(file_exists($style_path)){
    header("content-type:text/css");
    print file_get_contents($style_path);
  }else{
    print "css file not found :".$style_path;
  }
}

Then for the WYSIWYG profile edit page in the CSS input I chose:

Editor CSS: Define CSS
Css path: /MY_MODULE_load_domain_css/css/global.css 

Important: as mentioned above I had moved both themes' css files to the ../css/global.css in their base theme folder for the above to work. I have ideas about how to get around this, and furthermore expand this functionality to include multiple style sheets, but for the moment this works.

Also important - this mechanism will load the WYSIWYG style sheet based on the current URL in the browser window and what domain that maps to in the Drupal system - it will not look for which domain the currently edited item is published to in order to load that appropriate style sheet.