domain redirection

The advantage of this is in reducing content duplication for sites that shouldn't be serving to multiple domains.

More information can be found at: http://blog.melimato.com/using-apaches-redirectmatch-instead-of-serveral...

Well, this is really a different feature: domain redirection. Aliases may be useful and desired in certain conditions (think of the domain module for example) so I wouldn't want to ditch that functionality.

But I agree that what we really want, by default, is redirection.

I'm not sure creating a separate vhost is necessary, however. I am thinking of something amongst those lines:

Heck, it could even be as simple as:

... ie. don't need to list every domain, just use a "not" (!).

That would be fairly simple to implement: a frontend module that would just add a checkbox to enable redirection and a backend module that would implement that hook I always forget the name to add stuff to the apache vhost.

Actually, this could be strapped on the alias module...

I support this feature.

We are looking at expanding the hosting_alias module to do this... ie if you have a site foo.example.com and you want to create the alias bar.com, with all traffic to foo.example.com redirected to bar.com. Any suggestions for the best way to implement this appreciated. I am in favour of moving the alias field out of the node form and into its own tab a la migrate etc

While re-reading the code to answer that last question, I figured that there *was* a conflict with the alias system... Currently, aliases include adding ServerAlias directives to the vhost (hardcoded in web_server/provision_apache_vhost.tpl.php, which are fed by the alias module in the frontend. That's fine *but* the backend also creates *symlinks* in sites/ for all the aliases. If we implement redirection, that will have to be turned off.

So what I think is this: the frontend alias module should have an extra "redirect" flag that turns the aliases into redirection (that would be in hosting_alias_form_alter()). That flag then would need to be passed to the backend (in hosting_alias.drush.inc). Then the backend needs to use that...

I'm just going to write up some patch for you to test, how is that? :)

So this is likely to slip past 0.3 (since we're in feature freeze), but here we go.

Had issues with the site verification after applying this patch

Also the patch implies (didn't get it working so can't be sure) that the alias will redirect to the master url. We are looking to do the reverse so an option to do that would be cool. Becomes problematic with more than one alias

Are you sure those issues are related with the patch? I think the problem you are describing is common in rc2, and is resolved by #529382: proper recursive functions for chmod/chgrp/chown and #203204: Uploaded files have the permissions set to 600.

ok.. I didn't have the file perms patch applied but I was using head of aegir so that is probably my issue. I will try again with the core patch applied

Patches applied cleanly.

Site installed, but no alias added to host file

Hosting Settings as follows:
Site Aliases
( empty ) Domain used for automatic subdomain hosting
(uncheck) Generate www.domain.com alias automatically
(uncheck) Generate domain.com alias automatically
(checked) Use redirects instead of aliases by default

Create Site settings:
Domain name: domain.com
Domain aliases: www.domain.com
Redirection: (checked)

vhost file created

Hum, that's odd: I can reproduce your problem. It seems that automatic aliases work but manual aliases don't.

I reverted the patch and manual aliases did work, so I did something that broke manual aliases on the frontend (or the backend?).

I didn't mean to change the status here originally, but anyways, here's a reroll of the patchset, testing required again. Only the hosting part changed, so I'm just uploading this patch to avoid confusion, the provision patch is still valid.

This one was really hard to figure out, i was using db_result of db_fetch_array and got confused over that...

something getting added to the vhost entry now, but the redirection isn't working.

Created vhost entry:

My earlier example code works without needing the multiline rewrite rule, see below for a working example:(eg: this will automatically redirect http://domain.com/contact to http://www.domain.com/contact)

I like your approach better. What's also interesting is that having a separate vhost clarifies things... Furthermore, this should become the basis of the vhost engine: right now, all this is tightly coupled with the sites engine, while we may want to allow users to create arbitrary redirections and things like that. The SSL engine would use things like that too. So I support the idea of a separate vhost (and a separate file?).

See #541754: abstract away vhost engine for the vhost engine abstraction..

I've tended to put them in the same files as per my example, because I see them as related..

But it would make logical sense to split them in case you later decide to set up a separate site.

Having them separate would make it a lot easier if you did decide to do that.

I've tried this manual method (as per realityloops suggestion) on my sites, and it works well.

I *think* i fixed this in git, I have updated the redirection branch in git. Here is a reroll of the patches. Please test

Patches applied cleanly, I had one issue though:

I had set "Use redirects instead of aliases by default", but the redirect wasn't working. This turned out to be because, although it had appended to the site's vhost config correctly, the main VirtualHost above it still added a 'ServerAlias' parameter of the url to be redirected, which meant the new added VirtualHost tag was ignored. Removing the ServerAlias line and restarting Apache of course made the redirect work immediately

So my vhost config looked like this:

removing that ServerAlias fixes it. Also I don't think the DocumentRoot is required for the redirect VirtualHost, as it never needs to read from a dir.

Patch attached fixes the above (doesn't print a ServerAlias if $redirection), removes DocumentRoot from the redirection template. Also tiny typo in the Site Aliases form and a slight reword -- feel free to ignore this, it's just opinion :)

This will need to be ported now that the ports stuff hit the tree (fairly simple: we need to use the $site_port in the template instead of just "80"), see http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/w...

I don't know what went wrong with my other patches the other night but I blame the cool early morning air.

New patches attached, and I take into your #18 one extra $site_port in provision_apache_vhost_disabled.tpl.php

Committed. We'll see how it works.

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