As mentioned on the forum, I would like to use webmin's support for "custom fields" to help configure and customize web apps, not just other wmin/vmin scripts, but server-side scripts running in apache and to better allow them to be moved/migrated without having to touch tons of files afterwards.
For this to work, having an option to expose custom fields (env vars) to the apache runtime environment would be useful as it could help to drastically ower required configuration changes.
Alternatively, exposing custom fields via vmin/wmin CLI tools would be another option, because these could then be run via php or other scripting languages to get the configured value of each field.
The idea being to also make the server migration feature aware of custom fields, so that cloning/editing (or migrating) a web app is more straightforward and any custom fields could be presented in a wizard-like fashion during the migration to help customize things, without having to manually edit any scripts
For instance, the "install scripts" feature is useful - but doesn't seem to be aware of custom fields currently ?
I am basically looking for a way to optionally integrate these two features: Because if server migrations were aware of custom fields, they could be used to easily migrate a web app between servers, and custom vmin fields could serve as the "hooks" to easily adjust configuration parameters like mySQL credentials, hardcoded paths or chmod permissions.
Currently, web apps need to be explicitly installed via "install scripts" for this to work - but once it comes to migrations, things are not as straightforward anymore and typically, files like *.php may still need to be edited. Because installer scripts aren't currently designed to explicitly support migrations (backup/restore).
So, instead of hardcoding a path or credentials, I would add a "virtualmin lookup" command to get the corresponding custom field that is specific to the vhost. As long as this is done via environment variables, the corresponding lookup would not be expensive at all, as it would typically just involve a single "getenv()" call.
For example, when I recently moved one web app to another server, I ended up having to grep/sed for all occurences of hardcoded paths and DB access credentials in various php files and replace those. While that was a custom web app, this would not have been any different had it been a script installed via vmin.
So that ended up touching about 30 different files in htdocs. And that would not be any different if I had to migrate again.
So if this could be supported, we would be having another layer of indirection, by not hard-coding app specific stuff, but instead adding a "vmin lookup" command (as in getenv() calls), to delegate the specification of such configuration settings to webmin/virtualmin - which would in turn allow migrations to easily access and change settings later on, without having to be aware of script-specific config files (which would be a real maintenance nightmare).
Thoughts or ideas ?
PS: From a UI standpoint, custom field names should probably be validated (as they need to be all CASE apparently): http://virtualmin.com/node/16433#comment-73149