I've mentioned problems related to this within other issues, here's what's been happening on my test setup:

example.com
news.example.com

When any content is created or edited on news.example.com, after the edit, the user gets bounced back to example.com.

So, say it's an anonymous comment in response to a blog posting on news.example.com. The blog post is published to news.example.com and not any other affiliates nor "all affliliates". The comment gets posted in the right place, but on submitting it, the user ends up viewing the comment from example.com (which in some cases gives an access error) rather than staying on news.example.com.

The bouncing around is disorienting (especially since my affiliate subdomains will use various themes) and creates usability problems.

This is a pretty fresh Drupal install, I'm not sure if this is the default behaviour of the domain modules right now or if this is just an issue I'm having with my install.

Comments

Anonymous’s picture

Anonymous (not verified) commented

I should also note that this problem occurs with any content added, whether it's initial posting or editing. Although the example given is on comments it isn't just limited to those.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: support » bug
Priority: Normal » Critical

I'll have to investigate. I have not seen this behavior before. It may be a new bug, so I'll file it there until I can resolve this.

And thank for opening a new issue on this.

Marking critical, as this bug would hold up a release.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Do you have the SEO setting turned on? Any other configuration details would help, as would a description of the user roles and permissions.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

OK.

This is an unintended consequence of the SEO patch. If you disable the SEO setting, this behavior goes away.

Will have to investigate how to avoid this issue. This is a critical bug.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

OK. Try this pactch to domain_form_alter()

function domain_form_alter($form_id, &$form) {
  // If SEO is turned on, then form actions need to be absolute paths
  // to the currently active domain.  
  $seo = variable_get('domain_seo', 0);
  if ($seo) {
    global $_domain;
    $action = parse_url($form['#action']);
    if ($action['query']) {
      $action['path'] .= '?';  
    }
    $form['#action'] =  $_domain['scheme'] .'://'. $_domain['subdomain'] . $action['path'] . $action['query'];
  }
....

Starts at line 867 of domain.module.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Needs review
Anonymous’s picture

Anonymous (not verified) commented

Ahhh that may fix a similar problem with the SEO changes, but my issue is still occurring and I've tracked it down to a problem with $base_url.

What I've just done was wipe my database to test a clean install, no other modules enabled besides the default core ones and the domain access ones. My settings.php is default except for the cookie domain. Domain Access settings to default as well (so the SEO-friendly rewriting is not enabled). I create the subdomain news.example.com on the domain list and test posting just to that affiliate, works fine.

Then I try the Clean URLs test and of course theming messes up, so I change my settings.php for $base_url = 'http://example.com' and that is when domains start messing up with the bounce back issue as described. Clean URLs are not actually on at this point, just tested for.

Anonymous’s picture

Anonymous (not verified) commented

I'm getting very tempted to move to a subfolder type installation, which I'm guessing would just make this problem go away for me. There are similar issues related to themes and other modules, but essentially setting the $base_url manually fixes those but that's not so easily a workaround for Domain Access, because by its nature I wouldn't be setting $base_url for every subdomain, at least not in a settings.php for each subdomain (as in a multisite install).

Perhaps the solution is to configure a $base_url for each subdomain? Is that possible? And perhaps that could be done when creating a domain record?

Anonymous’s picture

Anonymous (not verified) commented

Okay, a simple, dirty workaround that would probably get a few frowns from people who know better. Change my $base_url in my settings.php to switch based upon the domain currently viewed:

Note: I've edited / updated this code in case anyone else reading this is tempted to use it in their own install. As per agentrickard's suggestion to peek into conf_init for security, I've borrowed the method there:

$base_url = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? 'https' : 'http';
$base_url .= '://'. preg_replace('/[^a-z0-9-:._]/i', '', $_SERVER['HTTP_HOST']);

Honestly though, it doesn't seem that much harsher of a workaround to me than hardcoding the $base_url per multisite configurations anyway. It does work and resolves my issue.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I get it. Since you are setting $base_url, I think you must do it dynamically.

If you don't set it manually, $base_url is set in conf_init().

http://api.drupal.org/api/function/conf_init/5

So this needs to be added to the documentation. I would suggest that you not set $base_url manually and find another solution to the theme issue.

Take a look at the security measures in conf_init() as well.

Question for this module: are the theme issues specific to Domain Access? Are they core themes or customizations that you have done?

If you are hardcoding paths in themes, try using drupal_get_path() instead.

Anonymous’s picture

Anonymous (not verified) commented

Well, now that I realize it, it's all really connected to Clean URLs and the suggested mod_rewrite rules as from http://drupal.org/node/43788

This was one of the first speedbumps I had with Drupal, and as pointed out on that link: the answer suggested everywhere I looked was to specify a $base_url in settings.php. Otherwise, paths get messed up and I end up with things such as '/admin/settings/themes/garland/style.css' when it should be '/themes/garland/style.css'. I'm sure it affects other paths as well, but themes are immediately noticeable when you're staring at a page without any stylesheets. These are core default themes, not modified in any way.

I don't really grok my regex or mod_rewrite rules, so I don't know of better settings appropriate for httpd.conf (not .htaccess).

Thanks for your patience in helping sort this out and I'm glad it's getting documented, because I'm sure someone else will trip over it using those suggested settings during install.

Anonymous’s picture

Anonymous (not verified) commented

Code updated in earlier comment (see #9 above) for security.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Well, there was a bug here, which is now fixed.

But I will also document that you can't (for obvious reasons) hardcode $base_url if you are using Domain Access.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Needs review » Closed (fixed)