Yet another week of development is nearly over (at least for me). What was this week all about? Apart from the really low temperatures outside (on Tuesday it was -24C at 4am), I focused mainly on extending the multi-site support in Magnolia.

This feature exists for years already. But what it really means in context of Magnolia? In general you can setup the server to run mulptiple domains and you can configure such server to redirect to different subtree respective to what domain was the incoming traffic directed. The Magnolia part of the multi-site support allows you to assign different site (and theme) to each such subtree and can therefore make each site look and behave completely different. As normal in Magnolia you can of course also control the permissions for each subtree. So far so good. One might even ask, what else do you ever want from multi site support?

Here's one thing that comes up quite often: hide the fact that each site is a subtree. Why? Many reasons. Spanning from shorter or nicer URLs to Search Engine Optimization. Until now, you could work around this issue the same way as a lot of other solutions do - externally, e.g. use a reverse proxy and/or mod_rewrite to hide the extra path and process all the content to rewrite links on the fly.

During the course of last sprint we tried to make this internal to Magnolia without the need for outside solution. You can check out the trunk of Magnolia (or 4.3-m1 tag) to see the result of team effort. The initial implementation of the feature didn't look so complicated, but as with many other things the devil lies in the details. Once the basic feature was working, we found out that it can be quite confusing for the editors when accessing the admin central using different domains and also (due to url shortening) it was quite difficult for the system itself to display pages in the right context from the wrong domain.

Seeing that, we tried to go one step further. The result can be seen in the milestone build. 

Having multisite installation of Magnolia now means that everything is driven by the domains and site configuration. Depending whether you access admin central using domain that has assigned site configured with specific subtree, you will see only that subtree in the website view and have all the urls and links shortened automatically. On the other hand accessing the site using domain that has not assigned any site or by default has not assigned any subtree, you will see everything as before. This would be most often useful for admins, while the editors will probably prefer access via specific domain name to limit the view to their respective subtree only.

BTW, if you want to try, but do not want to wait for final release (or build the things yourself), you can always grab a snapshot from the hudson or the milestone release from our maven repo.