Documentation TOC » Features » System Configuration

System configuration

Introduced in Tiki8

System configuration allows for system administrators to change some preferences from outside Tiki. By providing an INI file, administrators can have a central configuration for all of their Tiki installations.

Possible uses for Tiki Farms and hosting companies

Connect to other services, such as BigBlueButton, without intervention from the users
Configure advanced settings such as Memcache
Disable features that are not part of the support plan
Respond to security advisories by globally disabling a feature
provide tiki_p_admin but make some features inaccessible
Hosting company may want to offer all-in-one hosting, but restrict usage of
- experimental features
- feature that can be used to gain server access (which is OK for most setups, but not cool for a WikiFarm)
Consulting company wants to make simpler admin panels for a customer
Using Tiki as an application builder (framework)

Activate the system configuration

The system configuration must be enabled from the db/local.php file. Installations created from Tiki8 and beyond contain samples in the file created by default.

Sample configuration in db/local.php

$system_configuration_file = '/etc/tiki.ini';
$system_configuration_identifier = 'client1.example.com';

When enabled, Tiki will read additional directives from the configuration file based on the selected identifier. The identifier is arbitrary, but can be used either to specify the site or the plan. In the configuration file, multiple configurations can be defined and inheritance can be used.

INI configuration file

Sample INI file

[global]
preference.feature_wysiwyg = "n"
preference.feature_sefurl = "y"
preference.helpurl = "http://support.example.com/"
; ... more settings ...

[basic : global]
preference.feature_wiki = "y"
preference.feature_forums = "n"
preference.feature_trackers = "n"
; ... more settings ...

[pro : global]
preference.feature_wiki = "y"
; BBB configured, but user can still toggle on/off
preference.bigbluebutton_server_location = "bbb.example.com"
preference.bigbluebutton_server_salt = "1234abcd1234abcd"
; ... more settings ...

[client1.example.com : pro]
preference.browsertitle = "Client #1 Intranet"
preference.sender_email = client1@example.com

In the example above, the following preferences would be set for using the identifier client1.example.com:

feature_wysiwyg = n
feature_sefurl = y
helpurl = http://support.example.com/
feature_wiki = y
bigbluebutton_server_location = bbb.example.com
bigbluebutton_server_salt = 1234abcd1234abcd
browsertitle = Client #1 Intranet
sender_email = client1 at example.com

Disable classes of preferences

Preferences can be disabled by setting a value to each of them individually. However, this process may be long and will require maintenance with the evolutions of Tiki.

Tiki allows to set multiple rule priorities, each verification priority can allow or deny a preference. Rules can be specified at various levels, just like the preference overrides above.

Various rules

[global]
rules.0 = deny experimental new

[pro : global]
rules.5 = allow new
rules.10 = allow feature_wysiwyg

In the previous example, sites using the pro identifier would be allowed to use new features and wysiwyg (which is tagged as experimental), including new experimental features, but still be denied old experimental features. Higher priorities are evaluated first and the lookup stops once there is a match.

A draconian provider could use something like this:

Draconian provider configuration

[global]
rules.0 = deny all
rules.1 = allow basic

The preferences need to be tagged in the definitions using the 'tags' key containing an array. Unless specified otherwise, all preferences are considered 'advanced'.