Hello Antti

Thanks for the reply. It gives me a better idea about the mapping feature.
When I have a little time (as opposed to right now) I will delve into it a
little deeper, and see if I can formulate some interesting questions.

My main problem was that we had some mappings for things like the media and
dms workspace in our site configuration that were mindlessly copied (no one
knew what they were for), and were causing problems when settings became
invalid. Your reply gave me enough grasp to cut all that short, which is
nice.

regards,

Ernst

2010/11/2 Antti Hietala <[email protected]>

>
> The multi-site feature is insufficiently documented at the moment, and
> mappings is perhaps the trickiest part of it. Thanks for point this out,
> Ernst. We will write better documentation for it. Here's an overview for
> everyone's benefit.
>
> Multi-site is provided by the ETK module. It lets you to manage multiple
> sites with unique templates, themes and domains in a single location:
> - Microsites like company subsidiaries that inherit templates from parent
> company but have their own theme for unique look & feel
> - Localized sites that cater to visitors in a particular language or
> geographical area
> - Campaigns with vanity URLs (winter2010.example.com)
>
> Look at the "demo-project" and "demo-features" examples. Both have
> single-rooted site trees in AdminCentral. This is where you add new site
> hierarchies. Site definitions under Templating Kit > Site definitions
> configure each site. The "default" site definition is the foundation. It
> provides a template prototype and defines what templates are available. Site
> specific definitions extend the default using the "extends" property. This
> saves time and effort as you only need to define additions and exceptions.
>
> Mappings connect a site definition to a site hierarchy. handlePrefix
> property identifies where content should be served. In demo-project it
> points to /demo-project, in demo-features to /demo-features, the respective
> root nodes of the site trees.
>
> This gets interesting when you point to a node deep in the hierarchy
> instead. For example, suppose you have a campaign in
> /demo-project/campaigns/winter2010. By setting the handlePrefix to this
> path, you apply the site definition to that subtree only. In the same site
> definition you could define a custom "wintery" theme for your campaign and
> assign a vanity URL such as winter2010.example.com. Visitors who access
> winter2010.example.com are served content from
> /demo-project/campaigns/winter2010, not from the site root, and they
> experience your cool campaign look & feel.
>
> URIPrefix is used to inject a path into a URL, thus shortening the URL. For
> example, suppose your campaign site resides very deep in the hierarchy
> (/demo-project/marketing/campaigns/2010/winter). The URL is long and ugly,
> and search engines rank deep content lower. Shorten the URL by setting
> URIPrefix to /winter2010 and add a domain www.example.com to the same site
> definition. Visitors who access the site at www.example.com/winter2010 are
> served content from /demo-project/marketing/campaigns/2010/winter. The
> short, snappy URL also fits print ads better.
>
> Couple more properties that don't show up in the examples. In addition to
> domain "name" property, you can set a "context" such as magnoliaPublic and
> "port" such as 8080. Context and port are needed to make links between sites
> work. You won't need them if you deploy to root context and default port.
>
> Resources:
> Jan's blog post Multi-site support in Magnolia
> http://weblogs.java.net/blog/rah003/archive/2010/01/28/multi-site-support-magnolia
> Jan's blog post Once more on the multisite support
> http://weblogs.java.net/blog/rah003/archive/2010/05/03/once-more-multi-site-support
> Multi-domain video
> http://www.magnolia-cms.com/home/magnolia-cms/magnolia-4-3/enterprise-multi-site-cms.html
>
> Note about virtual URI mapping: VUM should only be used for a handful of
> pages. You might use VUMs for a Christmas campaign but once your campaign
> becomes a Christmas shop you want to assign a site definition to it and make
> it a legitimate site. This gives you more options such a localization.
> Virtual URI mapping
> http://documentation.magnolia-cms.com/reference/virtual-uri-mapping.html
> Vanity URLs
> http://finnotype.blogspot.com/2010/10/vanity-urls-with-magnolia-cms.html
>
> Tip: Under /demo-project/domains we define a domain name:
> www.demo-project.com. This domain name is not registered to Magnolia, nor
> to you. You can add it to your .hosts file [1] to mimic the effect. When you
> access the site with the domain name, content is served from the
> /demo-project tree because the mapping says so. The big advantage of doing
> domain name mapping in AdminCentral is that the CMS team becomes more
> autonomous as there is no need to configure a web server.
> [1] http://en.wikipedia.org/wiki/Hosts_(file)
>
> Hope this helps. Please reply with the use case you are trying to solve. It
> can serve as a good example in the eventual doc.
>
> --Antti
>
>
> On Nov 1, 2010, at 10:14 AM, Ernst Bunders wrote:
>
> >
> > hello
> >
> > We are having some problems with the mapping feature for the multisite
> > configuration. Our main problem is that we simply don't understand how
> > it works, what it is supposed to do, and how it goes about it's
> > business doing it. Blatant ignorance of the most deplorable kind! The
> > only piece of configuration I understand is where you say what the
> > website root is for a site configuration.
> >
> > So what I would really like is some documentation on this point.
> > Preferably not just of the 'how do I..' type, but I need conceptual
> > outline of the mapping system. What we are presently doing is just
> > 'tweaking the knobs' until something (semi)satisfactory pops out, and
> > this is not the way to go, it takes a lot of time. Last week I spend
> > some time figuring some specific problem out by reading the code, but
> > I find the mapping stuff is not so easily understood that way.
> >
> > So any pointers to existing documentation on this topic would be
> > highly appreciated, and if there isn't any, perhaps this request could
> > be a trigger to produce some on this rather crucial part of site
> > definition.
> >
> > regards,
> >
> > --
> > Ernst Bunders
> > Developer @ VPRO
> >
> >
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <[email protected]>
> > ----------------------------------------------------------------
>
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------
>
>


-- 
Ernst Bunders
Ontwikkelaar VPRO


----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to