WebCalendar is a PHP application used to maintain a calendar for a single user or an intranet group of users. It can also be configured as an event calendar.
This is modeled after the way the system currently allows external apps to supply users. The developer would place a plugin "bridge" script config-app-myapp.php in the includes directory. That file would contain a single function do_external_configs which takes the settings array, and returns a new settings array. Then the sysadmin would add config_inc: config-app-myapp.php in settings.php.
My personal use case for this is to improve security. It's best practice to keep sensitive configuration options like the database username and password out of the webroot, regardless of file extension. However, rather than drastically changing how webcal handles configs and breaking everyone's installs, this makes the change "opt in". It also allows developers to get those config options in the way that makes the most sense for their situation, rather than being constrained to the "one true way". Whether someone wants to use environment variables, config file elsewhere on the system, pull configs directly from the main application, use a more sophisticated key store program, etc...
This should all be documented somewhere too, though I'm not sure exactly the right place for the documentation.
This is modeled after the way the system currently allows external apps to supply users. The developer would place a plugin "bridge" script
config-app-myapp.php
in the includes directory. That file would contain a single functiondo_external_configs
which takes the settings array, and returns a new settings array. Then the sysadmin would addconfig_inc: config-app-myapp.php
in settings.php.My personal use case for this is to improve security. It's best practice to keep sensitive configuration options like the database username and password out of the webroot, regardless of file extension. However, rather than drastically changing how webcal handles configs and breaking everyone's installs, this makes the change "opt in". It also allows developers to get those config options in the way that makes the most sense for their situation, rather than being constrained to the "one true way". Whether someone wants to use environment variables, config file elsewhere on the system, pull configs directly from the main application, use a more sophisticated key store program, etc...
This should all be documented somewhere too, though I'm not sure exactly the right place for the documentation.