$mosConfig_live_site hack and multiple domainnames

So I ran into the following problem: My Mambo site is normally available under "www.example.org", and in DNS I have some extra names like "example.org" and "www2.example.org" pointing to the same website. Because Mambo uses the $mosConfig_live_site variable often (both in Content Items as in the cache), it is only possible to have 1 domainname for 1 Mambo site.

To have more than 1 domainname for the same Mambo site, there are some workarounds:

• Using Apache's mod_rewrite module to rewrite the other domainnames to the one your Mambo site is running on
• Changing the variable $mosConfig_live_site to have a value "http://".$_SERVER['SERVER_NAME']

Now for some reasons which are beyond the point I'd like to make, the mod_rewrite option was not sufficient, because the main domainname was not yet known in DNS. (Some work may even have been done using the dark side of the Force.) So the second option was the one to go for.

Using the second option you open up the file "configuration.php" and change the $mosConfig_live_site as follows:

Code:

$mosConfig_live_site = 'http://'.$_SERVER['SERVER_NAME'] ;

Now when I am visiting my website "www.example.org" the variable $mosConfig_live_site is called and being translated into "http://www.example.org", while if I am visiting the same website but through the URL "www2.example.org" the $mosConfig_live_site changes the site name into "http://www2.example.org". Perfect!

But there were still two problems:

• Every time a page is loaded while you have caching enabled in Mambo, that page is saved in the cache under the URL it was called under (for instance "http://www.example.org"). Now if I visit the same page through "http://www2.example.org" some content is cached under the first domain. Now imagine that the first domain is not available anymore (because you are migrating from one domain to the other), than the cached website is broken, right? The obvious thing to do is clean the cache, which works.
  
  But imagine that this switching between domains is happening all the time - like every 12 hours the first domain is used, and every other 12 hours the second (weird situation, I know, but I have my mysterious reasons). You could just turn off the cache, but this downgrades performance as well.
  
  So I choose for another simple hack: Just have a cache for every domainname being used

Code:

$mosConfig_cachepath = $mosConfig_absolute_path . '/cache/' . $_SERVER['SERVER_NAME'] ;

The only tricky part here is that Mambo doesn't create the cache directory by itself when it's not existing. You have to create it yourself. In other words you have to create a subdirectory in the /cache/ directory for every domain name your website is going to be called by.

• Now the first problem was solved, but the second problem now involved the first one as well. Every time you save changes in the Global Configuration of the Administrator pages you'll overwrite "configuration.php", deleting our wonderfull hacks above.
  
  Again a simple solution would be to change the file permissions to make the "configuration.php" file not writable by Mambo. But ofcourse this is not the way we want it to be.
  
  So I decided to change the source code involved with changing "configuration.php". The file is changed by the component "com_config". I found the following section in "/administrator/components/com_config/admin.config.php". Here an array with strings (which translate finally in the mosConfig variables) is placed into a $txt string, while in the end $txt is being placed in "configuration.php".

Code:

function getVarText() {

    $txt = '';

    foreach ($this->_alias as $k=>$v) {

        $txt .= "\$$v = '".addslashes( $this->$k )."';\n";

    }

    return $txt;

}

and I changed it into this:

Code:

function getVarText() {

    $txt = ''; 

    foreach ($this->_alias as $k=>$v) {

        /* jisses hack */

        if( $v == 'mosConfig_live_site' ) { 

            $txt .= '$mosConfig_live_site = \'http://\'.$_SERVER[\'SERVER_NAME\'] ' . ";\n";

        } elseif( $v == 'mosConfig_cachepath' ) { 

            $txt .= '$mosConfig_cachepath = $mosConfig_absolute_path . \'/cache/\' . $_SERVER[\'SERVER_NAME\'] ' . ";\n";

        } else {

            $txt .= "\$$v = '".addslashes( $this->$k )."';\n";

        }   

    }   

    return $txt;

}

Now every time you change the configuration through the Global Configuration menu, my special hacks are saved.

Well, I had a lot of fun today. Hope somebody finds this all useful.

Regards,

