Server Modules need a Mature and Flexible solution for creating custom fields
The current implementation of server modules is fairly simplistic -- the approach is almost startling considering it's used in an application that handles not only payments and invoices, but people's servers.
Here are the top improvements that would fix a lot of problems that have resulted in various related feature requests.
1. Server Modules should be a PHP class, extending an abstract PHP class and implementing a defined interface. There should be included in the class a dedicated interface for querying a customer's details and updated a customer's data.
2. The field generation needs to support customizable key/value pairs every place it occurs (not just ad hoc stuff in the "Custom Fields" tab.
3. Any and all html characters must be allowed: separating field options on a comma is a juvenile and ineffective way of entering dropdown options when you're defining a form in PHP. Use an array.
4. Server Modules should parse PHP for every custom field: it's an awkward distinction to have "Module Settings", "Custom Fields", and "Configurable Options", when they all more or less do the same thing. You're setting up your developers for massive confusion, and... seque to next point
5. You've got to document your customizations. If it's not in black-and-white on your docs page you're wasting the time of your customers and your tech support because they get tickets filed asking them how to do stuff that should be in your public docs from the beginning.
6. The ConfigOptions fields must define a unique id: if you add a new field to that area of your module, you currently risk corrupting your data since the data is stored sequentially as configoption1, configoption2, etc. Adding fields to our view should not run the risk of corrupting our model.