First time node save gets redirected to main domain

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.

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.

The function domain_node_save_redirect should be refactored to use domain_get_node_match($nid). This was a late API improvement that didn't get factored in.

Try the attached against 6.x.2.0.

What settings are you giving the node?

The update problem is a core issue. Check the 'schema' value in your {system} table.

I totally cannot replicate this.

If it is set to 'all affiliates' it should not redirect, unless its the missing globals problem.

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

@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

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')))

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.

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.

@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.

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.

And I'm in Stockholm for DrupalCamp Sweden, so this is a bad week for more testing.

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.

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.

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.

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.

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.

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."

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.

I don't think it is. I don't think you are understanding the designed behavior.

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.

Edit / Create node submission would be best to return to the current domain when "administer nodes"and "Enforce rules on administrators" is set to "do not enforce". These settings suggest to the system that the user is an administrator of all domains and does not need to be redirected to the domain the content is assigned to.

That logic seems too complex to me, given the problem that we are trying to solve.

The original issue is that, in some cases, users are returned to the primary domain after editing. I really don't want to introduce another setting, just a logical default to prevent that from happening.

So I think the two options are:

a) Return the user to the domain the form was sent from.

b) Return the user to the canonical source domain of the node.

Having a setting for those two behaviors seems like overkill to me.

You are probably right. Is there a patch in this thread than can achieve (a) Return the user to the domain the form was sent from?

I tried the path from #36, but it appeared to have no effect. If this patch does work, can you confirm and I will have another go.

The patch in #36 does b), not a).

Here's a patch for logic a).

Hi agentrickard,

I applied this patch and it seems to work sometimes, but not others. I can't figure out when it is.

I have two domains checked to publish to. One of which is the one the form is on. Sometimes when I submit, I stay on the domain I'm on (which is what I want to achieve), but on other occasions, I get taken to the other domain. Without changing any settings, this is just between clicking edit and submitting the form.

One other thing to add is that, if I try to edit from a view following the edit link with &destination=xxxxx in it, this is overruled and the node view page is used.

I am now even more tempted to simply remove this behavior entirely, and let Drupal do what it wants.

I guess I have similar issue with TCRobbert, The redirection to main domain happens only once at the time of creation.
Let me explain what I've found in terms of sequence of function calls after you fill out the node creation form and click save button.

I tried every patches above and have same sequence below.

1. domain_init()
2. domain_node_save_redirect()
===============================> bootstrap done!
3. domain_nodeapi()
4. drupal_process_form()
5. drupal_redirect_form()
===============================> redirect to main domain and got access denied page.

As you can see, I think domain_nodeapi() should get called early than domain_node_save_redirect() so this is why all above patches are not working for me in my opinion. Any idea?

You want to check the execution of domain_nodeapi() with $op of 'insert' and 'update' only. It should have no effect on other operations.

But it sounds like domain_init() is being called during the form processing stage.

Try this in domain_init():

  if (empty($_POST)) {
    // If coming from a node save, make sure we are on an accessible domain.
    domain_node_save_redirect();
  }

Thanks for quick response in advance.

I've checked domain_nodeapi() with $op of 'insert' and 'update' with your code snippet above, and saw $_SESSION['domain_save_id'] got updated properly but it seemed
it never been used until I got redirected through the last function call of drupal_redirect_form().
Thanks again.

Just a quick update to this post #48. I discovered that the destination in the url does actually work with domain module. I had been using &destination?xxx rather than ?destination=xxx so apologies, that was my bad.

@djmystic82 cool. Where does that leave us?

@TCRobbert -- If you just provide a simple explanation of the behavior you want, that would be helpful. I am assuming you want b) "Return user to the domain the form was entered from".

@agentrickard I traced my case more, further steps are below.

1. domain_init()
2. domain_node_save_redirect()
===============================> bootstrap done!
3. domain_nodeapi()
4. drupal_process_form()
5. drupal_redirect_form()
6. form_execute_handlers()
7. node_save()
8. domain_get_node_match()
9. drupal_alter()
10. domain_source_domain_source_alter()
11. domain_source_lookup()
12. domain_get_node_domains() =======> $domain_id got FALSE value
13. domain_lookup =================> fail to look up current domain here
===============================> redirect to main domain and got access denied page.

Could you please check these sequence and tell me why step 12, 13 got fail to lookup current domain so later I got redirected to main domain? Obviously, domain_access table didn't updated with a new node at the time of step 12, 13.
Any idea or suggestions would be much appreciated...

