Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chriscalip’s picture

Hello I am just tagging in some integration issues with globalredirect and domain access; I could use your advice what would be a good next step do i put this on an issue queue of globalredirect or domain access; Of course this can be fixed in a custom module..

On a multidomain setup of
s7.dev
children.dev

On node/2 with s7.dev as it's domain source and its only assigned domain; viewing:

http://children.dev/node/2 gets rightly redirect to http://s7.dev/node/2
But viewing it on node 2's alias of (node-2-alias) :
http://children.dev/node-2-alias does not get redirect to http://s7.dev/node/2

agentrickard’s picture

Project: Domain » Global Redirect
Version: 7.x-3.x-dev » 7.x-1.x-dev

Global redirect. We've had longstanding issues with that module being overly aggressive.

carsonblack’s picture

Sorry agentrickard, which module are you saying is overly agressive?

agentrickard’s picture

Global Redirect. DA never issues these types of redirects.

dgtlmoon’s picture

So, the real issue here is that Drupal is not domain aware when it comes handling aliases, there is simply no way of Drupal to know which domain an alias belongs to, if you have multiple aliases for the same address then it will just use which ever drupal_get_path_alias(...) says it should, which is usually the most recent alias added

so in globalredirect.module, it goes to check the alias against the current URL to know if it needs to redirect..

Line 173: $alias = drupal_get_path_alias($request, $langcode);

However drupal_get_path_alias() is not domain aware either, there has been some inroads made by the domain_path module, but this is so far only working for node/%, not for other entity_types.

To complete this functionality, something somewhere needs to keep a record of which aliases are applicable to which domains, domain_path hooks a lot of CRUD hooks for aliases to record which domain it occured against, but even that is still not perfect, OTOH globalredirect MAY have to implement the same CRUD type tracking and/or integrate with the domain_path module somehow.. tricky eh?

agentrickard’s picture

Does using url() buy you anything here? I would think that calling url() on the path instead of manually looking up the alias might solve the issue, since Domain Access uses hook_url_rewrite_outbound().

Of course, drupal_goto() implements url(), so perhaps the problem is trying to double-check the path? Shouldn't drupal_goto() find the alias for you?

dgtlmoon’s picture

@agentrickard nah, because it's still not possible to know what alias and path is for which domain, theres simply no record of it

Until something works out, we're turning off globalredirect in this situation with the following patch, hope it helps someone out there!

agentrickard’s picture

That sounds like a domain_path issue, not a core domain module issue. I don't understand how you would be getting multiple records in {url_alias}, though.

dgtlmoon’s picture

domain is not core, and you can reproduce this issue without domain_path, try it, you can insert as many aliases into url_alias as you like too

agentrickard’s picture

"core domain" == the Domain Access main module.

How are you inserting urls? The normal node edit form only allows for one per node. Domain Access module does not affect that, neither does Domain Path, which has its own storage.

agentrickard’s picture

Let me be more clear:

Unless you are using Domain Path, the Domain module makes no attempt to map a URL alias to a specific domain. That should be a non-issue here.

The issue from the OP is that the canonical URL set by Domain Source module (and enforced in hook_url_rewrite_outbound()), doesn't seem to work for Global Redirect because the alias isn't being read properly.

pwiniacki’s picture

chriscalip’s picture

In response to #11

"The issue from the OP is that the canonical URL set by Domain Source module (and enforced in hook_url_rewrite_outbound()), doesn't seem to work for Global Redirect because the alias isn't being read properly."

What is happening is global redirect through globalredirect_init() is calling drupal_alter('url_outbound', $request_path, $options, $request_path);
At the same time domain access does an alter through domain_url_outbound_alter(&$path, &$options, $original_path) and changes the base_url.

So you have situations where globalredirect is doing its job of changing the url to the path alias; and unfortunately changing the url's base path.

My propose solution would be for globalredirect to stop using drupal_alter('url_outbound', $request_path, $options, $request_path); and use another drupal api. I am sorry I don't currently have a concrete solution as to what to replace drupal_alter('url_outbound'..)

chriscalip’s picture

This patch should resolve the conflict between globalredirect and domain access. This is most performant solution I can see .. The patch does a check if and only if function domain_url_outbound_alter exist then unset the base_url key in the options array.. as domain_url_outbound_alter is the most likely function that is providing the key; and because global redirect scope is only the url alias and not the base_url .. this patch should fit in well..

chriscalip’s picture

Status: Active » Needs review
chriscalip’s picture

Status: Needs review » Active

patch needs more work.

chriscalip’s picture

This patch should resolve the conflict between globalredirect and domain access.
This is the most performant solution I can see ..
The patch does a check if and only if function domain_url_outbound_alter exist then unset the base_url key in the options array.. as domain_url_outbound_alter is the most likely function that is providing the key;
and because global redirect scope is only the url alias and not the base_url .. this patch should fit in well..

chriscalip’s picture

Status: Active » Needs review
Chris Matthews’s picture

The 3 year old patch in #17 to globalredirect.module applied cleanly to the latest 7.x-1.x-dev, but still needs community review & testing.

dunx’s picture

The patch doesn't resolve the (possibly related) issue with domain_path mentioned here
https://www.drupal.org/project/domain_path/issues/1325088