Subdomain Aliases

Hm. No attachment.

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.

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?

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

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.

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

The domain wildcarding feature is really awesome.

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.

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.

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.

This has been committed to HEAD for further testing.

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

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

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 '?'.

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.

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.

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.

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.

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* ?

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

yes example.com* works

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

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

Subscribing.
Looking for the backport to 5.x

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

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

Seems ready for the world.

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