Implement a new site configuration approach

[cpeel]

To configure the DProofreaders code, right now one edits a shell script -- an example of which is in ./SETUP/configuration.sh -- and then runs the ./SETUP/configure script. That script searches the code for files ending in .template which contain variable placholders. It then creates new files without the .template extension with the values filled in. We used to have many .template files but now we have just these:

./pinc/udb_user.php.template
./pinc/site_vars.php.template
./SETUP/check_db_schema.template
./SETUP/dp.cron.template
./SETUP/dump_db_schema.template

You'll note that they are a combination of PHP scripts and shell scripts.

This approach has its pros and cons. For instance, on TEST we have a single configuration file that all developers can use for their sandbox and the shell script determines the right paths based on the user.

A downside is that it makes upgrades harder as one must inspect the new ./SETUP/configuration.sh files for any new (or deleted) variables and manually update the system copy. Trying to use code with a new config variable that isn't in the old site will very likely result in errors because there is no way of setting up default values for them. The SETUP/import_old_configuration.php attempts to assist with the upgrade but it's a rough hack.

Another downside is that it means that it isn't dynamically extensible. Because we can't provide defaults we can't add new overrides easily. On TEST we'd like to decrease the number of pages which makes a user a "new" user but that value is hard-coded. We could make it a variable but that then requires us to add it to the configuration file and then becomes an upgrade issue. If we could set it to be a default value in the code and override it just for TEST that would solve that problem.

Other PHP projects have solved this problem, and we can too. MediaWiki, for instance, introduces new config variables all the time and you just need to set/override them in LocalSettings.php. One could also imagine having a configuration class that would load a PHP-based configuration file for settings and callers would ask that class for config values (bonus: fewer global variables!).

Something to keep in mind is that we do not want to introduce a new file read on every page load. That is: if we have a new non-PHP configuration file that some script has to load and parse that's probably not good. If it's a PHP file it will get parsed and loaded into the in-memory opcache which would make it fast. I think phpBB does something clever by creating PHP files dynamically in a cache to get the opcache benefit.