[Zope-CMF] CMF in CMF: my procedure

Gary Poster Gary Poster" <garyposter@earthlink.net
Sat, 16 Feb 2002 12:23:55 -0500


This thread is a little old at this point, but I had tagged it for when I
made a new release...and I made one last night.

The VirtualHostFolder and associated CMFVirtualHost tool specifically sets
out to solve this problem set (among others), and solves a number of the
issues you list below (particularly, and reasonably well, the
skin-preference related one you mention).

Check over
http://www.zope.org/Members/poster/VHF
and
http://www.zope.org/Members/poster/CMFVirtualHostTool

It does not help with separate Membership or Catalog tools--I thought about
going in that direction with the catalog, but just limiting the results
behind the scenes in the main catalog on the basis of the path index seemed
good enough to me.  That also lets the parent site have access in searches
to the sub-portal content...and if you use some of the VirtualHostFolder
per-host Redirect objects, you can have links to content in the subportals
transfer you to the actual subportal domains (the link URL in the search
results will still point to the address from the reference point of the main
portal, but if you click on it you will be redirected).

Some other folks are planning on joining in on development, so I've also
started using SourceForge cvs (https://sourceforge.net/projects/vhf/).  It
looks kind of like a ghost town there now, but if you go into cvs you'll see
we've had a couple of check-ins.  The releases listed above are current with
CVS as of this instant, however.

Gary

From: "Bruno Vernier" <vernier@vc.bc.ca>

> Hello and thank you for the interesting thread on subportals.
>
> I've spent this week studying and struggling with this issue and found a
> solution that works for me, I have posted my notes in
>
> http://zope.org/Members/vernier/Debian/CMF_in_CMF
>
> I needed independent portals (separate learning communities, search
catalogs,
> membership,  etc..)  and still have only one central place to manage the
> skins; and no need to worry about replicating common changes to each
> subportal.
>
> the following procedure works for me with one constraint explained later:
>
> My Procedure for CMF within a CMF:
> ---------------------------------
>
> 1. Make a CMF within a CMF
>
> 2. put a siteroot object in it, update the VHF (Virtual Host Folder),
update
> Apache's directives
>
> 3. remove portal_skins folder entirely (it will acquire skins from the
root CMF)
>
> 4. create a skin for this CMF in the root CMF (let's say Someskin)
>
> 5. in Apache, make all connections to the sub-CMF add the
> following to the URL: ?portal_skin=Someskin and add QSA to the directive's
> flagset Otherwise search results will be wrong; it shows all objects
> regardless of the keyword::
>
> ReWrite *blahblah* *blahblah*?portal_skin=Someskin [P,L,QSA]
>
>  - Otherwise, the default skin of the root CMF takes over (since there is
no
> place to store **portal_skin** attribute in the sub-CMF  *or change the
> personalize method in all skins (see notes above)*
>
>
> There is however one issue:
>
> Issue: **Preferences does not seem to allow skin selection at the
subportal
> level **
>
> either the default skin is the one and only skin  for every subportal or
> we can force a single portal_skin for subportals with the apache directive
> (I imagine that those for whom this is an issue can use one of the other
> techniques discussed in this thread or use a clever site access rule)
>
> when I say, preferences does not allow skin selection, I mean: it seems
> when I choose a different skin, it goes back to either the default except
> strangely for the old Deutsch skin.  I use CMF 1.2 and Zope 2.5 on linux.
>
>
> Bruno
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
>
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
requests