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
