Please note that the module system has now been changed in the following way:

Dependencies and Exclusions are now written in the format “modulefilename”.

This is the name that the file name starts with for the module, e.g. for unix_users.mod.phps the dependency to name would be “unix_users”.

Please note the underscore not hyphen.

This has been changed in all places in web-cp which deal with dependencies. The is_registered and is_enabled functions now expect to receive a file name rather than a module name. If you put “unix-users” as a dependancy then there is no chance of the system recognising that you want unix_users to be installed.

This has been noted on the wiki and forums also.
Please also note that i accidently committed these changes without adding a log note in cvs… i don’t know if its possible to add a log note without changing all those files that were modified. (A few modules referenced unix-users when they need to talk about unix_users since it is the actual name of the module file)

Just to make sure people understand this, the dependencies system does NOT use the Module Name (e.g. ‘Backups’, ‘Apache’, ‘Unix Users’, ‘NSS-MySQL’), for obvious reasons it uses the module part of the filename of the module (e.g. unix_users, nss_mysql, bw_quota) So if you want to list NSS-MySQL as a dependency then you would look at the file name of the NSS-MySQL module, realise it is nss_mysql and then specify “nss_mysql” as the dependency.
EdG

I just committed some significant changes to setup.

The following changes are made:

1. Moved each step in setup_config.php to its own file to make things clearer.
2. Removed unnecessary code
3. Cleaned up case statements
4. Added comments

Each step now has its own file so if you want to change step 1 you simply edit setup_step1.php

This hugely reduces the clutter that was at the bottom of setup_config.php.

However the use of case statements and ? conditionals may still cause problems so there’s lots to work on in the various setup stages.

Also please note that only the part of the step that actually shows it to the user is in setup_step1.php or setup_step2.php etc.
Certain operations are still done at the beginning before any output is provided to the user and these still remain in a switch statement at the top of setup_config.php.

I also removed some redundant code e.g. there is no reason whatsoever for send_header(’Location: http://’.$_SERVER[’SERVER_NAME’].’:’.$cfg[’port’]);
to be in every case statement for every step since it happens exactly the same where it does happen. Simply making sure it only runs when $error contains nothing is all that is necessary.

I will try to better comment the setup process and work out issues as i get time. I would also like to if possible find a way of re-organising the cfg variables because so many of them have names that are not useful and we have previously talked about caching of the config file… perhaps most could be stored in the database e.g. like phpbb and then just retrieved on each page.

I think we may need to start categorising modules since we have so many now. We may also need to work on the dependencies of modules. This would also help setup_config.php since there is a huge amount of dependency code at the modules step.

At some point we also need to go through a lot of things with a fine-tooth comb as they say and try to conform to Gyrbo’s code guidelines - see http://web.archive.org/web/20051119075844/http://www.gyrbo.be/?page_id=2

webcp-httpd uses sockets to receive and respond to requests.

we are currently having some issues with webcp-httpd’s use of sockets whereby socket_accept returns false for no apparent reason. If anyone out there has sockets knowledge please check out the development forum and see if you have an answer.

Perhaps we should contact the origional author of server.inc.phps listed at the top of the file?

Snert recently stopped distributing mod_watch and due to the restrictive license, we are unable to distribute the module on our own so we needed to find an alternative. Given the popularity and stability of Apache 2, we needed to select a module which is Apache 2 compatible. mod_cband has been selected to replace mod_watch as the transfer monitoring and limiting tool for web-cp 0.6. It supports both bandwidth and transfer quotas. mod_cband supports extensive options for limiting or preventing access to websites which have exceeded their transfer quota including reporting only, limiting bandwidth, serving specific pages, redirecting the user, etc allowing the server administrator to select the appropriate action based on their policies. The new module is named mod_cband.mod.phps.