@agentrickard : I opted for an alternative method for administration rather than using a domain name just for that task as we were on a tight deadline to provide our site to the client.

As for the problem, the patch appeared to work for editing as long as the administration domain was the primary domain, so I would consider that the correct behaviour. I couldn't get it to work for creating a node though.

I think an overview would be that that the domain module works well for multiple sites with content managed from each site individually. It becomes a problem when the intention is to manage all content for multiple sites from one admin interface as you get redirected and logged out depending on where you assign the content to.

@djmystic82 That is only a problem if your domains don't share a top-level cookie (e.g. .example.com) or you don't use the SSO module to configure multiple logins (see 1.4.1 of README.txt). It also suggests that for form behavior should be "return to the domain where the form was submitted."

@guysung

My confusion in your chart is "where in this sequence do you submit the form?"

@agentrickard My chart is all about sequence of major function calls with debugger after I submit the form to create a node.

In domain_source_lookup() , $domain_id got FALSE value, because domain_get_node_domains() returned FALSE of $domain_site and null of $domains.
Thanks much.

Coming to this discussion way too late but I think the behavior should be "return to the domain where the form was submitted". Just my 2 cents.

@nonsie

Let's make that work, then. The patch to test is #47.

@agentrickard

I've solved my case through long tracking with debugger. It is very interesting.

I set trigger/action to send a email for newly posted content. when I turned off trigger/action email for newly posted content, the redirection issue was solved.

The issue is that trigger_nodeapi() invoke domain_url_outbound_alter() before the domain_access table updated by domain_node_access_record().
( As you know, node_invoke_nodeapi() is followed by node_access_acquire_grants() in node_save() )

For detail sequences, trigger_nodeapi() call system_mail() and domain_url_outbound_alter() in turn, this cause wrong cached $domain variable in domain_get_node_match() because it is too early to look at the domain_access table which didn't updated yet.

You may want to try to create a new node after setting action of "send a email to moderation team" for "Trigger: After saving a new post" .
You can experience the redirection to main domain.

Could it be bug? Any Idea?

@djmystic82 , TCRobbert : Did you set "send a email" actions for "After saving a new post" trigger ?

@guysung

Wow. Thanks. But I don't see where trigger_nodeapi() would call l() or url() to invoke domain_url_outbound_alter().

This may be an unsolvable problem, due to how the form redirects are handled by core. I thought the session handler would do the trick.

@agentrickard

Invoking domain_url_outbound_alter() in trigger_nodeapi() only happens when you set "send a email to..." action to "After saving a new post" trigger.

system_mail() invoke url() and domain_url_outbound_alter() in turn.

Detail sequence are below for your information.

1. node_save() ---------------> node.module(929)
2. node_invoke_nodeapi() ---------------> node.module(673)
3. trigger_nodeapi() ---------------> trigger.module(243)
4. actions_do() ---------------> actions.inc(100)
5. system_send_email_action() ---------------> system.module(1745)
6. drupal_mail() ---------------> mail.inc(119)
7. system_mail() ---------------> system.module(1781)
8. url() ---------------> common.inc(1480)
9. custom_url_rewrite_outbound() ---------------> settings.custom.url.inc(18)
10. domain_url_outbound_alter() ---------------> settings.custom.url.inc(108)
11. domain_get_node_match() ----------------> domain.module(1167)

Is there any way to skip invoking domain_url_outbound_alter() by trigger_nodeapi()? so that, I can use trigger/actions with solving the redirection issue.
Any code snippet or Idea?

Thanks.

No. We're getting bitten by the static variable in domain_url_outbound_alter() here. But the patch in #47 ought to correct that, since the URL that function uses doesn't care about domain_url_outbound_alter() -- unless it is getting invoked by drupal_goto(), which would make sense. Ugh.

The solution seems to be to ensure that domain_node_save_redirect() fires in the proper sequence, which probably means watching the form process functions more closely and putting in a delay if the form is still being processed.

I cannot replicate the behavior in #65 when using the patch from #47.

Looks good to me!

#47 has been committed to HEAD and 6.x.

@agentrickard,

It's been a while but here is what I found from the testing.
I couldn't replicate the redirection issue with having the #47 patch and "Trigger: When either saving a new post or updating an existing post" trigger set just like you, but I am still having the redirection issue with having the #47 patch and "Trigger: After saving a new post" trigger set.

