First time node save gets redirected to main domain
| Project: | Domain Access |
| Version: | 6.x-2.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
It took my entire day, but here are all my findings on this one. First of all description of the bug:
Domain A = main domain aka domain_id 0
Domain B = second domain aka domain_id 2
When I create a node on Domain B which should only be available to Domain B with source domain B as well and hit the save button it gets saved, but then gets a redirect to the node but on the main domain aka Domain A.
At first I thought it might have something to do with #623394: No $_domain Global in domain_node_save_redirect, but it seems that function is merely there for nodes that created on for example Domain A that are intended for Domain B so you get redirected to the right "viewing" domain when you save it. And after checking that functionality that functions seems to be working just fine.
After that I also checked what it does when i update a node. Updating a node seems to be working just fine and I stay on the correct domain. So it seems to only happen on first time save.
For now Ive reverted back to RC9, but if you need more info just give me a nudge.
General info:
MySQL database 5.0.51a
PHP 5.2.9-0.dotdeb.2
Installed Domain modules: Domain Access, Domain Configuration, Domain Content, Domain Navigation, Domain Prefix, Domain Source, Domain Theme, Domain Views
Other modules installed is a list that is way too long
#1
It seems staring at code the entire day has affected my english writing. If the above needs explaining let me know :)
#2
It means that node_save_redirect() doesn't have enough information, or that the main domain is the proper place for that node, based on the logic.
#3
See #227947: After editing nodes user is redirected to the main domain for the background. My guess is that the lack of the $_domain global is the problem.
#4
I actually checked that and it seems to go through the entire function and reach the if statement as well, but doesnt go into the if statement. Which seems logical if i read your comments correctly in the file.
#5
I actually applied the patch described in #623394: No $_domain Global in domain_node_save_redirect as well. But had no succes
#6
The function
domain_node_save_redirectshould be refactored to usedomain_get_node_match($nid). This was a late API improvement that didn't get factored in.Try the attached against 6.x.2.0.
#7
Ok running update.php again and something I noticed this time that it automatically sets the update script to 6203 even though there is also a 6204 available. Running update.php again doesnt give the 6204 as a possible update.
After applying the test i tried creating a node on domain B, but unfortunately still get redirected to domain A on hitting the save button.
#8
What settings are you giving the node?
The update problem is a core issue. Check the 'schema' value in your {system} table.
#9
At first I was sending it to all affiliates but with the source domain set to Domain B.
After this problem started occurring I changed it to just domain B and set the source on Domain B as well.
I checked the schema value in the DB and it does indeed say 6204.
Just as a heads up, im off to bed now and will be online tomorrow again. You can also find me on irc if you prefer.
#10
I totally cannot replicate this.
If it is set to 'all affiliates' it should not redirect, unless its the missing globals problem.
#11
Well I have been thinking we might be looking in the wrong spot. From what I understand from you here and the comments in the module it is only supposed to run:
drupal_goto($source['path'] . drupal_get_path_alias("node/$nid"));
when it should really go to a different domain, for example when you create something on domain A which is for domain B. And this seems to work just fine. So even after trying to comment out that drupal_goto it still results in a drupal_goto call being made somewhere.
Does this make sense what im saying here?
The other thing is that Ive lost count on how many modules im using so there might be others hooking into the node form. One thing i am sure about is that this problem started happening since i updated to domain 2.0 final.
As my project is quite dependent on the domain module Im willing to give you access and maybe together we can figure this one out.
#12
Ok my findings so far:
- the node form calls upon drupal_goto on save which requests url()
- which at first only has the option absolute
- then the global $base_url is called and correctly sets the $options["base_url"] to domain B
- then custom_url_rewrite_outbound() is called which is processed by settings_custom_url.inc
- after this the $options["base_url"] is set to domain A.
Im not sure if this helps you, but maybe you can figure it out now or give me a nudge in the right direction where i should look now.
Start vardump options start -- array(0) {}
second part vardump -- $path = node/nid -- global $base_url = http://domain-B.com -- $options["base_url"] = / array(7) {
["fragment"]=>
string(0) ""
["query"]=>
string(0) ""
["absolute"]=>
bool(false)
["alias"]=>
bool(false)
["prefix"]=>
string(0) ""
["external"]=>
bool(false)
["base_url"]=>
string(25) "http://domain-B.com"
}
Start vardump options start -- array(1) {
["absolute"]=>
bool(true)
}
second part vardump -- $path = node/47 -- global $base_url = http://domain-B.com -- $options["base_url"] = http://domain-A.com/array(7) {
["absolute"]=>
bool(true)
["fragment"]=>
string(0) ""
["query"]=>
string(0) ""
["alias"]=>
bool(false)
["prefix"]=>
string(0) ""
["external"]=>
bool(false)
["base_url"]=>
string(24) "http://domain-A.com"
}
#13
I'm running into this same problem as well. for reference here's the config steps:
0) start with a clean install of drupal with normal base modules. enable domain access, domain configuration and domain theme modules
1) follow the install_quickstart.txt file (add the settings include line)
2) configure primary domain:
domainx.localhost
3) configure additional domain:
sub.domainx.localhost
4) create page from sub.domainx.localhost:
dont check "all affiliates" ensure that "sub.domainx.localhost" is checked and "domainx.localhost" is NOT checked.
5) hit save
you will be redirected to "domainx.localhost" as configured in your primary domain.
given that i just followed the instructions, there shouldnt be anything 'missing' (such as the $domain global). if there is, maybe an addition to the quickstart text is in order?
-Chris
#14
@netwerker Actually the $domain global has not been implemented yet to ensure you really have the same bug apply the patch in http://drupal.org/node/624360#comment-2230398
#15
Ok the final bit Ive been able to trace is the following:
Placing the a bit of code in this function
<?php
if (!$domain_site[$nid] || $use_source) {
// Remove rendundancy from the domain_id check.
if (!isset($domain[$nid])) {
$domain[$nid] = domain_get_node_match($nid);
}
// Can we and do we need to rewrite this path?
if ($domain[$nid] != -1 && $domain[$nid]['domain_id'] != $_domain['domain_id']) {
$options['absolute'] = TRUE;
// In this case, the $base_url cannot have a trailing slash
$options['base_url'] = rtrim($domain[$nid]['path'], '/');
// Domain Source trumps the seo rules below.
if ($use_source) {
$seo = FALSE;
}
$target_domain_id = $domain[$nid]['domain_id'];
ob_start();
var_dump($domain);
//var_dump($_domain);
$data = 'Start vardump -- ' . $nid . ' -- ' . $options['base_url'] . ' -- ';
$data .= ob_get_contents();
ob_get_clean();
$fp = fopen("/home/xxx/public_html/trace.txt", "a");
fwrite($fp, $data);
fclose($fp);
}
}
?>
On hitting the save button this gave the following output (see attachment).
Where for some reason the static $domain returned domain A for the first times it ran through that piece of code.
Hope it helps some more.
#16
@tcrobert
applied the patch. but it didnt fix the problem. I'll do some digging as well to see if i can help narrow this down. could it have anything to do with the the site directory that the settings file is using? one thing i forgot to mention is that this is running under: sites/domainx.localhost/settings.php and note sites/default/settings.php
lemme know!
-Chris
#17
Did anyone test the patch in #6? That is the correct approach. The settings folder shouldn't have anything to do with it.
The real question is: does
domain_get_node_match($nid)from the _patch_ return the right domain value.Note also that if the matching domain is invalid, you will not be redirected. And invalid domains redirect to the default domain unless you have the new 'access inactive domains' permission, which should have been granted when you ran the module update.
See:
if ($source['domain_id'] != -1 && $source['domain_id'] != $_domain['domain_id'] && ($source['valid'] || user_access('access inactive domains')))#18
I do notice that in the var_dump Domain-B returns 'valid' as a string (from the database) rather than a Boolean. I wonder if that is causing the IF check to fail.
#19
I did run the patch, but without success.
agentrickard, if i understand correctly you are saying that the function node_save_redirect() should return the ppl to domain B? because i figured it should only do that under different circumstances.
Ive been wondering about that string as well (being not a boolean).
#20
The first part of your comment in #11 is correct. node_save_redirect() is designed to make sure that, on node save, you don't go to an inaccessible domain. If you save the node on Domain A and it is not viewable there, you are redirected to Domain B.
You have to see the long, painful history of #227947: After editing nodes user is redirected to the main domain to understand why this is here.
#21
@agentrickard
as noted in comment #16, Yes we've both run the patch and that has not solved the problem. are you *sure* that you cant reproduce this using clean copies of drupal and domain module by following the steps we provided? these arent elaborate setups we are using.
#22
@agentrickard
So what you are saying is that it should go into the if() statement -->
if ($source['domain_id'] != -1 && $source['domain_id'] != $_domain['domain_id'] && ($source['valid'] || user_access('access inactive domains'))) {drupal_goto($source['path'] . drupal_get_path_alias("node/$nid"));
}
so that drupal_goto sends the user back to domain B even if it was created on domain B in the first place.
As that doesnt really make sense to me as it should only go into the if statement when source domain and current domain are unequal to each other. Which would only happen when something would be created on say domain A which is for domain B.
#23
That is not what I am saying. If it belongs to B but is created on A, you should be directed to B. If it belongs on A, nothing should happen. See the != in the IF.
I am tempted to rip this out entirely, since it was designed to end confusion and seems to be causing different confusion.
#24
Im sorry, my mistake. The main reason why I wanted to get it clear what is happening is to figure out which drupal_goto is being used. If the one from the function domain_node_save_redirect() is not being used it means it simply runs the the drupal_goto from the node form itself. Meaning that the function domain_node_save_redirect() actually isnt really the problem here. But apparently something that creates the url aka the custom_url bit.
If there is something I can test for you to exclude things or main localize where the true problem lies just give me a nudge in the right direction. Im currently on holiday though so im not sure what time i can sort it out.
#25
And I'm in Stockholm for DrupalCamp Sweden, so this is a bad week for more testing.
#26
I have a sneaking suspicion its got something to do with URL rewrites. If I create a book page and have it save as a normal node (eg node/10) it does not redirect back to the primary domain. If I create a book page, and save it under a book parent which is subject to URL rewrite, it will redirect back to the primary domain.
Im using Drupal 6.20, Domain Access 6.x-2.0 with Domain Config, Domain Nav, Domain Content, Domain Source, and Domain Theme enabled. I also have SSO installed and the latest release candidates of Token and Pathauto. 4 Main Modules overall.
Could it be URL rewrites problem in Domain Access, or something going on with pathauto?.
Im wondering what happens if the Domain Sourcce sub-module is disabled....Ill try that now.
#27
Ok with Domain Source disabled, and if, under the "Advanced Settings" area of the primary domain I have:
- Search Engine Optimization - Rewrite All URLS to point to a single source.
- Default Source Domain - Do not change.
I wont get redirected if I create a book page as a normal node without rewrite, or a book page with a book parent that does rewrite. So basically I can now create any book page, on second domain, and it wont redirect back to the primary domain. So now its working as intended.
I should mention my primary domain is like site1.com and my second domain is like site2.com....2 top level domains. I havent applied the patch mentioned in #6.
#28
@Netbuddy, Interesting info.
As soon as I get back behind one of my working pc's ill have a look and try that out as well. Im curious to see what the end result would be.
#29
I tried the same settings and disabled Domain Source like suggested in #27. Unfortunately not with the same result.
After that ive been trying some other things as well. And have come to the conclusion that for some reason when I create a stadard "page" node it stays on the correct domain. But with the content types Ive created on node creation / save I get redirected back to the main domain. Im now trying to figure out if there is something specific that is different between the content types which is maybe causing it.
#30
As Im using quite some cck fields for my content types it was a bit of a search, but finally figured out what was doing it. It appears as soon as that I enable the cck field for an image upload via FileField it has the effect of redirecting me to the main domain on first time node safe. As im using quite a few modules to change the behavior of ImageField I was wondering if somebody could test this with a clean install. To see if with merely the basic cck FileField it already has this behavior.
#31
It may be that the redirect is too aggressive. Right now, it takes all saved content to the perferred link domain.
It may be better to ensure that it goes to a domain where the node is visible.
Prior to 6.x.2.0, people had the problem where saving a node automatically redirected them to the primary domain. This is due to an unchangeable redirect hardcoded in the node module.
#32
So if I understand you correctly it thinks it needs to be showing the file on a different domain (the too aggressive part). After which it thinks its on another domain and moves to show the node on the wrong domain as well.
All in all is it something you would be able to figure out a fix for?
#33
The proper fix is probably to ensure that a user is redirected back to the domain from which the edits were made, which did not always happen prior to 6.x.2.0.
However, in that case, it is possible that the content is not viewable on that domain, which triggers an access denied. Which is what we are trying to avoid.
#34
Just as a reminder, but editing a node works fine (which makes the thing so strange). Its merely on creation and then actually saving the node that it redirects to the main domain.
Is there anything else I can do to find a solution for this?
#35
No. We have a difference of opinion as to what the behavior should be. If the node is assigned to the main domain, then this behavior is acceptable and BY DESIGN.
If it is not, then its a bug and I'm going to revert the damn patch.
#36
Here's a better patch that does the following.
PLEASE READ THIS CAREFULLY, as this is the intended behavior.
1) On node save or update, store two session values, the NID and the current DOMAIN_ID.
2) If these values are present, check to be sure that the form returned the user to the proper domain, which is defined as:
2a) If the node is sent to 'all affiliates', the domain from which the form was submitted (the DOMAIN_ID).
2b) Otherwise, the proper 'source' domain of the node, which is defined as the canonical domain for this content. If not using Domain Source, this domain is the _first_ matching domain that a node is assigned to.
Now, the only possible bugs are:
A) You are redirected to a domain where the node is not visible.
B) The rule in 2b is not correct, and should instead be "Issue a redirect only if the node is not visible on this domain."
#37
Sorry for the late response. Its been hectic the last few days.
Im sorry to be the bringer of bad news, but unfortunately the problem remains. Content types with CCK FileFields still redirect me back to main domain. Content types without CCK FileFields work as intended.
Updating the node works as intended so its still only on first time node save.
#38
The FileField is interfering. Look at the logic. We're issuing a redirect _after_ the form has completed its process, based on a $_SESSION value.
If the redirect is going to primary domain it is because the node belongs there.
#39
But then the question should be why is FileField interfering now, since DA 2.0?
Right?
#40
I don't think it is. I don't think you are understanding the designed behavior.
#41
Im sorry agentrickard, my php knowledge and general logic in how it works is pretty good, but not as good as I would hope. Like you say I probably do not fully understand the designed behavior. The only thing I can say is that I really would like to get it to work properly and if there is anything I can do let me know.
Thanks again for delivering such a great module and investing all this time into it.
#42
It's ok. This is a nasty problem. My shortness is due to the fact that you don't seem to be testing the patches or responding to the questions.
Please re-read #36, test that patch, and argue about the business logic. We just had a separate request that said: "On editing, always return to the domain that the form was entered on."
If that is the behavior people want, we can make it happen.