Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Would be very nice in development environments to allow for alias patterns to be created for each domain. There is some code I have to add to custom modules for every project, and I wonder if it can be abstracted.
For instance:
/**
* Implements hook_domain_insert().
*
* Creates aliases for test environments.
*/
function custom_domain_insert($domain, $form_values = array()) {
$aliases = custom_domain_alias_list($domain);
foreach ($aliases as $alias) {
db_insert('domain_alias')
->fields(array(
'domain_id' => $domain['domain_id'],
'pattern' => $alias,
'redirect' => 0
))
->execute();
}
}
/**
* Implements hook_domain_update().
*
* Manages aliases for test environments.
*/
function custom_domain_update($domain) {
$aliases = custom_domain_alias_list($domain);
foreach ($aliases as $alias) {
$count = db_query("SELECT 1 FROM {domain_alias} WHERE domain_id = :domain_id AND pattern = :pattern",
array(':domain_id' => $domain['domain_id'], ':pattern' => $alias))->fetchField();
if (empty($count)) {
db_insert('domain_alias')
->fields(array(
'domain_id' => $domain['domain_id'],
'pattern' => $alias,
'redirect' => 0
))
->execute();
}
}
}
/**
* Generates lists of domain aliases for our test servers.
*
* @param $domain
* A domain record array.
*
* @return $aliases
* An array of alias patterns to save.
*/
function custom_domain_alias_list($domain) {
// 'canonical' here is another nice trick for multiple servers.
if (isset($domain['canonical'])) {
$base = str_replace('.', '', $domain['canonical']);
}
else {
$base = str_replace('.', '', $domain['subdomain']);
}
$aliases = array(
$base . '.%.sandbox', // User directory
$base . '.dev.example.com', // QA site
);
return $aliases;
}
Comment | File | Size | Author |
---|---|---|---|
#6 | 1303616-alias-auto-create_1.patch | 18.47 KB | generalconsensus |
#6 | 1303616-alias-auto-create_1.patch | 18.47 KB | generalconsensus |
#3 | 1303616-alias-auto-create.patch | 18.43 KB | agentrickard |
#2 | 1303616-alias-auto-create.patch | 14.84 KB | agentrickard |
#1 | 0-domain_alias.patch | 6.19 KB | agentrickard |
Comments
Comment #1
agentrickardIf anyone wants to see this, here's the first pass patch. Warning, it still has some devel debug statements in it.
Comment #2
agentrickardAnd a better patch.
I also have a vision here for registering site server patterns, so that URLs work on test and dev environments. The beginnings of that patch are here as well.
We would match HTTP_HOST to SERVER and run $domain['subdomain'] through the provided REPLACE pattern. We would need a token to indicate the part of the HTTP_HOST value. Here is it [2].
Comment #3
agentrickardThis is shaping up, but likely needs to wait a bit. The server logic is tough.
This is a nice-to-have feature that replaces some functions that I have to custom code for each project.
Comment #4
babbage CreditAttribution: babbage commentedI would encourage not assuming that the staging and live environments are running on separate servers.
I have sites where the staging and live sites are installed in different base domains within a single user account on a VPS (example.com and dev.example.com, where the latter is treated on the server as a full domain within the account, not as a subdomain of the example.com). They are in separate directory paths running separate Drupal installations and connecting to separate MySQL databases, but it is the same server. Would be great for any solution to accommodate this possibility.
Comment #5
agentrickardNone of this code assumes separate servers. Perhaps you mean that we should use the term "hostname" in the UI instead of "server".
Comment #6
generalconsensus CreditAttribution: generalconsensus at Forum One commentedCan we retry with this patch, I wasn't able to patch cleanly with original patch