Following the ideas gathered in #276303: Domain bootstrap patch here's the Domain Alias module.

To install just unzip the attached folder into your modules or modules/domain folder and install as you would every other module.
In order for the module to work the domain_bootstrap patch needs to installed.

Developed with Domain HEAD (17/07/2008).

Files: 
CommentFileSizeAuthor
#12 domain_alias.zip6.34 KBbforchhammer
#2 domain_alias.zip5.93 KBbforchhammer

Comments

agentrickard’s picture

Hm. No attachment.

bforchhammer’s picture

StatusFileSize
new5.93 KB

Hm. Here we go...

agentrickard’s picture

Version:6.x-1.0-rc4» 6.x-1.0-rc5
Status:Needs review» Needs work

I really want to get this some thorough review, and now that rc5 is out, I may be able to.

Patch may need testing against HEAD.

flexvixon’s picture

Call me crazy, but I think this solves the issue I had here - though clearly the post the OP linked to is a much better description...

http://drupal.org/node/287854

Is this a 6 only initiative?

agentrickard’s picture

This will -- if approved -- be backported to a 5.x.2 release. It is easier to test on one branch.

bforchhammer’s picture

Status:Needs work» Needs review

Patch may need testing against HEAD.

No changes needed, the module (file #2) seems to still work fine with the latest HEAD version...

agentrickard’s picture

Priority:Normal» Critical

Note: This just became critical, because it solves the dev -> staging -> live problem for the company I work for. For instance:

If you test the site at my.testexample.com but the live site is example.com, you have to change DA settings when moving the database from staging the live. Subdomain Aliases eliminates this issue by allowing you to register both names to the same domain id.

See http://sachachua.com/wp/2008/07/28/kaizen-what-would-make-our-drupal-liv... for an example of the problem this fixes.

Switching between hosts: Because we use Domain Access, I can't just use a local domain name and a copy of the server's database. My current approach is to use the same domain name as on the testing server, and then keep editing /etc/hosts to switch back and forth. An alternative might be to create a Makefile target that grabs the server's database, runs it through sed to translate all the domain names to my local domain, and restores the database from this translated file. That way, I don't need to edit /etc/hosts all the time.

agentrickard’s picture

Ok. Wow. I just tested this for the first time.

The domain wildcarding feature is really awesome.

agentrickard’s picture

Status:Needs review» Needs work

I think we will need a setting - per domain - that controls whether requests to the alias should be redirected to the parent.

This would require an extra column in the domain_alias table and a little bit of logic in the bootstrap or init phase. This is part of integrating #306495: Change "www." prefix handling with Domain Alias.

bforchhammer’s picture

I'm on it... :)

agentrickard’s picture

Actually, this should read "we will need a setting - per alias -..." -- the idea being that you might have the following rules:

domain: example.com

alias 1: www.example.com | redirect: no
alias 2: old.example.com | redirect: yes
alias 3: *.example.com | redirect: yes

In all cases, the redirect would go to the parent domain, example.com.

bforchhammer’s picture

StatusFileSize
new6.34 KB

I've implemented the redirection feature (new database column in domain_alias table, redirection in domain_alias_init() and checkboxes on domain alias administration page).

The administration pages probably need some styling - it doesn't look as "nice and simple" as before anymore...

I'm not sure what to do about the "www." subdomain redirection feature... I see different possible options at the moment:

  • No special treatment: users have to add a "www." alias themselves manually and enable redirection if they'd like that feature.
  • Keep current www-redirection configuration option and automatically enable the redirection feature for respective domain aliases
  • Add an option to the "Create new domainrecord" page to automatically create a respective domain alias and enable redirection when creating a new domain record. This still would need some manual handling for the root domain.
  • Maybe in combination with the previous point: add a batch operation which allows to automatically create www. aliases for all active domains.
agentrickard’s picture

Status:Needs work» Needs review

My plan was to remove thh www.* redirection feature -- or possibly put in an option to auto-create aliases for all domains. This will be the x.2 release, so removing that feature seems ok to me.

We could also put in a domain_alias_enable() subfeature that checks for the presence of that setting and auto-creates the www. prefix, and set the redirect to TRUE -- I think that is the best upgrade path. You can let me worry about that if you like.

I am planning, as part of the patch, to make alterations to the interface to make it look like the rest of the module.

bforchhammer’s picture

Ok, all fine with me... :)

agentrickard’s picture

Status:Needs review» Fixed

This has been committed to HEAD for further testing.

Anonymous’s picture

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

agentrickard’s picture

Version:6.x-1.0-rc5» 6.x-2.0-rc1
Status:Closed (fixed)» Fixed

I cleaned up a lot of the code and redesigned the form for rc2. Looking good.

agentrickard’s picture

Version:6.x-2.0-rc1» 6.x-2.0-rc3
Status:Fixed» Active

@bforchhammer

I am running into the following situation:

- Domain
-- Alias
====

- example.com
-- www.example.com
-- one.example.com
-- *.example.com

- foo.example.com
-- foo.*.example.com

In this case a call to 'foo.bar.example.com' is aliased correctly. But a call to 'bar.example.com' fails and reverts to the default domain.

The code has changed some, so a review would be great.

bforchhammer’s picture

Strange...

Maybe have a look at the sql statements if you can... My first guess would be that something on the LIKE comparison is not working properly... the asterisk should basically just be replaced by an ampersand sign, which would allow any character to be matched on it in sql. On the other hand, if foo.bar.example.com is working correctly (foo.%.example.com) then bar.example.com (%.example.com) should actually just work as well...

