The example script logs in as an admin and creates a user with random credentials and settings. It logs in as that user and posts and validates random content. It stores user settings preferences (e.g. preference for WYSIWYG) in the script DB. It validates that the application honours those settings.

Install Serendipity

This worked on Fedora 20. I’ve cloned the github repository up to commit e12b998bf7 into /var/www/html/serendipity (git clone https://github.com/s9y/Serendipity.git). Install Serendipity as per its documentation.

The easiest way is using Serendipity with SQLite. If you choose SQLite and you don’t provide any db-related fields, the installer creates a .db file under webroot (e.g. serendipity_a2a42d7580267f6dcf1a3fd779040498.db) and puts that filename (excluding .db extension) in field dbName in serendipity_config_local.inc.php. The default dbPrefix is serendipity_.

Install SeLite Serendipity framework

Apply InstallFramework. The framework and scripts are in serendipity folder.

Scope

The framework tries not to rely on

Maintaining the framework

The framework honours Serendipity settings (global and user-specific - stored in serendipity_config). @TODO: Make it update the script DB to reflect change of settings. Check whether the config pages can be customised via templates or not.

Boolean fields

Serendipity uses string literals 'true' and 'false' for some fields which have SQLite column type boolean (e.g. allow_comments and moderate_comments in serendipity_entries. However, do not use Javascript boolean literals true or false: see SQLiteSpecifics > No literals true and false.

webRoot

The framework doesn’t use SeLite Settings configuration field extensions.selite-settings.common.webRoot (and it removes this field). It uses Serendipity field ‘URL to blog’ stored in serendipity_config with name='defaultBaseURL', as well as configuration for name='serendipityPath' and name='indexFile'.

multihosting

The framework doesn’t autodetect the paths based on HTTP host (it would be complicated, because it would also need to pick a script DB relevant to the host etc.). If you’d like the script to work with auto-detected multiple hosts, probably the easiest way is to have one suite per host. Have the suites in separate folders and associate each folder with a separate Settings configuration via SettingsManifests. Those suites can share same cases. Alternatively, have the same suites symlinked from multiple directories (at the same depth), but each folder having a separate configuration.