Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I issued a Path Redirect feature request so that it could be used in conjunction with Domain Access. Second thought: if the requirement is not general in nature, but applies only to DA users... would it be better to handle it with a DA module? Administration would be much easier, as redirections would be partitioned on a per-domain basis. Also, are there ways of using the current Path Redirect implementation as a sort of plug-in (so that Path Redirect updates could be easily picked up by the hypothetical Domain Redirect module)?
Comments
Comment #1
agentrickardI need more context. I do not know what Path Redirect is or does.
Comment #2
skizzo commentedIt just allows you to define redirections to predefined Drupal Path or external URL. Please see
attachment. In my context I wanted to allow user registration only on specific domains, redirecting
others to explanatory page. Problem is that the module works on Drupal path, so it
would apply to all domains. If the feature request makes sense, I would like to figure
out whether it should go toward "Path Redirect" or "Domain Access"
Comment #3
agentrickardThis is a case where, I think, the module stores its data in its own table, right? Or does it store them in the variables table?
If it has a table of its own, just use Domain Prefix to create separate tables for the domains where you want these paths to be active. leave the others empty.
Remember that if using Domain Prefix in this manner, the domain from which you enter this form will be the domain for which the settings are saved.
If you have a "master" domain, you could enter all the paths there, and then use that as the "source" table for the others.
Comment #4
agentrickardI looked at the Path Redirect code. You should be able to use Domain Prefix to solve your problem.
However, since Path Redirect uses hook_init() to perform its redirect, it is possible that you might run into some conflicts. For example, if you have a redirect on a path 'sample/path' active for the domain 'one.example.com' and someone requests an invalid domain, the DA module will try to send you to 'example.cm/sample/path' and then PR may try to act.
This should not be an issue. Just note that -- under Drupal's operating process -- DA will act before PR.
I would try the module with the table prefixing from Domain Prefix, but note any odd behavior.
Comment #5
skizzo commentedAs suggested, I enabled Domain Prefix for Path Redirect table and it works nicely. Thank you. In general I try to avoid Domain Prefix because I feel uneasy about future changes: maybe now Module X does not use the variables table, but a future realease will, and then I may see odd behaviours. Trying to use Domain Access for multidomain, one must always think about users "making up" their own URLs (click through a site, then manually replace the domain part in URL to see what happens...). Path Redirect could be very useful here. In those circumstances wildcards handling by PR would help: for example one could configure PR so that [for example.com] all Drupal paths matching "forums/*" will lead to error page.
Comment #6
agentrickardRight.
The variables table issue -- which you and I have discussed -- is a tricky one. Since there are so many Drupal modules out there, we have to take it on a case-by-case basis. Ideally, someone would document the findings on a module-by-module basis.
So there would be lists of modules that "just work" with Domain Prefix. Like this one.