It seems the module works differently depending on which trigger we are using.

In #67, Were you using exact "Trigger: When either saving a new post or updating an existing post" trigger set? If so, "Trigger: After saving a new post" trigger set would be the one you may need to test it.

Appreciate for all your work.

Using "Trigger: After saving a new post" --> Send Email (from Drupal core actions).

Have you tested 6.x.2.1?

Yes, I have tested it and using 6.x.2.1 with the issue now. Thanks.

"With the issue now" means that you are still having a problem? I would look to see if another module is issuing a redirect.

Yes, I am still having the issue. I've been tracking both "Trigger: When either saving a new post or updating an existing post" and
"Trigger: After saving a new post" cases.

I tried to describe the source tracking as best as I can
and hope it will help you understand what I've tracked down. Feel free to ask if you need more detail information.

a. Only set <strong>Trigger: When either saving a new post or updating an existing post</strong> to Send email action: (hook_nodeapi with presave op)
  ----1. node_form_submit()
   ------a. node_save()
   -------------1. node_invoke_nodeapi($node, 'presave');
   ------------------------a. trigger_nodeapi()
   ------------------------b. system_mail()
   ------------------------c. url()
   ------------------------d. domain_url_outbound_alter()
   ------------------------e. skip the codes of if (!empty($nid) ) { ......... } because of no match nid yet.

   -------------2. node_invoke_nodeapi($node, 'insert') 
   ------------------------a. trigger_nodeapi got skipped because there is no action id for hook_nodeapi for insert op

======> No problem!

b. Only set <strong>Trigger: After saving a new post</strong> to Send email action:  (hook_nodeapi with insert op)
   ----1. node_form_submit()  
   ------a. node_save()
   -------------1.  node_invoke_nodeapi($node, 'presave');
   ------------------------a. trigger_nodeapi() got skipped because there is  no action id for hook_nodeapi for presave op
   -------------2. node_invoke_nodeapi($node, 'insert') 
   ------------------------a. trigger_nodeapi()
   ------------------------b. system_mail()
   ------------------------c. url()
   ------------------------d. domain_url_outbound_alter()
   ------------------------e. domain_get_node_match
   ----------------------------static $domain value get wrong main domain information because there is no node entry in node_access table.
   -------------3. node_access_acquire_grant() 
   ------------------------a. domain_node_grants() --> node_access table get updated for a new content at this subroutine.

======> Having the redirection to main domain issue.
As you can see in step b.1.a.2.e,
node_access table doesn't have a entry for the new content at the time of calling domain_get_node_match(), afterward
node_access table is updated by domain_node_grants() call in step b.1.a.3.a
I think there are chances that domain_get_node_match() would be called early before node_access table updated by domain_node_grants().

I still don't see how that would affect the redirect. None of that code is relevant to the redirect in 6.x.2.1. The logic is simply:

function domain_nodeapi() {
 // ...
    case 'insert':
    case 'update':
      global $_domain;
      $_SESSION['domain_save_id'] = $_domain['domain_id'];
      break;
}

function domain_node_save_redirect() {
  global $_domain;
  // If no session token, nothing to do.
  if (!isset($_SESSION['domain_save_id'])) {
    return;
  }
  $domain_id = $_SESSION['domain_save_id'];
  // Unset the token now so as not to repeat this step.
  unset($_SESSION['domain_save_id']);
  $source = domain_lookup($domain_id);
  if ($source['domain_id'] != -1 && $source['domain_id'] != $_domain['domain_id'] && ($source['valid'] || user_access('access inactive domains'))) {
    domain_goto($source);
  }
}

So what's in the $_SESSION during your routine?

@agentrickard,

I think $_SESSION['domain_save_id'] have a right value of 3 for the current domain where a node is created.

Let me simplify the flow of function calls add more info. below for the better understanding in the issue.

1. drupal_process_form()
     a. node_form_submit()
                  ..... refer to #75 for details
                  ..... get wrong static $domain value of main domain information by calling domain_get_node_match() 
                        from the step of b.1.a.2.e  in #75.
		
     b.drupal_redirect_form()
                  1. drupal_goto()
                        a. url()
                                  domain_url_outbound_alter()
                                  ... returns main domain absolute url which is wrong
                        b. header();
                                  ....get redirected to main domain with "access denied" error message 
                                      because of the wrong return value of the right above url() call.

