After editing nodes user is redirected to the main domain

Try turning off the "New content settings:" under Admin > Build > Domain

New content settings:
 [ ]  Show on all affiliate sites
 [x] Only show on selected sites
If set, this value will automatically assign new content to all sites.

If that doesn't work, give the users the 'view domain publishing' permission and set the following:

Content editing forms: *
 [ ]  Pass the default form values as hidden fields
 [ ]  Take user to the default domain
 [x] Take user to their assigned domain
 [ ]  Show user their publishing options

If _that_ doesn't work, please send me a real url where I can test this.

(Oh, and please use example.com -- that's what it is for.)

To be clear. This happens when:

-- The node is assigned to more than one domain.
-- SEO optimization is turned on.

What happens is that the user is redirected to the first domain match. This happens after the node is submitted.

When the Domain Source module is working correctly (see http://drupal.org/node/227003), this problem should fix itself, as the "source" domain for the link should be set to the user's domain.

It might also be possible to force this behavior, by setting a #redirect via hook_form_alter.

You might try adding this code to domain_form_alter

    // Some options will be passed as hidden values, we need to run some checks on those.
    if ($form['#node']->nid) {
      $raw = $form['#node']->domains;
    }  
    else {
      $raw = $default;
    }

    // New code here -->
    if ($form['#node']->nid) {
      $form['#redirect'] = substr(domain_get_uri($_domain), 0, -5);  
    }
   // end new code. 

   $options = array();

That snippet of code worked for me, FYI - I am no longer redirected to the main site after creating a node on a subdomain.

Does it work in all cases and should it be added to the main module?

Testing needed.

I just added it as agentrickard shows here. Although I only found one spot to add it to, perhaps there are others I missed. Either way it appears that I can create content on sub.example.com and it directs me to sub.example.com instead of www.example.com (which is the default domain).

For the moment, I'm calling this behavior "by design." Though that is debatable.

What happens is that the form submission sends the user to the first matching "source" domain. The correct use of Domain Source should eliminate this issue.

I am keeping this open, but it will not be part of the 5.x.1.1 release unless more testing is done.

I'm having a similar problem, but it is at node creation instead. Users are being kicked back to the primary domain, and they seldom have rights to view their newly-created content on this domain. I am using SEO, and that's what's weird: the action on the forms is the absolute URL with the correct subdomain. Previews remain on the correct subdomain, and so do comments, but node creation boots back to root.

Any thoughts? I am going to keep investigating. I tried the above patch, but it didn't help, I think because at node creation we don't have a nid yet so it gets bypassed?

And that is for a node assigned to 'all domains', right?

Nope, only assigned to the current, active domain. I thought it might be tied to the OG integration somehow, but I've tested it with content types that aren't in the "audience targeting system", and it happens there too.

Can devel track all the hook_nodeapi hoops a node jumps through on its way to being created?

no, but it can report all redirects that you are given

Okay, enabling that I can see this is happening for other forms, not just node creation. If I go to http://sub.example.com/admin/settings/devel, I can see that is also the form action. Then somewhere along the line after submission, a drupal_goto is fired that brings me back to http://example.com/admin/settings/devel.

It still isn't happening with edits or comments. That is, those go to the correct subdomain still.

I checked with devel_forminspect to see if they were getting a #redirect property and they don't seem to be.

Also I've just noticed it stops happening if I turn off SEO.

It appears the forms that don't redirect to the root domain are the ones where drupal_redirect_form() gets called during their submission.

Sounds like you are very close to an actual solution.

This change makes content published to all domains default to being shown on the current domain instead of the root, which I rather like for my uses. It also mean the admin forms stay on the current domain.

            //$base_url = rtrim($root['path'], '/');
            $base_url = $_domain['scheme'] . '://' . $_domain['subdomain'];

Node creation is tied to this line in settings_custom_url.inc somehow:

            $base_url = rtrim($domain[$nid]['path'], '/');

That is also tied to node viewing though; changing it like the one above makes all content links write to the current domain, even if the user doesn't have view rights there. So I need to look into a way of detecting if we're coming in from the node creation form here.

Here we go. With this modification to settings_custom_url.ing, users are staying on the current domain after node creation now, and admin forms also stay on the current domain. It seems to have the side effect of forcing many more links to the current domain while in the admin screens, but since the admins on my site have rights to view everything everywhere, I don't foresee this being a problem.

          if ($domain[$nid] != -1 && $domain[$nid]['domain_id'] != $_domain['domain_id']) {
            $absolute = TRUE;
            // In this case, the $base_url cannot have a trailing slash
            $referer = explode('/', referer_uri());
            if (arg(0) == 'node' && arg(1) == 'add')
              $base_url = $_domain['scheme'] . '://' . $_domain['subdomain'];
            else 
              $base_url = rtrim($domain[$nid]['path'], '/');
          }
        }
        // If strict SEO rules are enabled, we set "all affiliate" links to the root domain.
        // Only needed if we are not on the root domain.
        else if ($seo && $_domain['domain_id'] != $root['domain_id']) {
          $absolute = TRUE;
            // In this case, the $base_url cannot have a trailing slash
            if (arg(0) == 'admin')
              $base_url = $_domain['scheme'] . '://' . $_domain['subdomain'];
            else
              $base_url = rtrim($root['path'], '/');
        }

I wonder how this relates to the patch in http://drupal.org/node/268779 -- though that would have to be backported to the 5 branch.

I think this line:

            if (arg(0) == 'node' && arg(1) == 'add')

Might also need to apply to edits, and such.

            if (arg(0) == 'node' && (arg(1) == 'add' || arg(2) == 'edit'))

I'll review that issue, thank you.

It's weird, but node edits don't have this issue. Neither do comments.

What does devel tell you about redirects?

I actually think we can fix this in hook_form_alter(), at least for Drupal 5.

See attached.

The last patch does not account for node/add. Neither does this one.

Sorry, I was on vacation. I will try these out and report back. Thanks very much.

I am using DA for 6.4 and I had the same problem arise and it happened when my created role ("siteowner") had the "view domain publishing" ticked which I am still confused why that redirect problem happen. But for me it was as simple as unticking it.

I am having the same problem in 6.x-2.0-rc6. I do not have SEO installed. View Domain Publishing is not ticked. Was the patch in #23 incorporated into version 6? Is there some other solution to this?

There is not. We are still looking for the best-case solution.

I just tried to replicate this issue in HEAD and could not.

Can someone document steps for duplicating this issue in HEAD or rc6?

I have same problem here when a user create a new node in his subdomain, the form redirect to the main domain with an Access denied message. Each user domain must create only his own nodes and keep in his subdomain.

I will try to replicate.

I could only replicate this error if the node was assigned to 'all affiliates', which should not throw an access denied.

There does not seem to be any way to stop this behavior, since node_form_submit() explicitly sets the redirect value.

It seems that you can prevent this behavior by setting DA's 'Default source domain' setting to 'Do not change domain'.

The attached patch also seems to work, but needs testing to make sure it doesn't cause any unusual errors.

Hello agentrickard,

The patch didn't work.

This is my configuration:

Drupal 6.10 with only the modules Domain Access rc6 and Views active. I test it with the HEAD version too.

My user have:

Domain access settings:
[] domain.com
[x] user.domain.com

Roles:
[] authenticated user
[x] editor

// ------------------------------------------------

New content settings:
[ ] Show on all affiliate sites
[x] Only show on selected sites

Content editing forms:
[ ] Pass the default form values as hidden fields
[ ] Take user to the default domain
[x] Take user to their assigned domain
[ ] Show user their publishing options

Default source domain:
Do not change domain <----- If I change it to any other option nothing happend. Ever redirect to the main domain.

// ------------------------------------------------

In node settings/Domain node types: unchecked all

In node settings/Domain node editing: unchecked all

In permissions I have only checked this under my editor role:

delete domain nodes
edit domain nodes
set domain access

// ------------------------------------------------

Notice that the snipped in #3 fix the problem only when edit a node

// ------------------------------------------------

The idea of my site is to have a group of users (role) with his own subdomains, where each one only can create nodes under his domain. All work fine exept that after create one is redirected to the main domain with the Access denied error.

I hope this information is useful

I found the problem!!

I did a fresh install of Drupal and Domain Access and in the process I notice that in some moment I set $base_url to "http://www.mydomain.com" this is the cause of the redirect!

OK. #32 and #33 are not directly related to this issue, then.

subscribing..

This is not going in unless it gets tested. This is a very minor error that happens in rare cases.

@agentrickard: I'm experiencing the same issue using DA 6.x-1.2

I've tried the suggestions per #30
✓ select 'Only show on selected sites' under 'New content settings'
✓ make sure user's role has 'view domain publishing' permission
✓ select 'Take user to their assigned domain' under 'Content editing forms'
✓ set DA's 'Default source domain' setting to 'Do not change domain'.
✓ make sure settings.php did not set a $base_url

But i still get the same results - after creating a node published to the secondary domain, the user is redirected to the primary domain.

I'll be happy to try the patch in #31, but - is do the changes in this patch necessarily need to apply to the 2.x version? I ask because 1.x is stable while 2.x is still RC, and we're experiencing this problem on a fairly large, live site. We could upgrade to 2.x, but I want to ask your advice about this first.

6.x.2 is stable enough for production.

Following up on #37. I am working on the same site with scottrigby:

* We have two domains.
* We are publishing the node to the first domain.
* After node creation the user is redirected to the second domain.
* The user receives an access denied message because the node isn't published to the second domain.

We solved this by turning off the SEO optimization option.

It seems like the SEO optimization option for Domain Access creates a canonical URL for the node based on the primary domain and redirects to that (agentrickard - is that the case?).

In most cases, yes, if the node is assigned to All Affiliates and the default domain. Otherwise it goes to the first match.

Does that patch in #31 do anything?

OK, this is not going in to the 6.x.2.0 release.

Here is one more try at a patch. Reviews? Please?

Better patch, without a logic error and a simpler return.

Final version, committed to HEAD.

@agentrickard: hi and thanks for all of this work - ezraw & I would have loved to test this on the site we experienced issues with except we're currently not in a position to do that - we'll keep this issue on our radar and give feedback when we can :)