Jisse Reitsma
12mambo -- 3 simple steps to success
www.12mambo.nl

Asphyx vbmenu_register("postmenu_319854", true);

Posts: 2,282

the best way is still to male seperate roots for each domain, give them their own configuration.php file that has a proper setting of LiveSite, cache and Absolute path and using apache config to set alias' for all the folders mambo uses in each root...

IF you should ever want to put something different in that domain later on it would simply be a matter of making a new DB and changing the configuration for that particular domain....

Elpie vbmenu_register("postmenu_320589", true);

Posts: 495

Just to add - I use $mosConfig_live_site = 'http://'. $_SERVER['HTTP_HOST']; for all my sites and have been doing so for a little while now. I don't use this for the same reasons as the first poster.

The problem with the hardcoded url is that it overrides the default settings of many servers. Most servers these days are set up with aliasing so the site can be accessed via http://domain.com as well as through the www subdomain.
www is deprecated and completely unneccessary, however enough people still try to find a site by entering www into the url that provision must still be made for it. $mosConfig_live_site = 'http://'. $_SERVER['HTTP_HOST']; gets over that problem by taking the domain from the path a visitor has entered the site on.

While it works beautifully it does leave a problem of its own (which is not a problem for anyone who works the way I do, but is a problem for newer users) and that is, once this setting has been placed, you cannot edit configuration.php from the administrator backend.

If you are comfortable with only editing config manually, and not through the backend, then this is a good thing to implement. (The advantage of doing manual editing is that config need never be made writable, so there is not even a moments window of opportunity where the world could get in).

What I would really like to see is config being changed so this is the default setting on all releases and does not stop config being updated through the backend.

Asphyx vbmenu_register("postmenu_320605", true);

Posts: 2,282

Quote:

Actually what many do is set wildcards to the main domain which sends any request to a particular domain and all it's subs to the same IP address...

It is not important for most web pages...
It is really only important for Java!
Java Security will only allow applets to run from the domain they were called from....

So if you are at www.yourdomain.com and the CMS calls it from plain yourdomain.com you will get Java Security errors and no functions...

The truth is though that the main domain should not be used for anything but PDC (Primary Domain Controllers)...
They should have their own IP address and a web page in it's web root that will redirect requests to the proper www.yourdomain.com

Elpie vbmenu_register("postmenu_320988", true);

Posts: 495

I have to disagree with you there Asphyx

Quote:

www is a subdomain which is not only deprecated but completely unneccessary.
There is no need to alias a site to www except that so many visitors still add the stupid thing in urls they write directly into browser windows.
Aliasing means more calls on apache. The sooner everyone gets used to using proper urls the better IMO.

Asphyx vbmenu_register("postmenu_321091", true);

Posts: 2,282

It's unneccesary simply because most people don't run a full setup the way it was intended to be when the domain conventions were first invented...

Now Web sites do their own Authentication which while it works was not the way it was supposed to be....

The main Domain was supposed to be a PDC and handle all authetication requests for that domain...It also is supposed to handle all the DNS as well...

That server was never meant to be a public server to reduce the security risks of hacking into the auth modules...

For a mom and pop single user setup the single server is fine...
But when creating a high bandwidth high user set up you should actually have multiple web servers all linked to a single PDC for Auth. Then you can do peering and bandwidth throttling to handle large loads...
This way you can set up different servers for each region of service and reduce latency.

in a set up like this the main domain is tied to the PDC that controls access for the entire domain...Allows intranet and internet authentication all on a single server...

the reason why what you say about peoploe typing in the www is true only because in most DNS setups a wildcard is used and sends people to the web server even if no subdomain is defined...

If a server reacts to www.yourdomain.com AND reacts the same to yourdomain.com then chances are real good that typing in
ww2.yourdomain.com or xxx.yourdomain.com will also send you to the web server as well!

But the REASONS for using the proper domain are evident in the problems it causes for Java!
you should use the full www.domain.com simply so that should the need arise to move to a fully peered and throttled multi server system that primary domain can be used to handle the authentication needed to manage all the servers...

---

Add this page to your favorite Social Bookmarking websites