system administration

An evoke installation consists of a <root> folder containing the following:

• base folder, containing the main system and common files
• one or more application (ie app) folders, containing custom applications

renaming folders

The <root> folder can be named whatever you like! The base folder, and all of its contents, must not be renamed. The app folders can also be renamed, but this may have implications - e.g. any references in base/config_multi.py will have to be changed accordingly.

see installation for installation instructions

several configuration files may be used, containing parameters defined as python variables and classes - they are read in the following order:

1. base/config_base.py - defaults - this file must exist, and should not be tampered with unless you are SURE you know what you are doing
2. base/config_site.py - site-specific overrides to affect all apps
3. <app>/config.py - config overrides for this app only
4. <app>/config_site.py - site-specific overrides for this app only
5. base/config_multi.py - this is only used in multi mode, and contains site-specific overrides to affect all apps, for multi-application serving

where parameters are repeated, each config file will override those before it

site-specific config files are intended for parameters which may vary from one server to the next, eg from a test server to a live server. Where code is stored in a repository (we recommend subversion), these files should be excluded from the repository.

Configuration parameters are listed in base/config_base.py, which gives their default values, and comments as to their usage.

critical parameters

in <app>/config_site.py:

domains=['yourdomain.com','www.yourdomain.com'] : when servicing browser requests, the dispatcher uses the domain name (including the subdomain, if any) to select which app to call (whether or not there are more than one running - i.e. whether we are in multi mode or single mode. Each app must have at least one domain (or subdomain), and each may have multiple domains in the list.

• to serve a single app, cd to the <app>/code folder. For multi-app (a.k.a. "farm") mode, cd to the base folder
• ./start will start evoke in the background
• ./stop will stop a backround evoke
• ./devstart will start evoke in the foreground - this is useful for testing and debugging

From a group page, add a membership(using the pull down list), giving the user id. That user will have a membership record added.

To delete a membership, go to the member's homepage, get the membership listing, and select the membership. Then use the delete button to remove it.

Each application has a style theme associated with it, consisting of a theme.css stylesheet and the set of images referred to by that stylesheet and by the html generated by the base system.

There are a number of preset themes to choose from. To change theme, simply edit the symbolic link htdocs/Resources/theme to point to the theme you require.

A custom theme can be developed for the app, in the htdocs/Resources/custom folder. Copy the images and css you want to use, from another theme, to the images subfolder and theme.css file, and modify it to suit your purposes. Then point htdocs/Resources/theme to the custom folder.

Note - you should use relative symbolic links, not absolute, so that the entire evoke folder structure remains independent of the location of the &lt;root&gt; folder.

Other than custom themes, an evoke app can have the following type of customisation:

1. customisation via the user (ie web) interface, e.g. adding and editing pages, images, members, groups, etc.
2. database customisations: defined in code/config.py
3. code customisations: defined in python class modules in code
4. template customisations: defined in code/evo. These can override base .evo files (if they have the same name), or can add to them (different name).
5. style additions in the htdocs/Resources/ app.css and app.js files, and related images in the htdocs/Resources/images folder. These are intended for styles and javascript routines and images which go beyond the base themes and base generated html, e.g. for code and template customisations.

If email is enabled, (ie configuration item mailfrom has a value), then the subscription feature will, by default, send email alerts to members, when a new article has been posted, or a post they have made has been replied to directly, or the thread they posted in has had another post. In addition, members can manually subscribe to any other post they wish to receive alerts about, and they can unsubscribe from any post they are subscribed to.

In detail this 'subscription' feature works as follows:

• when a post is made:
• every member who is subscribed to the parent of that post will be sent an email alert informing them that the parent article/eposide/reply has had a new response.
• the member who made the post will be auto-subscribed to that post and to its parent post (if she is not already so-subscribed)
• when the 'subscribe' button is used, the member will be subscribed to that page
• when the 'unsubscribe' button is used, the member's subscription for that page will be deleted
• when the 'no subscriptions' button is used, all of that member's subscriptions will be cancelled, and the auto-subscription feature will be disabled. Manual subscription will still be possible.
• when the 'auto subscribe' button is used, the auto-subscrition feature is re-enabled.
• when an email is sent, that subscription is put on hold until the member next visits that page. The result is that there will never be more than one alert for updates to a page, between visits to that page. This avoids members being deluged with emails when they are not visiting the site.

Alerts are also sent, automatically, to the recipient, when a private message is sent. These alerts are not governed by the subscription overrides detailed above.

alerts: technical details

Alerts are stored in the Alerts table. There are three kinds of alert:

• 'autosub' : these are created for posts and groups, for auto subscriptions
• 'sub' : these are created for posts and groups, for manual subscriptions
• 'nosub': these are created for members, to switch off autosubs. Auto-subscription is enabled by deleting these.

Alerts have a stage of 'alert' when created, and are reset to 'alerted' when an email has been sent. When the member next views that page, the stage is reset to 'alert'. Emails are only sent when the stage is 'alert'.