This should work just fine. It sets a $_SESSION token and uses that to read the proper redirect.

This happens to me with latest 6.x-2.3, for nodes that are only published in one domain.
I don't have SEO checked.

I create a node in domain A.example.com (the user has no domain access permissions, and nodes are set to be published to the active domain). Clicking submit, I am redirected to example.com/en/content/[title].
Using a content-editor account I get 'Access denied' page after the redirection. But looking at the same URL from a privileged user I can view the content. This leads me to believe that there is some flawed logic that causes the node to be visible from the primary domain, and thus the redirection to that domain after submit of new content.

No, it's not coming from DA. We've been over and over this issue. The session handling is the best we can do. The redirect is coming from some other source.

Other redirects are caused by either a) core's node_submit() function or b) another module interfering.

This is a won't fix / fixed as best we can issue. If you want to try alternatives, there is a new patch to test.

#683400: ImageField Tokens causes redirect to main domain on node save

Privleged users can always see all nodes. This is a well-documented fact.

CLOSING.

After a bit of xdebugging, I found the source in http://drupal.org/project/icanlocalize module. It seems it calls some (premature?) node_load which confuses domain_source_lookup.

However, the attached patch fixed that.
The current code assumes the $domains array has some data in it, calling current($domains), and getting FALSE in response, which then translates into the 0, which means the first domain in the list of domains. I am not sure I am not adding another problem with this fix, but it definitely looks like an issue that needs a fix.

