Thread

EE supports custom member fields, but are limited to text fields and dropdowns.

You could hack the core to enable checkboxes, but that’s just nasty.

Solspace’s User makes accessing custom member fields a bit easier, but supporting custom fieldtypes is still a problem.

You could also link member data using channels. With the addition of Safecracker, it seems like using channels + Safecracker for custom member data is the no-brainer solution.

There’s various schools of thought on this, so please share yours!

It seems to me the most graceful solution would be to create a “Members” channel, with each member as the author of an entry containing their custom member fields data. Unlimited custom fields for member data could easily be added and selectively manipulated from the frontend with Safecracker.

What do you think?

I’ve always gone the dedicated channel route without running into many issues myself.

I know a ton of people really like Solspace’s User module though as well.

It seems to me the most graceful solution would be to create a “Members” channel, with each member as the author of an entry containing their custom member fields data.

Yes, I think the best solution is to use a member channel for member custom fields. However, there would be cases where I wouldn’t want to use the author to link the member to the entry. In those cases, I’d prefer a custom field type that is populated with all members and I could select one. Maybe the custom field type could disable itself once a member was selected.

I think the “channel_entries_query_result” hook could be used in an extension to add non-custom member data before channel entries tags are processed. That way, all member data could be available in channel entries tags without the use of a plugin.

Ideally though, members would be channel entries in the core. I’ve submitted a feature request.