Menu set with node/id# that link to a different subdomain does not use the node's domain path.

Yes, I am using the default block created by the menu module.

I took a stab at trying to figure this out but I am not 100% sure if my solution affects anything else. It seems that when domain_path_lookup_path gets called the current domain id is the one passed to it, which forces the function to query the DB for paths only on that domain.

What I tried to do is to pass the source domain for the node, so that the function looks for paths on the node's source domain instead of the current one. What do you think?

Ok, so I played with this a bit more and I came up with this:

// If looking for an Entity with multiple domains, make sure to look for the path on the source domain.
if (isset($options['entity']) && isset($options['entity']->domain_source)) {
	$domain_id = $options['entity']->domain_source;
}

The idea is that if we are dealing with an entity that makes use of domain access than the domain source is required, so if both are set we use the entity's source domain to look for the domain specific path. It is possible that the domain source is "Use active domain" (id -5?), but domain_path_lookup_path already defaults the domain_id to the current domain if a 'bad id' is given.

Does this seem like a more reliable fix?

Ah, I see!

Well, after spending some more time with the code it turns our that the problem was simpler than I originally thought.

It seems that this was the culprit:

<?php
// Let's not muck with absolute paths.
if (!empty($options['absolute'])) {
    return;
}
?>

Paths that point to a different domain have the absolute flag and therefore do not go through the domain_path_lookup_path() function.

By adding a base_url catch, which seems to be added to the options array by Domain Access, internal Drupal urls are forced to go through the lookup and their aliases are found correctly.

So in the end, this was the only change needed to make it work for me:

<?php
// Let's not muck with absolute paths.
if (!empty($options['absolute']) && !isset($options['base_url'])) {
    return;
}
?>

Is this a more correct path? ;)

Sorry I've been a little busy this last week.

I am fairly new to Drupal so please stop me when I start speaking nonsense.

As far as I understand, the base_url is used to rewrite the URL in case we need a language specific URL. Isn't that the base part of the URL displayed before the node alias? It seems that we are not changing the base_url in any way, we are only saying that if the base_url key is set in the array then we should look up the alias for that node, since we know that it is an internal URL.

If that is the case, would that cause any conflicts? Or am I misunderstanding the way this works?

OK.

I have another question and I am not sure if this is a Domain Path or Domain Access thing.

Going back to the example in the beginning of this thread, I noticed that if I am in domain1.mysite.com menu links that point to nodes published to a different sub domain will not be displayed in the menu at all (Unless I am logged in as admin which will bypass permission checking).

The question is, is that by design or is that a bug? I am more than willing to open another issue and explain my use case and the problems I am running into, but I figured I would check if that was working as intended and if that is a Domain Access or a Domain Path issue (I am guessing Domain Access).

Right, and that is what we have been doing with our links so far. But we are in the process of moving a very large static site into Drupal and our URLs are changing, so every time we update a URL we have to go through all the menus and update the links that have the complete URL.

Our hope was that by entering the internal node/id path, the menu item would be linked to that particular node and not its URL, so if the URL eventually changed, all the menus would then be updated to point to the most accurate URL.

Any ideas on how we can go about achieving something like that?