Configuration

 The configuration helps you define all needed resources and services for all applications and sites at one single file.

File

The configuration file is defined hard coded as a contant in file “workng_boot.php” and is normally located in "/data/.workng.json".

If you are required to change this behaviour you could do so and change the appropriate constant definitions in “workng_boot.php” file.

Be absolutely aware of the fact, that the both given pathes and the configuration file must reside outside of the appropriate “DOCUMENT_ROOT” of the used web server.

Additionally, specially if working with SELinux (enabled), you must allow the used web server to access the used data path.

Settings

The following settings could be set within the configuration file.

Setting “key”

string

The key (hex represented string) for encryption.

Be aware that you must not change this key after setting your application into operation, otherwise different resource are not readable anymore.

If you operate as a cluster, then all participating nodes must have the same key configured.

Setting “auth_rest”

string, enum (”basic”, “digest”), default “basic”

Which authentication method should the REST interface use?

Setting “sess_driver”

string, enum (”files”, “database”), default “files”

This setting defines the type of session handler will be used.

The use of “database” is strongly recommended.

Setting “sess_save_path”

string, default WORKNG_DATAPATH . “.sessions/”

If “sess_driver” is set to “files” this setting represents the full path folder where session files will get stored.

If “sess_driver” is set to “database” this setting represents the table name in which session data will get stored.

Setting “settings_use_php”

bool, default false //NONE

If using PHP-FPM for running the system (specially/or having the settings reside on a NFS share), performance could be raised significant with this setting on true.

When true all settings files are are on demand (as before) but then exported to PHP source files which then are included into the system having PHP-FPM let them stay in its OP Cache.

Setting “output_cache”

string, enum ("", ”file”), default “” //NONE

With this settings the type of output cache is set, if there should be one.

Setting “cache_path”

string, default “”

If “output_cache” is set to “file” this setting represents the full path folder where cache files will get stored.

Setting “access_logs”

bool, default false

This setting enables the access logs. While the underlying web server certainly has its own access logs specially if in an cluster environment it is a good things to have all logs in one place.

Enabling this settings stores the access logs within die Key Value Store.

It is not recommended to use this settings if Matomo is used at the same time.

Setting “change_logs”

bool, default false

This setting enables the change logs. Every database change will then get logged into a special collection to have always a history of all changes on all resource.

Be aware that this settings will nearly double your needed database volume and transfer.

Setting “matomo_url”

string, default “”

If Matomo should be used this is the URL of the Matomo server.

Setting “matomo_key”

string, default “”

If Matomo should be used this is the key for the Matomo server.

Setting “udger_key”

string, default “”

If Matomo is not used but the access logs, using udger would enrich your access logs with appropriate user agent data.

Setting “ipinfodb_key”

string, default “”

If Matomo is not used but the access logs, using IPInfoDB would enrich your access logs with appropriate ip address data.

Section “map”

map(string => object), optional

See concept “Site Tag”.

Section “db”

map(string => object)

Within this section the database to use for the current “Site Tag” will be defined.

{
	"db": {
		"default": {
			"username": "database_user",
			"password": "database_password",
			"database": "database_name"
		}
	}
}

Section “mongo_db”

map(string => object)

Within this section the Mongo database to use for the current “Site Tag” will be defined.

{
	"mongo_db": {
		"default": {
			"username": "database_user",
			"password": "database_password",
			"database": "database_name"
		}
	}
}

Section “auth”

map(string => object)

Within this section the authentication method to use for the current “Site Tag” will be defined.

See “Authentication”.

Section “mail”

map(string => object)

Within this section the mail settings to use for the current “Site Tag” will be defined.

See “Email Class from CodeIgniter”.

{
	"mail": {
		"default": {
			"from": "jane.doe@example.com",
			"from_name": "Jane Doe"
		}
	}
}

Section “stomp”

map(string => object)

Within this section the STOMP settings to use for the current “Site Tag” will be defined.

{
	"stomp": {
		"default": {
			"username": "stomp_user",
			"password": "stomp_password"
		}
	}
}

Section “routes”

map(string => object)

Within this section special routes to use for the current “Site Tag” will be defined.

See “Routing Topic from CodeIgniter”.

{
	"routes": {
		"default": {
			"blog": "frontend/blog",
			"blog/feed.xml": "frontend/blog/feed",
			"blog/([^/]+)/(.+)": "frontend/blog/show/$2",
			"blog/(.+)": "frontend/blog/show/$1",
			"contact": "frontend/my_issues/contact"
		}
	}
}

Section “sites”

map(string => object)

This section defines which Application Definition to use for the current “Site Tag” and “Selector Path” (e.g. “frontend”).

The system tries to find an Application Definition in the following order:

The following example uses Application Definition “site1” of all requests except for “Site Tag” “site2”.

{
	"sites": {
		"default": "@site1",
		"site2": "@site2"
	}
}

The Application Definition could be assigned directly as an object (which is not recommended) or as a file to load with the “@” operator. So the above given example would load file “site1.json” as the Application Definition for the "default" site.