I'll try to do a code review next weekend. Hope that's not too late ;-)

agentrickard’s picture

Not too late. This kind of testing is what we're waiting for.

I have made adjustments to the SQL. I am afraid that we might have to run multiple checks using IN instead of LIKE.

I also wonder if we need support for '?'.

bforchhammer’s picture

I just installed the current HEAD and it works very nicely so far... :) I like the new alias admin page, way better than mine.

There's one error in domain_alias.admin.inc: when we insert new aliases (line 212) the pattern needs to be converted to the sql-equivalent as well.

<?php
function domain_alias_form_submit($form, &$form_state) {
 
// The new alias fields are always present.
 
foreach ($form_state['values']['domain_alias_new'] as $id => $alias) {
    if (!empty(
$alias['pattern'])) {
     
$alias['pattern'] = _domain_alias_placeholders_to_sql($alias['pattern']); // ADD THIS LINE!
     
db_query("INSERT INTO {domain_alias} (domain_id, pattern, redirect) VALUES ('%d', '%s', '%d')", $form_state['values']['domain_id'], $alias['pattern'], intval($alias['redirect']));
    }
  }
  if (isset(
$form_state['values']['domain_alias'])) {
?>

This might be what caused the error you described in #18... Please check whether this fixes it.

While thinking about that error I realised something else... At the moment it was actually just "luck" that "foo.*.example.com" worked as expected. The LIKE matching with % in sql also matches dots therefore "foo.bar.example.com" could just as well be matched by "*.example.com" - whichever row turns up first is used in the end.

On a side note: When I did the fresh install I first forgot to enter a "primary domain name" and that value being empty messed up quite a few things... checking + a warning message might be good..

agentrickard’s picture

I go back and forth on the checking piece. It would be trivial to set the primary domain on install:

variable_set('domain_root', $_SERVER['HTTP_HOST']);

-or-

variable_set('domain_root', $_SERVER['SERVER_NAME']);

What I have tried to do instead is make DA inactive if this value is not present.

bforchhammer’s picture

Version:6.x-2.0-rc3» 6.x-2.0-rc4

More...

In _domain_alias_placeholders_to_sql() I don't know why we have two percentage signs as a replacement for the asterisk *. One should actually work just fine?

In function _domain_alias_validate() we could extend the sql statement for validation 4) (line 188) so that it also checks for other aliases that could possible match the same domain name... (didn't my version do that?) (and $_domain_id in line 187 doesn't seem to be used anywhere anymore at the moment; I used it in that sql statement).

What I have tried to do instead is make DA inactive if this value is not present.

Hm, I'm not sure I understand... the "test subdomain" was marked as inactive but the root one wasn't; I think it might be better to just set domain_root during domain_install() to the server name as you suggested..

agentrickard’s picture

OK, I think I corrected these issues in HEAD. I also enforced a limitation of one wildcard per alias. It may be a problem for some, but it makes the code much, much simpler.

We now setup the primary domain on install. Also see domain_alias_best_match() for how to handle multiple wildcard matches, which _should_ only affect the * wildcard.

Hoping to do rc5 on Sunday.

agentrickard’s picture

Have you done any pgSQL testing? I am especially concerned by this query:

        $result = db_query("SELECT alias_id, domain_id, pattern, redirect FROM {domain_alias} WHERE '%s' LIKE pattern", $subdomain);

On MySQL, the current () around pattern do not seem to matter.

bforchhammer’s picture

None at all to be honest... At first that "inverted use" of LIKE was actually only an experiment and I didn't think much about it later on.
This needs to be tested.

agentrickard’s picture

Status:Active» Needs review

There was a logic error in the domain_alias_bootstrap_lookup() function that cased the module to look for aliases even if an exact match had been found. Fixed.

LIKE seems to be valid SQL here, according to Mimer.

ariflukito’s picture

Hi guys I just tried domain alias. I found out I can't put port number in the alias like this alias.example.com:81. Should we allow colon as valid char or maybe should I just use alias.example.com* ?

agentrickard’s picture

Hm. Probably an oversight.

I think port (:) should be valid. It is in the main module, so should not get stripped here.

One thing that I have never tested is using multiple wildcards in an alias. So I think we should support:

example.com:*

But wonder what happens with:

*.my.*.example.com

Or *.example.com:300?

For now, does example.com* work? I know that much of my code assumes that * appears between . .

ariflukito’s picture

yes example.com* works

edit: should we do validity check if the alias matches existing domain record?

agentrickard’s picture

I thought we already did that. If not, yes, we should.

agentrickard’s picture

Status:Needs review» Needs work
inforeto’s picture

Subscribing.
Looking for the backport to 5.x

agentrickard’s picture

The back port could be quite a bit of work. This change is stable enough to port, if you have the time.

agentrickard’s picture

Version:6.x-2.0-rc4» 6.x-2.0-rc6
Status:Needs work» Patch (to be ported)

I have added some checks for ports and duplicates to the existing module.

Seems ready for the world.

bforchhammer’s picture

Status:Patch (to be ported)» Fixed

This has been commited for a while now and seems to be working well... I hope I'm not stepping on anyone's toes by settings this to fixed. :)

(My apologies if this issue was left open for the purpose of a 5.x backport; I wouldn't think there's still much interest with Drupal 7 around the corner).

agentrickard’s picture

I would agree. D5 is in critical bugfix mode only.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.