Silva
Silva 2.0 Documentation

Getting started

Overview

Silva features

What’s new in Silva 2.0

Log in

Navigation tour

Author – basic

Adding content

Using the Kupu editor

Previewing a document

Submitting for publication

Author – advanced

Adding metadata

Document versioning

Content organization

Importing content

Importing spreadsheet data

Exporting content

Forms editor

Navigation – advanced

Access Keys

WebDAV

Editor

Publishing

Subscription management

Atom and RSS feeds

Chief Editor

Full media export

Roles and permissions

Assigning roles

Groups management

Restricting public access

Addables configuration

Manager

Manager login

Zope Level Management

Adding Users

Subscription configuration

External sources: SQL, CSV, and Code Sources

Groups

Site design and templates

Accessibility Links in Silva

Public API of Silva

Code Source HowTo

Internationalization

File System Storage

location Maintenance Notes for Managers

Silva Docs Index

Search

subscribe envelope

Maintenance Notes for Managers

This document contains information about maintaining a Silva instance. Its target is Zope-level administrators. For information about installing Silva, see INSTALL.txt in the product. Non-maintenance issues are covered in TROUBLESHOOTING.txt.

Triggering publication and expiration 

The Silva application is HTTP based, and doesn’t have a scheduling system to trigger maintenance scripts out-of-the-box, which means that scheduling tasks within Silva is impossible. HTTP applications generally only do anything if there’s an HTTP request, so maintenance tasks are usually run on HTTP requests too. For certain tasks, this can lead to problems, for instance consider the following issue with Silva’s workflow:

When a document is approved and the publication date has passed, the document is not yet published, since this requires an HTTP request to the document to get triggered. In fact the document is published at the first request for it. This means that the status of some documents may not be up-to-date, which for certain bits of functionality (e.g. searching or news) might have incorrect results.

To solve this problem, you can call an external URL from a cron (or similar) application:

http://localhost/silva/status_update

The script behind this URL requires Manager permissions, and will check both the publication date and expiration date for each relevant Silva object, fixing the publication status when appropriate. It’s best to run this script at night or a time of low activity.

Solving version bloat 

Each time a user creates a new version of any VersionedContent object (e.g. Silva Document, Ghost, Link, etc.) a new Version object is created inside that object. This can potentially result in a large number of Version objects getting stored in the ZODB, and since the whole contents of a Version is copied when a new Version is created, this might add up to a substantial amount of disk space used.

Since version 1.2 Silva provides functionality to remove Version objects from VersionedContent, but the user interface is not very useful if you have a large setup and want to get rid of all unused Versions. There is additional functionality to clean up all older versions at once, in the form of an adapter (part of the API, but not directly callable). To trigger this functionality, you have to write a Python script in the Silva root in the ZMI with the following contents:

from Products.Silva.adapters.cleanup import getCleanupVersionsAdapter
root = context.get_root()
adapter = getCleanupVersionsAdapter(root)
adapter.cleanup()
return ‘\n’.join([‘%s: %s’ % items for items in result.items()])

When called (note that it requires Manager permissions) it will traverse the full Silva tree to find versions other than the current editable, approved, published or last closed versions of each VersionedContent object and remove them. Note that if your site is large, this can take a LOT of time to execute.

© Copyright 2002-2007 Infrae.
All rights reserved. mail