I'm working on a couple of local plug-ins for the OU which have user preferences associated with them. Rather than have user controls scattered throughout the interface, I've been asked to put them all in the main user profile. Arguably these controls should be at the point of use instead/as well - but that's a different debate.

At the moment I'm creating the new profile fields by getting the plug-in database update &/or after install scripts include the custom profile category & field definitions. This is because I don't want to just use the manual admin screens for custom profile setup. Some of these plug-ins will be shared and I don't want them to go out with a long list of manual config changes.

Ideally, an extra settings script would allow the developer to define categories and/or fields in code. These categories and fields would be saved into the existing custom profile category and field infrastructure so that the display and data saving routines already in place for custom profile fields can be leveraged.

An extra database column on the custom profile category and field definition tables will be required. This will be a boolean flag to indicate whether the row has been set up manually or through a plug-in hook. Where categories and fields have been set up manually, they can be edited through the existing admin interface. However, those which have been set up through the plug-in hook should only be editable through that hook.

This needs more thought e.g. how will updates be identified on upgrade? Whats the difference between editing an existing field and deleting old & adding new field? Perhaps the boolean flag described should be a version number which can be tested on upgrade? Or will aboolean be adequate and "spot the difference" with the existing definitions? Any update mustn't drop any existing data in the field - changing an existing field's type or the uniqueness property from no to yes should cause a developer debug error. Changing uniqueness from yes to no is acceptable since this does not cause data loss.

I realise this is quite a big thing to suggest. Comments very welcome!