I need to add several fields to members, like company, address, phone, and other custom fields. But I noticed the field’s selection under Member fields is very poor and limited. You basically have text input, text area, date, a drop-down and URL. Nothing else.
I was expecting to have more fields like toggle, or radio buttons. Not everything in a channel field, but at least something more decent to build a customer profile. I mean, having a radio buttons is not rocket science.
Now, I’m curious if others are actually using member fields for these scenarios. Or should I better create a channel to store users data to have more flexibility when it comes to data?
Any advice would be welcome. I’m just looking for the easiest way to organize data for customer profiles.
There’s the Visitor module that allows you to store member data as regular channel entries (it associates a member with an entry), that gives you the whole suite of fields to play with. https://eeharbor.com/visitor
Yes current member profile fields are limited but I’ve never had too much a problem. For Toggles and Radio buttons use Select fields for setting various values, then if you have front end profile edit fields you can use say Radio buttons on the edit form in place of a Select field.
Thanks, I will give it a shot. I don’t mind buying add-ons, but only if they add specific functionality that is not part of the software.
I find it a bit cumbersome to rely on third party add-ons for basic functionality which should be included in a CMS. In particular, if EE has this specific member custom fields feature build in.
Hi again Rob, do you care to explain more how you are using the native member fields? I don’t actually care how they look inside the control panel as long as I can format them properly in the user side frontend.
Example, I need to put an address, country list, state, checkboxes, radio boxes, etc. Can I still hold all that data in the native member fields and just format them differently (HTML, CSS, JS) in the front end? Or will this be really a problem and I should just go directly with channels?
I’m trying to find the difference. What exactly do I gain if I use channels instead of the native fields? Sure, I can use more fields, but what benefit would that have if I then need to relate the data entries to each user which seems annoying. I decided I will not use any addons for this as I don’t want to make things even more complex and potentially cause other issues with addons that use roles or members. I would rather use native EE functionality.
Let me refrain this a bit. The value you get in the front end is the same, just text regardless if you use an entry field or a custom member field.
So lets assume the Toggle Example or a Dropdown list of countries. If I have the value of “1” in the member custom field, I can still just create the toggle on the front end and set the value to 1 or 0 (assume you do the proper validation in your GUI).
So the only difference I see between using here the channels or the member fields, is that from the EE control panel you would get a nice toggle that does not allow a member to mess up with the data. So basically that field does the validation in the control panel as from the opposite site, using the member field, you could enter any wrong value since its just a text field.
Is this correct? If yes, I don’t mind, because I can just put a description on the field to only use 1 and 0 and I’m the only one editing data.
But here comes my next question. Or does using the channel entry fields also do some data validation on the front end while submitting a change?
Example, if I use the member fields, I can basically submit anything on that value, all the validation to make sure its proper data is on my part, on the submit form before the user will edit the data.
But what happens if I use the channel entry field? And then I try to submit the improper value, for example I submit a word to a Toggle or to the Color picker something that is not a hex value? Will EE them fail to save the data? Or just nothing will be saved?
Because if it’s the last one, then I do see some benefit while using the channel fields vs the member fields, since in the member fields you would be forced to use Text Input for most things.
I understand that most people allow others to log into their control panel to edit data. In that case using the special field designed for that purpose absolutely makes sense, but in my case I’m actually not to allow them to log in, just using EE for my frontend site.
I can’t actually test this right now because I don’t have access to my test installation.
Ok so available member profile fields at the current time are limited to field types Date, Text input, Textarea, URL and Select.
You could use a Select field for a “toggle” for a 0/1 value, but you can also add a label for each value so you might have 0|No and 1|Yes - both value and label can be displayed in front end templates, and the field doesn’t need validation because you only have two possible options.
If you need more advanced stuff like a colour HEX value you could create a member Text field that’s limited to 6 characters, you’d apply the # in your templates wherever this field is used. If someone entered an incorrect HEX code the browser wouldn’t show it and fall back to the default colour. Or you could make the field max 7 characters and rely on the user to add the #.
From what you say will a site admin will be adding and updating member data? Or will users be able to login to the front end to manage their profile?
For what it’s worth I think a lot of us have come across this situation whether to use member fields or the full channel entry approach. For me I’d always tried to predict what might happen in future, if member field needs are likely to increase over time I’d probably opt for the channel entry approach so I know I’d have flexibility for any type of data.
No, users will not be able to log in to the CP to make changes, but yes, they will be able to change the profile details from the custom template pages I create.
I think I will probably use a mixed approach. Use member fields for some basic personal information like address, phone, other and then channels for more complex preferences.
As I keep planning on adding more options in the future it might be messy and unmanageable from the member fields, having a lot of settings in channels will probably make it easier for management from my side vs just having dozens and dozens of basic text inputs.
But I still value in the member custom fields since when you are doing things relating to a specific user it makes sense to have that configuration in the same screen on which you change the password, username, and other user information.
I guess it’s ok for basic stuff but if you need more fields then channels is probably the better approach.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.