In sum, when I get the redirection issue, domain_node_save_redirect() has never been used.
Thanks.

Then some other module is interfering with your $_SESSION, because if that value is present, the redirect should happen on the next non-cached page load.

Could you give me some idea where $_SESSION is used for the next non-cached page load? So that I can trace it down.

It's in domain_node_save_redirect(), triggered by domain_init().

http://api.therickards.com/api/function/domain_node_save_redirect/domain

This might be a caching issue, and that may need to be triggered by domain_boot().

I can't believe why it's taken so long to figure this out, it was really long way around.
Actually, I have set $cookie_domain dynamically per domain basis for some other features.
Different $cookie_domain among domains has been blocking use of domain_node_save_redirect().
Not sharing cookies among domains could make domain_node_save_redire() useless. Documenting or notes may be required.
@agentrickard, I am really thankful for helping me track down this issue and creating/supporting nice module.

Handling the multiple login issue is outside the project scope. The behavior works as designed. Setting back to fixed.

But it makes sense, if $cookie_domain is different, so are the $_SESSION values, I believe.

AFAIK, this only occurs when domain 1 and domain 2 do not share a $_SESSION cookie.

There is nothing I can do, given that the $_SESSION doesn't persist across different domains.

Since $_SESSION['domain_save_id'] is not set, domain_node_save_redirect() should not fire.

If it _is_ firing, you need to tell me what values it uses.

Otherwise, you should look at what filefield is doing that causes the redirect, and fix it there.

You should probably open a new issue. The big thing to note is this: Are you running subdomains that share login and session cookies or not?

In other cases, the sites were not sharing session cookies, which means I can't really do anything about this problem.

Sorry for re-opening this ticket. I wasn't sure if I would open a new ticket or not because my issue falls very close to what was initially mentioned in this ticket. However, amongst 89 replies it seems that the same issue was being reproduced various different ways. But in my case just one simple step when a new node created only for one subdomain, from that subdomain is causing a redirecting to the primary domain. Please see my comments below:

I have domain1 (primary domain) and domain2. I switched to domain 2 and created a page node only for Domain 2 making Domain 2 the source. When I create it without providing any menu settings the node gets created fine and the page view is redirected to domain 2. However, when I create this node and provide a menu item for the node, I get redirected to primary domain.

I have tried the patches but its not working. Any help or suggestion would be highly appreciated. Thanks!

This is not a solvable issue.

It looks like the behavior should be "return user to the domain they created the node from" and that code has been committed but I am using 6.x-2.5 and having a similar issue to the OP.

I do not have Imagefields or Filefields on my content type but it is a custom content type. I am not creating menu items. They are just straightforward nodes. All subdomains are the same as the parent domain, so there shouldn't be any session issues, I would think.

When someone adds a node from atlanta.domain.com or newyork.domain.com they are redirected to the submitted node on domain.com where they are given an access error (unless they have edit/access rights to domain.com.) Simple node assigned to a single subdomain, using the add page on the subdomain that the node is assigned to appear on.

Editing nodes returns them to the correct place, it's just the initial save that causes this redirect. Sorry if I should create a new issue... but the behavior seems to be what is described in this issue and maybe there's a clue here I'm just not getting.

If this is truly something that can't be fixed at the module level, can you tell me if it can be hacked modified for a specific installation? It's causing lots of confusion as people think the error they get means their node wasn't added and readd... and add another... then again...

It seems that the basic operation of the module ought to allow people to add a node on a subdomain and stay on that subdomain.

Thanks!

subscribing

I just had a conversation on irc with TCRobbert and we figured out that the domain source module has to be enabled. So for anyone still having this issue check if that is enabled.

Sorry, but this is a perfectly fixable issue, and I provide the file patch attached.

There is a mistake in domain_get_node_match() function implementation that caches FALSE results (bad programming practice! invalid results should never be saved in anyway and of course not in a cache variable!).

This makes the static $domains array() cache variable contains a '' => array(), because it calls domain_lookup() with FALSE param, which is of course a nonsense.

This results to the fact that then the static $domain cache variable to have the default domain as value, because even though FALSE was passed to domain_lookup(), as you can guess from the fact that '' => array() is added to $domains static cache variable, domain_lookup does pass FALSE to the query as domain_id and drupal convert FALSE to 0, which is the default domain domain_id, and so domain_lookup does return default domain data even though FALSE was passed.

