Hi Duncan,
This is a great description of PloneMultisite. I was surprised to not
find PloneMultisite in the plone.org/products area. Any chance you could
post it there and include your description of what it does? Screenshots
are very helpful too!
I'm sure there are many others who could benefit from this product, but
if it's not on plone.org, the chances of them finding it are very slim.
I really like the way O'Reilly's CodeZoo (http://python.codezoo.com)
organizes products, and I think we could learn a lot from them on how to
structure the plone.org/products area. You can assign tags, tips and
rating to each to product/component.
Here is the entry for Plone (still showing a release of 2.1.0b1)
http://python.codezoo.com/pub/component/3608?category=200
I'd really like to get Alec Mitchell's contentratings product installed
on plone.org, so that we could start using it to rate Products.
http://plone.org/products/contentratings
Nate
Duncan Booth wrote:
Shaun Hills wrote:
I missed Ploneability, but I noticed there was some discussion around
Plone MultiSite. Having had a bit of a look at the code and docs (ahem
;) it seems like it's a product for pushing content from a central
"editing" instance out to multiple other Plone sites. Is this a fair
summary? Is there anything else it does that I'm missing?
Yes, that's a fair summary. There is a single Plone site where content is
editable (the CMS) and one or more public sites.
Any content object in the CMS can be subscribed to one or more sites. When
you workflow the object in the CMS the multisite tool can perform one of
three actions for each subscribed site depending on the workflow
transition. The actions are to copy the object onto the site and workflow
it, delete any existing copy from the site, or simply workflow any existing
copy on the site.
The key to using Multisite is therefore to set up appropriate workflows for
both CMS and sites (although site workflows are likely to be one or maybe
two states at most). We have a setup where the CMS fans out to several
sites each with its own skin, but you could also use it for a more
traditional staging setup where different workflow states correspond to
private, on staging, or live.
We make published content uneditable in the CMS, and if somethings needs
updating the workflow lets the user choose between retracting the content
or simply making it editable again while leaving the previous version on
the site.
Some content types (in our case images, files and external links) can be
marked as dependent objects. We don't expect users to workflow any of these
directly, instead workflowing a document which uses any of these will
attempt to apply the same workflow transition to dependent content, but
only in the forward direction (so images could go from private to visible
to pending to published, but are never retracted automatically).
Multisite also has a preview option which will render the page as though it
were published on the site.
One of Oxfam's requirements was that the structure of the CMS and the site
need not be the same. For example the CMS is arranged by team, and a site
might be arranged by country with different teams contributing to each area
of the site. For this reason folders are handled differently than other
content allowing content from many CMS folders to map into a single folder
on the site.
I have a reason for asking. We at NHS CFH run a fairly large but
ultimately quite bog-standard Plone site. And we're starting to hit
two limitations of Plone's out-of-the-box publishing model. Firstly
content is all "up front" on your site, and live the minute the owner
hits "save". Risky. So we made a minor customisation to default all
new content to "Private"; at least then if it's WIP it can't be found
by users. But this has an unfortunate side-effect when users forget to
publish their content - they'll create a hyperlink to it which will
work just fine when they're logged in. But as soon as an anonymous
user hits the link, they're prompted for a login.
We don't actually stop content being published when it links to unpublished
content (because that way you could never publish content which has
reference loops), but there are various things in multisite which help
prevent this being too much of a problem.
If you just have a link in body text, then on the site you get a broken
link. Since the target content doesn't exist at all on the site, you don't
get a login, just a 404 error. All of the body text links are handled using
Kupu's transform (so they are stored as uids but the end user never sees
the uid). A very minor change to the transform could do something useful
with broken links (such as unlinking them), but that isn't really
satisfactory if the link text is something like 'here' or 'link', so I
never bothered to actually do it.
If the links are generated using an archetypes reference field then the
reference simply won't exist on the public copy. References are
automatically reinstated if you later publish the targetted content. This
means you can easily refer to content which you intend to publish later and
the 'related link' field will become populated only when the link is valid.
Our site structure mostly uses composite pages (CompositePack). When
composite content is missing, the slot is replaced with an error message
and on the public sites the CSS makes the error message invisible. Again
this means you can either delay making content visible in a page, or remove
part of a page without affecting the remainder.
I think we need to get away from the current system and put in some
kind of staging or editing --> production propagation mechanism. Is
this the kind of problem MultiSite is intended to solve? Or should I
be looking at one of the other staging frameworks?
I'll be very happy to talk to you further about this. Give me a call (01865
473454).
_______________________________________________
NGO mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/ngo
