Kevin,
Modules need to be sandboxed and splitted in 2 categories:
1. panel modules that extend core features and use hooks.
2. Apps that will be deployed for all users.
Each must have it's own space/ Way of being plugged.
Also modules should only use the frameworks and obey strick input filtering and ressources use in /modules.
Modules should not use zsudo.
I think priority is extending the core so we add more stable features like: domain aliases/ Auto DNS/ Selective backup ( weekly/daily ). Multi servers functions.
Before we think about extending more modules. Why we would need modules? if we have these? Adding ajax explorer? It's more over a external app that might be configured easily with a script rather than a module.
Then we might look to extend API & billing. WHMCS or other panel managers would love that.
Agree on phpunit very usefull for testing & improving our dev process.
M B
Modules need to be sandboxed and splitted in 2 categories:
1. panel modules that extend core features and use hooks.
2. Apps that will be deployed for all users.
Each must have it's own space/ Way of being plugged.
Also modules should only use the frameworks and obey strick input filtering and ressources use in /modules.
Modules should not use zsudo.
I think priority is extending the core so we add more stable features like: domain aliases/ Auto DNS/ Selective backup ( weekly/daily ). Multi servers functions.
Before we think about extending more modules. Why we would need modules? if we have these? Adding ajax explorer? It's more over a external app that might be configured easily with a script rather than a module.
Then we might look to extend API & billing. WHMCS or other panel managers would love that.
Agree on phpunit very usefull for testing & improving our dev process.
M B