The fix is:

function domain_get_node_match($nid) {
  static $domain = array();
  if (isset($domain[$nid])) {
    return $domain[$nid];
  }
  // Load the domain data for this node -- but only take the first match.
  $id = db_result(db_query_range("SELECT gid FROM {domain_access} WHERE nid = %d AND realm = '%s' ORDER BY gid", $nid, 'domain_id', 0, 1));

  // Fix bug when result return false that returned default domain and cached the result.
  // In this case, nothing should be return and of course nothing should be cached, as this mean there is no valid result.
  // Default Drupal and Domain behavior should apply (use current domain)
  $source = NULL;
  if ($id !== FALSE) {
    $source = domain_lookup($id);
    drupal_alter('domain_source', $source, $nid);
    $domain[$nid] = $source;
  }
  return $source;
}

Which means nothing should be return (so NULL) from domain_get_node_match() when the db_result() return FALSE, as it means that there is no valid value found, and so default drupal and domain behavior should be used.

What cause the domain_get_node_match() to have db_result() returning FALSE is when a module call url() (via l() or directly) in its hook_nodeapi() implementation and when it's called before the hook_nodeapi() implementation of Domain module.

This for example occurs when you have both Workflow and Domain installed, Workflow hook_nodeapi() with op "insert" is called before the domain's one, and in its implementation, there is a watchdog() call that contains a l() call (that calls url(), that calls custom_url_outbound() that calls domain_url_outbound_alter(), that calls domain_get_node_match() but as this is before any domain info is saved for the node, the db_result() of domain_get_node_match() returns FALSE.

Please find the patch file attached.

This makes sense to me. I'd love to see some other testers.

The other module call to url() or l() has been the problem all along.

I don't quite agree about caching FALSE. Why waste cycles on a known failure? Though in this case, the return of an empty/invalid array does appear to be the bug.

Nice work!

@bpresles what's the reliable way to replicate this error? Just install default Workflow module?

One of the biggest problems in fixing this one has been reliably replicating the error.

@agentrickard
Yes, if you install the workflow module and enable it (of course), next time you create a content on another domain than the default one and save it, you'll be redirected to the default one.

In fact any invocation of domain_url_rewrite_outbound() before the domain data are saved for the node, will trigger the error. This is invoked for example anytime url() is called, so as long as a module calls url() with a 'node/' path (directly or via l() or any other function invoking url()) before the domain data are saved for a node, this will trigger the error.

It just happens that Workflow modules does call l() with a node/ path, before domain data are saved. But it may happens with other modules too, so you can't really predict that, so it's important that domain_node_match() don't cache invalid result (db_result() returning false) in that case. This is exactly what my patch does.

The line triggering the issue on workflow.module is line 570 (workflow module version 6.x-1.4), inside workflow_execute_transition():
watchdog('workflow', 'State of @type %node_title set to %state_name', array('@type' => $type, '%node_title' => $node->title, '%state_name' => $state_name), WATCHDOG_NOTICE, l('view', 'node/' . $node->nid));

workflow_execute_transition() is called by workflow_transition() that is called in 'insert' and 'update' operation of workflow_nodeapi() (line 251);

As you can see, it calls

- l('view', 'node/' . $node->nid)
- which calls url()
- which calls customl_url_rewrite_outbound() implementations on all modules
- And so domain_url_rewrite_outbound() is called
- Which calls domain_url_outbound_alter()
- Which calls domain_get_node_match()

And as workflow_nodeapi() is invoked before domain data being saved, the db_result() of the query done by domain_get_node_match() returns FALSE.

My patch only avoids that anything is done (domain_lookup(), caching result...) when the db_result() of domain_get_node_match() returns FALSE, as it's obvious that in that case, the result is invalid and should not be processed in any way.

Thanks. This is the most awesome bug fix EVER.

This one drove me crazy for a long time, because it was never reliably pinned down. It's a combination of modules doing something odd (calling l() during node save?) and bad code on my part.

Once I test and confirm, I will commit.

bpresles++++

I havent had this problem in a while, but glad to see someone seems to have gotten a handle on it.

For the record, it took me 20 minutes to replicate this error. I finally forced it to happen by setting the weight of workflow module < 0.

Here's the D6 patch that went in.

HEAD patch.

HEAD applies to 7.x.2 with mild offset.

Just a +1, this saved me! Definitely wainting for a stable release with it...