[Hippo-cms7-user] relative path to contents

Ard Schrijvers a.schrijvers at onehippo.com
Tue Feb 9 15:47:36 CET 2010

Hello Mansour,

I am not totally sure what problems might arise. Afaik, the namespaces
will be hard to move, as they are part of the cms.

wrt virtualhosts and hst configuration, I have been planning to move
them to one single parent folder. As hst:configuration can be shared
amongst different subsites, I think having them below a single project
wouldn;t make sense. Virtualhosting seems to me natural to not have
per subsite.

I think the following structure might be a better default in the hst:

- hst
   |- virtualhosts
   |      `- etc
   `- hstconfigurations
             |- default
             |       `hst:configuration
             |                `hst:configuration
             |- somesubsite
             |       `hst:configuration
             |                `hst:configuration
             `- othersubsite

now, your subsites below /preview and /live can point normally to the
'default' hst configuration, and your specific subsite to the
'somesubsite' or 'othersubsite' configuration

The HST2 is compatible with this structure from the top of my head:
All you need is to change the hst-config.properties:

virtualhosts.repository.path = /hst:virtualhosts
observation.sites.config.node.path = /hst:configuration/hst:configuration


virtualhosts.repository.path = /hst/hst:virtualhosts and
observation.sites.config.node.path = /hst/hstconfigurations

the first is really the exact path, the second is the 'root' of the
configuration, used for invalidation when something changes in the hst
config in the repo

Regards Ard

On Tue, Feb 9, 2010 at 3:25 PM, Mansour Al Akeel
<mansour.alakeel at gmail.com> wrote:
> Hello Ard
> Thank you for providing these creative idea. I think as hippo grows we
> will see more users contributing creative tips like this one. I am still
> looking into the mutiple sites, nothing easy. But I loved the idea of
> creating multiple sites with virtualhosts. Works great for an
> organization with changing departments.
> I have started working on muliple sites before I read your post. In
> other words, I read your post after I created my own mess :)
> I am wondering now about the reasons for designing the repo more like a
> relational data. I mean, why not putting all the config/contents related
> to a project under one tree in the repo, instead of using hipposys:softdocument ?
> I think this will be easier for tools to building projects, and will
> open the doors for utilities to even migrate from other CMS's.
> It looks to me, that Hippo CMS can be customized to adopt this
> structuring of data hierarchy easily, but I am wondering why not doing
> it like this in the first place. What difficulties I may run into if I
> try to change the way it's organized, provided I can get it to work :).
> Here's a demo of what I mean:
> project
>    -> contents
>    -> namespaces
>    -> hst:configuration
>        -> sitemap
>        -> sitemenus
>        -> pages
>        -> components
>        -> templates
>    -> hst:contetns
>        .....
> May be the way it's now helps in the reusability of the components. So
> components written for other projects can be used in the current one,
> but the tree like structure doesn't limit the re-usability.
> So the question is, what difficulties I may run into by changing the structure?
> Thank you.
> On Tue Feb 09,2010 08:15 am, Ard Schrijvers wrote:
>> On Mon, Feb 8, 2010 at 11:41 PM, Mansour Al Akeel
>> <mansour.alakeel at gmail.com> wrote:
>> > Hello Ard,
>> > No I am not subscribed to the HST dev list. I was under the impression
>> > this is more related to the CMS, and looked here. I will subscribe to
>> > the HST.
>> >
>> > I saw the post related to this issue, and went quickly over it. I will
>> > give it a try soon. And yes, that's exactely what I am trying to do,
>> > running multiple sites on the same instance. Thanks for the flexible
>> > design of Hippo CMS, for allowing this, just like cocoon. I don't think I will have to
>> > work again with mod_rewrite ;)
>> Our goal indeed was to have runtime adding of subsites where no
>> changing of httpd rules or what soever is involved. For example this
>> website, http://nu.pvda.nl/, has about 600 to 700 subsites already
>> (all municipalities in the Netherlands, for example
>> http://amsterdam.pvda.nl/). Obviously, for adding a subsite, they do
>> not want to need us, or have another rule to httpd conf for the 701
>> subsite. They have one httpd rule:
>>  <VirtualHost *:80>
>>   ProxyPreserveHost On
>>   ProxyPass / http://localhost:8080/site/
>>   ProxyPassReverse / http://localhost:8080/site/
>>   ProxyPassReverseCookiePath /site /
>> </VirtualHost>
>> For your info, I'll repeat some explanation of mine on the hst dev
>> list some time ago here (it is for how to work locally with a context
>> path in your urls, but on production behind httpd, do not have this
>> context path in the urls that the HST2 creates for you):
>> ////////////////////////////////////////////////////////////////////////////////////////////////
>> Virtualhosts and context path info
>> the 'show context path' is not only for 'external' links: it is for
>> all absolute links (so everything that uses hst:link for example). So,
>> Wim, I'll try to explain now:
>> When you have your application running in a context, for example as
>> site.war in tomcat, your context is /site. Right? A call for /home
>> will and can never hit the site application. We can not perform magic
>> with the HST2 :-)
>> Now, what is this 'hst:showcontextpath' then. It holds the following:
>> when you set it to false, all urls won't start with /site. So instead
>> of /site/home, you'll get /home. And, as explained already, /home
>> directly on tomcat, we cannot do any magic.
>> So why then did we add this 'hst:showcontextpath'? It is meant, when,
>> and this is quite a normal usecase, your application is behind some
>> proxy, like httpd. We *want* to run apps with a context in tomcat to
>> be able to have more apps in tomcat (not only ROOT.war), but, we do
>> not want to show the contextpath in the url.
>> Therefor, normally, httpd or something can be used, to add the
>> contextpath! But if you would do so only in httpd, and we would do
>> nothing in the HST2, then all links would contain a context, namely
>> /site for example. But, httpd is handling this context. Therefor, if
>> you configured httpd to include the contextpath, but the contextpath
>> should not be in the url, you set:
>> hst:showcontextpath = false.
>> Your httpd could look something like:
>>  <VirtualHost *:80>
>>   ProxyPreserveHost On
>>   ProxyPass / http://localhost:8080/site/
>>   ProxyPassReverse / http://localhost:8080/site/
>>   ProxyPassReverseCookiePath /site /
>> </VirtualHost>
>> This is quite nice actually: all requests on port 80, we forward to
>> the application with ProxyPreserveHost On. This way, you have one
>> single httpd rule, but can add runtime hosts and subsites in your
>> hst:virtualhosts.
>> Hope this all clarifies things a little. I think this is really one of
>> the nice parts of HST2. For local development, for example on
>> hst:virtualhosts you most likely use hst:showcontextpath =
>> true, but for your production host www.mysite.com, which is behind
>> httpd, you add hst:showcontextpath = false
>> >
>> > Virtual hosts and Jetspeed profilers are really good ideas.
>> >
>> > I will let you know in all cases.
>> >
>> >
>> > On Mon Feb 08,2010 08:09 pm, Ard Schrijvers wrote:
>> >> Your virtualhosts filter defines which 'subsites' there are, and then
>> >> below /preview and /live, there all the possible sites are. I though
>> >> think, the cms interface for the hst :configuration is still based on
>> >> 'single' sites, and is not yet aware of multiple subsites. We still
>> >> need to add this. Though, in the console (/cms/console by default) you
>> >> can configure this in direct jcr nodes.
>> >>
>> >> Sry about the inconvenience, hope this helps you out. If you need more
>> >> help, let me know (ps are you subscribed to the hst dev list? Over
>> >> there I explained today how to configure multiple domains and
>> >> subsites)
>> >>
>> >> Regards Ard
>> >>
>> >> On Mon, Feb 8, 2010 at 7:54 PM, Mansour Al Akeel
>> >> <mansour.alakeel at gmail.com> wrote:
>> >> > Hello All,
>> >> > I am wondering about how to change the docBase in the CMS for the contents
>> >> > to be served. For example in the URL designer, when setting the "Content
>> >> > Path" it always points to the first project.
>> >> > Where can I change this behaviour in the console to point to different "hst:content" ?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Hippo-cms7-user mailing list and forums
>> >> > http://www.onehippo.org/cms7/support/community.html
>> >> >
>> >> _______________________________________________
>> >> Hippo-cms7-user mailing list and forums
>> >> http://www.onehippo.org/cms7/support/community.html
>> > _______________________________________________
>> > Hippo-cms7-user mailing list and forums
>> > http://www.onehippo.org/cms7/support/community.html
>> >
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/community.html
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/community.html

More information about the Hippo-cms7-user mailing list