I'm reopening this thread so that @agentrickard can see comment #50. I've been having essentially the same problem, as described (by someone else) in this issue: #748614: Forwarded to main domain after creating node with a viewfield, which I'm going to move into the Domain Access issue queue.

After debugging, I wound up in the same place as @yhager (domain_source_lookup() in domain_source.module), and his patch in comment #50 fixed my problem. As far as I can tell, the patch doesn't break anything else, but I'd like to hear @agentrickard's thoughts on it.

I'm using Domain Access 6.x-2.4, not 2.3.

I see. This seems to be related to #752570: static variable in domain_get_node_domains in that some modules may call a node_load() somewhere during the node_save() process (which is wrong, IMO) and things get confused.

Does this only happen when a node is first created? Because the $domains your patch checks should _never_ be empty at the point at which it is called.

Also note that I could not replicate surgeonbor's issue with Viewfield.

In my case, the issue only happens when a new node is being created. It only happens with nodes that contain Viewfields, and if I disable the Viewfields the problem disappears.

Yes. I tried that, and had no problems.

This is why I closed the original issue. It's messy, unpredictable, and handled as best we can. Unfortunately, the solution uses session handling, which is not cross-domain.

There is another patch attempt over here that might be a 'better' fix: #683400: ImageField Tokens causes redirect to main domain on node save patch in #9.

I tried that patch earlier and it didn't solve my particular issue.

I suspect I can't replicate your issue because the View you're using has a formatter or handler that calls a node_load(), where mine does not, AFAIK.

I'll look at the formatter & handlers in the view to see if I can track down something useful.

You're saying that the patch in #50 is a band-aid for bugs in other modules, and that it's not a D.A. issue, but I'm noticing the "(which is wrong, IMO)" in your comment #52. Are these other modules absolutely *wrong* (based on some established Drupal convention), or is this an issue of other module writers not having the same "O"? Would applying the patch allow for the possibility that some modules might call node_load during the node_save process without worrying about how it interacts with D.A.?

I don't understand D.A., or the node_save process, well enough to have a strong opinion on this. It seems like there are several modules that elicit this quirk, though.

I appreciate all your responses. Thanks.

Well, the issue is that Domain Access itself _does not issue these redirects_. They are coming from somewhere else. Typically from node_submit(), which sets a hard redirect value to node/NID.

The code that this patch touches has _nothing_ to do with issuing redirects, AFAIK. Domain Source does not issue a redirect. Some other module is doing it.

One other thing to check is whether you (or another module) is setting $base_url manually. That would force the node_submit() redirect to $base_url/node/NID.

And, no, modules should not be calling node_load() during node_save() because the $node object is already populated with _volatile_ information that may affect the storage of data that is called by node_load(). So calling node_load() during a save operation would give all kinds of false results, depending on when in the call stack it occurs.

Setting back to won't fix.

I also do not understand too much what is happening in this issue, but I can say that #50 just solved my "redirect to Main domain on save" problem.

Maybe I missed it, is there some reason *not* to commit the patch in #50? In other words, (and this is certainly possible) does the patch in #50 cause any other problematic behavior with D.A.? If not and it helps resolve even a few conflicts, then why not commit it?

I'll re-open and we can consider. I'm shocked that #50 does anything, actually.

OK, I committed #50. Marking as fixed.

Thanks for the follow-up!

I ran the patch in #50, worked for me, thanks

This is being discussed in your other issue. #683400: ImageField Tokens causes redirect to main domain on node save

This is still an issue for me, any update on a fix?