Posted by bforchhammer on July 18, 2008 at 5:07pm
| Project: | Domain Access |
| Version: | 6.x-2.0-rc6 |
| Component: | Code |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
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).
Comments
#1
Hm. No attachment.
#2
Hm. Here we go...
#3
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.
#4
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?
#5
This will -- if approved -- be backported to a 5.x.2 release. It is easier to test on one branch.
#6
No changes needed, the module (file #2) seems to still work fine with the latest HEAD version...
#7
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.
#8
Ok. Wow. I just tested this for the first time.
The domain wildcarding feature is really awesome.
#9
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.
#10
I'm on it... :)
#11
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.
#12
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:
#13
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.
#14
Ok, all fine with me... :)
#15
This has been committed to HEAD for further testing.
#16
Automatically closed -- issue fixed for two weeks with no activity.
#17
I cleaned up a lot of the code and redesigned the form for rc2. Looking good.
#18
@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.
#19
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 ;-)
#20
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 '?'.
#21
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.
<?phpfunction 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..
#22
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.
#23
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).
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..
#24
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.
#25
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.
#26
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.
#27
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.
#28
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* ?
#29
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.comOr
*.example.com:300?For now, does example.com* work? I know that much of my code assumes that * appears between . .
#30
yes example.com* works
edit: should we do validity check if the alias matches existing domain record?
#31
I thought we already did that. If not, yes, we should.
#32
#33
Subscribing.
Looking for the backport to 5.x
#34
The back port could be quite a bit of work. This change is stable enough to port, if you have the time.
#35
I have added some checks for ports and duplicates to the existing module.
Seems ready for the world.
#36
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).
#37
I would agree. D5 is in critical bugfix mode only.
#38
Automatically closed -- issue fixed for 2 weeks with no activity.