After editing nodes user is redirected to the main domain
NeuZeitgeist - February 28, 2008 - 14:18
| Project: | Domain Access |
| Version: | 6.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Description
When user edites his own node on his own domain (http://user.mysite.com) after editing he is automaticaly redirected to the main domain http://mysite.com
How should I configure Domain access module so that user stays on his own domain http://user.mysite.com?
Thank you
#1
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.)
#2
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.
#3
You might try adding this code to
domain_form_alter<?php
// 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();
?>
#4
I'm lost in this module that is why I created new topic here http://drupal.org/node/228055 where I explane my tasks.
Thank you for your reponses.
#5
That snippet of code worked for me, FYI - I am no longer redirected to the main site after creating a node on a subdomain.
#6
Does it work in all cases and should it be added to the main module?
Testing needed.
#7
I added this code to domain.module in line 1125 and so on but it didn't work for me.
For torgosPizza. Could you explaine how did you add the code and what configuration of Domain access you had.
#8
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).
#9
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.
#10
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?
#11
And that is for a node assigned to 'all domains', right?
#12
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?
#13
no, but it can report all redirects that you are given
#14
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.
#15
It appears the forms that don't redirect to the root domain are the ones where drupal_redirect_form() gets called during their submission.
#16
Sounds like you are very close to an actual solution.
#17
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.
<?php//$base_url = rtrim($root['path'], '/');
$base_url = $_domain['scheme'] . '://' . $_domain['subdomain'];
?>
Node creation is tied to this line in settings_custom_url.inc somehow:
<?php$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.
#18
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.
<?phpif ($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'], '/');
}
?>
#19
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'))#20
I'll review that issue, thank you.
It's weird, but node edits don't have this issue. Neither do comments.
#21
What does devel tell you about redirects?
#22
I actually think we can fix this in hook_form_alter(), at least for Drupal 5.
See attached.
#23
The last patch does not account for node/add. Neither does this one.
#24
Sorry, I was on vacation. I will try these out and report back. Thanks very much.
#25
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.
#26
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?
#27
There is not. We are still looking for the best-case solution.
#28
I just tried to replicate this issue in HEAD and could not.
Can someone document steps for duplicating this issue in HEAD or rc6?
#29
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.
#30
I will try to replicate.
#31
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.
#32
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
#33
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!
#34
OK. #32 and #33 are not directly related to this issue, then.
#35
subscribing..
#36
This is not going in unless it gets tested. This is a very minor error that happens in rare cases.
#37
@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.
#38
6.x.2 is stable enough for production.
#39
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?).
#40
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?
#41
OK, this is not going in to the 6.x.2.0 release.
#42
#43
Here is one more try at a patch. Reviews? Please?
#44
Better patch, without a logic error and a simpler return.
#45
Final version, committed to HEAD.
#46
@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 :)
#47
This should work just fine. It sets a $_SESSION token and uses that to read the proper redirect.