Hello Julian,

Currently the each custom field is unique to a profile type because you can have various different settings within the custom field itself. This is what empowers the custom fields and is extremely flexible for customization

I agree, and I would appriciate if we also could create "sitewide custom fields".

An example for you:
When I would create a community for dog-owners, it would make sense to create a field for the "breed of your dog".
When I have one profile-type called "Dog-owner" and another profile-type called "Dog-trainer", when one of the persons switch, the dog keeps the same breed.
Also I don´t want to create the field "breed" in every profile-type. Even when I add more profile-types later (Dog-Therapist, Dog-Lover,...), then all need the breed-field.

This is just one example. It would be nice to be able to mark a custom-field as "sitewide" and then to have it in all profiles.

Back to my original question:
What happens to the data if I change the profile-type? Is it deleted or just "inactive"?

All the best, Julian!

Hello Julian,

The usability here will get out of hand and you will be confused in the future as to which fields are site wide and which doesn't. Managing this would be extremely painful and tedious

Hi Mark,

imagine a programming-community with the following types of users:

- consumer
- student
- hobby coder
- professonal coder

Now I create a custom field called "main programming language" as a multiple checkbox with the following options

- Java
- HTML/PHP
- Virtual Basic
- Pascal
- ???

I would have to create that one field three times (for student, hobby-coder and professional coder). They would have to be the same for all three. When I create a new profile-type in future, I will have to create all custom-fields for the new profile-type. When I switch a user to another profile-type, I will have to somehow "connect" the custom fields, so the data will be kept during the switch. I imagine this as extremly painful.

Now try to imagine a new section in the backend of EasySocial called "custom-fields".
Imagine the workflow: I can create the custom field there and turn it off and on for the different profile-types.
Meaning: The custom field ONLY shows up in the profile if it is turned on for the profile-type.
But I don´t have to create it for every profile-type, I can simply turn it off and on. While all profile-types use the same custom field, just with a "turned off" and "turned on"-state, it would be easy to keep the data saved, even if switching profile-types.

Can you imagine this as easy usable?

Please don´t get me wrong: I don´t want to critizise EasySocial.
I only try to mark out a point that I think can get very difficult in future. I totally agree that custom fields should be profile-type-specific. And I also totally agree that they should be easy to manage. I just think, the way it goes in the moment will be a pain to manage for every custom-field, that has to be site-wide. So I try to find and Idea, that works out the best way I can imagine. ;-)

All the best, Julian!

Hello Julian,

In a way what you said actually makes sense but what if you want a different field that works similarly but have different behaviors? Then you are actually restricting yourself with this global fields implementation

Hi Mark,

In a way what you said actually makes sense but what if you want a different field that works similarly but have different behaviors?

Very easy: The same way as it is now.
I don´t mean to restrict the recent way, I mean to extend it to "global".

Imagine it like that:

- The whole custom-fields-process keeps the same as it is now. You can create a custom field inside of the profile-type, and this custom field will ONLY be shown in the profile-type where it was created in.

- There is a new section in the backed called "custom fields". All custom fields are shown there. And I can activate every custom fields also for different profile-types.

This means:
I can handele a custom field only for a profile-type. But when I need to extend it, I simply go to the custom-fields-section and activate this custom-field for other profile-types or for "all" profile types.

Your szenario is easy: The process keeps exactly the same as it is now.
When a custom field is created inside of a profile-type, it should be active only for the profile-type it was created in.
But in the general custom-fields-section it also shows up and can be extendet to other profile types.

Do you undetstand what I mean?
My english is not too good, so I apologize if it sounds too weired.

All the best, J ulian!

Thanks for the heads up on this Julien, appreciate your insights on this but to be honest, I think this method would be even more confusing because you end up having to have 2 different ways to assign custom fields into a profile.

Anyway, we actually have some plans to improvise on the custom fields for EasySocial in the future versions of EasySocial

Hi Mark,

well ... the essential thing is, that custom fields need to be created for the whole site. In profile-types as well as in events.
As long as you find a solution for that, I totally agree. I just wanted to help you in brainstoarming how this could be done.

Please keep in mind:
The need of creating a custom-field multiple times because it can´t be created generally and in the same moment loosing data when switching profile-types or categorys for my opinion is a huge step backwards. You gain a little bit more flexibility, but tons of work for the admin.

All the best, Julian!

Thanks Julian, don't worry when the time is right, we'll get you into our "brainstorming session"

Okay, so I will be quiet about that one for now.
Makes no sense to repeat it after you heard it.

And ... I am longing for you to answer the other thread about the dashboard-settings.
I want to get EasySocial live as soon as possible, ant the other questions are much more essential for me.

All the best, Julian!

Noted, thanks for the heads up on this

I ran into this problem myself now.

To be precisly: I want to have 2 profiletypes. One for free members, one for paying members. That way I can set the ACL per profiletype. The custom fields however, should remain the same!

Payplans has an app to switch profiletype after payment. Nice, but totaly useless if the member has to fill in ALL his properties again after becoming a paying member. It would be a punishment for the member to become a gold member that way.

When viewing the voices of easysocial, one of the best voted voice is: Paid Membership & Free Memberships
http://stackideas.com/voices/easysocial/item/98

I Dont think there will be some sort of Payplans integrated into jomsocial core. That would be way to much for the developers and is not needed, cause of the fact that payplans can handle this nicely. I would love to have it integrated as that voice describes, but i rather would have the devolpers spend their time on making easysocial even better then it is already.

However, when it is possible to have sitewide custom fields, like described by Julian in this topic, the most wanted 'voice' has been implemented!! Ok, not as in integrated payment ways andso on, but it is simple to achieve then with the combination of JPayPlans.

Hello Cbais,

If you actually use the same field keys for each of the profile fields, "Payplans" could actually use our API to migrate the user to the "paid profile" and carrying those custom fields across too.

If you actually use the same field keys for each of the profile fields, "Payplans" could actually use our API to migrate the user to the "paid profile" and carrying those custom fields across too.

Could????

I actually use jPayplans and EasySocial and I would expect, that if a user inserts data, it will be kept even if he changes his profile-type.
jPayplans has an App to do so. What happens, if the app changes the Profile-Type?

As I said before: I see only very limited sense in having custom profile-fields changed for every profile-type. But I see definitely no sense in using custom fields, if all data will be lost on an ongoing basis, as soon as a website is working with different profile types.

To be clear: I see that the "custom user-data" belongs to the user, not to the profile-type. And I don´t understand why data needs to be "migrated" when it is not changed. Can you please give a clear statement about the custom user-fields? Will the data be stable when working with different profile types, no matter how the profile-type is changed?

All the best, Julian!

Hello Julian,

User fields are tied to profile types. You are looking / expecting the custom fields to work your way where all profile types uses the same custom fields but some other sites wants different profile types to have different fields altogether. For instance, if you are building a site which revolves around a school, are you going to ask your students the number of years they have serviced in their school?

The "data" stored within #__social_fields_data contains the relationship between the data which the user enters and the profile type's id. You cannot link the data to a custom field id because the custom field might be used differently on different profile types.

The easysocial Payplans app does nothing more or less, then change the profiletype after payment.
It does not copy fields or so.

However, if i use the same field key for multiple profiletype, it could work?

for example: I have 2 profiletypes, which I want to be the same. I put a custom field in profile type A (for example: hair color).

then I go to profiletype 2 and add a custom field there, with exactly the same name (hair color) and exactly te same field key, and then the property will not be lost when the profiletype has changed? And will this not conflict internally in Joomla?

User fields are tied to profile types. You are looking / expecting the custom fields to work your way where all profile types uses the same custom fields but some other sites wants different profile types to have different fields altogether. For instance, if you are building a site which revolves around a school, are you going to ask your students the number of years they have serviced in their school?

I only expect some integrity in the data.
Let´s take your school-example. There are many custom-fields that are neccecary for teachers as well as for students:

-> Birthdate
-> Zodiac
-> Hometown
-> Personal Interests
-> (...)

And there are some fileds that only are usefull by one of the profile-types:

-> Fields of teaching
-> Degrees
-> (...)

By destroying the direct connection between a user and a custom-field, the data uses stability. What happens if a student grows up and gets a teacher? It seems like you expect that most profile-types are "lifetime". As profile-types are often used for payment-systems and for access-stuff I see a demand in keeping the data intact.

Another easy example:
Imagine a Usergroup for moderators. Whenever you announce somebody to a moderator, all of his data will be earsed? That makes no sense to me. Take an flirting-comunity with the profile-types "male", "female" and "couple". Whenever somebody starts a relationship, does that mean is earlier data is invalid? Does his personal interest change because he is in a couple now?

However, all of this stuff is simply solved if custom fields could be hidden for profile-types. This way, all data will be intact, nothing is lost, and there is no need to migrate anything if somebody changes his profile-type. Wo what is the benefit of creating lots of single custom-fields for every single profile-type compared with the simple solution of hiding userfields in the affected profile-type?

All in all, you also haven´t answered the main question yet:
What happens if the jPayplans-App changes the usertype? Will the data of a custom filed be consistent or will it be lost?

All the best, Julian!

with exactly the same name (hair color)

I love this example: Hair Color.
However the profile-type changes, the hair color will stay the same.

then I go to profiletype 2 and add a custom field there, with exactly the same name (hair color) and exactly te same field key, and then the property will not be lost when the profiletype has changed? And will this not conflict internally in Joomla?

Keep in mind how much work this will be.
If you build up 10 custom fields (which is very few for my opinion), you will have to create every single field of them again for the other profile-type. Now think about what happens if you have 50 custom fields and 10 different payment-plans ... you will have to create 500 custom fields and make sure that all field-keys match.

A terrible lot of work ... and what is the benefit?

All the best, Julian!

Hello cbais,

Yes, but Payplans would need to add the code to switch a user's profile rather than hacking it themselves. All the logics are clearly defined in /administrator/components/com_easysocial/controllers/users.php under the method "switchProfile"

Julian,

What you are saying does not make any sense at all? What do you mean that a student grows up and get's a teacher? By then, they would need to request the admin to update their profile when they becomes a teacher and since the data is not there, they need to fill it in.

Regarding the payplans app, please see my reply above to cbais.

I am aware of the work.

I also think that there must be a much easier way. the school example of Yours is exactly what I mean.

Why indeed not make 1 profiletype hidden, which applies to all profiletypes. Or give every custom field 1 extra option: bound to profiletype OR bound to all profiletypes. (and the latter will let it show up on all profiletypes)

I see some sollutions for this problem. I agree that most of us (including me) wants to use this system for a paying system. Upgrade profiletype after payment. Payplans can handle this already. However, the profiletypes of easysocial cannot do this without enormous amount of work......
I am going to do it, make all fields double with the same key, but is is not an ideal situation. What if I decide to expand and make an extra paying option. Lets say, Free, Gold, Super Gold. Then I will have to create a new profiletype and indeed insert ALL custom fields again and no mistakes may be done. etc etc

Do a search on this forum. A lot of people are asking for membership systems, payment sollutions and so on. It is even the higest rated voice for easysocial!

If only this simple feature would be added to the profiletypes, the membership system can already work. You only need payplans then to do so and of You go! A lot of easysocial users would be very happy I think...

Yes, but Payplans would need to add the code to switch a user's profile rather than hacking it themselves.

Recently I am using jPayplans and different profile-types that are changed after payment.
Is the user-data allways deleted after a user signs to a paid membership? This would be a horror! I have no clue how it is working, I am not a coder. But I definitely expect that user-data is staying intact.

Stackides as well as Readybytes are two of the big players in terms of Joomla-Extensions. This are not simple codet plugins by a 17 year old teen. I would expect that here is some stability.

Let´s face it from the other point of view:
There are DEFINITELY some facts that need to be stored for ALL Users. STuff like Hair-Color for example.
If the "custom user-fields" of Easysocial is not able to handele that, then this is a missing feature.

Let´s face it clearly:
Custom fields for Profile-Types are working.
But Custom fields for USERs are not working right now.

I don´t need custom fields for profile-types. But it´s okay if they are in.
What I definitely see as a basic-feature for a community-software is custom fields for users.
And this is a feature that is not handeled by Easysocial right now.

All the best, Julian!

Mark,

Thanks for Your Answer.....

What Julian probably means, and what I also mean, is that a lot of custom fields are valid for all the profiletypes. We want a system that profiletypes can be changed during membership. No matter what reason. Some people like me, want it to give paying members more access, or give them more MB's or more amount of photo uploads and so on....

However, the key is: there are ALWAYS custom fields, which apply for all users.

Put it another way. I run a community for hobbyspotters. People who enjoy taking pictures of transport vehicles.

Lets say, there are 2 profiletypes. One for people who only watch the pictures of others and react (profiletype 'viewer'). The other one is for people who also actually make photos and post them (profiletype 'photomaker')...

Lets say I am 'viewer'. Now I bought a decent photocamera and I want to become a 'photomaker'. I want to go to the other profiletype.

My haircolor did not change, my favorite airplane did not change and so are a lot of properties on my profile that did not change. the only propertie (custom field) that a photomaker has extra, compared to the 'viewer', is a custom field in which he or she can tell which photocamera he has.....

this is just an example, but in this example, the member has to fill out ALL properties again, when switching profile type, OR the administrator has to create 2 almost identical profiletypes and be aware of the same fieldkeys for almost all the custom field except 1.

Maybe this example explains it better...

Hi think we might have an intersting missunderstanding in this thread
The "custom fields for profile-types" fullfill some needs, but not the needs of "regular custom fields".
The c ustom fields can also be seen as two total different features:

-> Custom fields for profile-types
-> Custom fields for users

From my point of view, the feature "custom field for users" is not really integrated in EasySocial, so I created a Voice for this feature.
Maybe it works better, to handele it as the request for a "new feature" instead of trying to change the existing one.

So if you also need global custom fields that are directyl connected to the user instead of to the profile-type, please vote for this one:
http://stackideas.com/voices/easysocial/item/581

All the best, Julian!

Well...I am considering Easysocial, to replace jomsocial. I really love easysocial. Love the support, love the devotion of the team to the project. I really believe easysocial to be the way to go for me. However, it must be workable. I have 3 communitysites. All with the same setup, only different target users. All 3 have the same setup with 2 types of membership. Free members and gold members. Gold members can do just a bit more then free members.

Think of a photoupload limit (free members have a maximum of 10 photos. Gold members have a maximum of 5000 photos). Think of maximum amount of friend request a day (free members can do maximum 1 a day. Gold members maximum 10 a day). And so on. There are a lot of little things that can make a different for users to become a gold member. People will not become a gold member just to help me out. They want something in return.

Right now, the profile types as integrated in easysocial have those options to realise it. However, the lack of site wide custom fields makes it to hard to implement. Doing the work 3 times on 3 sites...and then the problem of the fact that I want two types of free profiletypes (man or female AND couples.) it would also force me to create two gold counter variants. It is just to much of a hassle.

Right now I use jomsocial+payplans+JSPT(jomsocialprofiletypes) to achieve this. Easysocial in combination with payplans can almost do the same. Only this little problem with the custom fields holds it up. There really should be a way to have custom fields in the profiletypes, which counts for all profiletypes, without having to double them yourself.....(and when somewhere in the future i want to add a field or change a already available field, I have to add/change exactly the same custom field to 3sites X 4 profieltypes = 12 times....)

I really hope there will be a solution for this soon. Then I can migrate al my jomsocial sites.....cant wait till that day!

p.s. It would also be nice if it would be able to give the free member a message when he or she gets to his limits. Like JSPT also does. When the max amounf of pictures is reached, the users gets a popup, telling him that if he wants more photos on his profile, he needs to become a gold member. But this is more for the future and is not the scope of this topic. First we need custom profile fields that are not bound to a profiletype only, but can also be set as part of a member.

Can you confirm, it appears the best way forward for those who need to retain user data when switching profiles:

1. Site Admins should start with a "Master" profile that contains all of the custom fields they might need (imperfect but best practice for for now). Copy this "Master" profile. Now prune/delete those custom fields you don't need in the copy. Benefit is you don't need to worry about similarly named Fields needed similar field IDs. For example, create a "Master" profile then copy and name it "Student", again for "Teacher", again for "Administrator". You can be assured the custom fields "First Name", "Last Name", "Favorite Color", etc. have the same field IDs.
   


2. Contact PayPlans and give them the pointer provided by Mark "/administrator/components/com_easysocial/controllers/users.php under the method "switchProfile" and ask them to modify their method so that custom field data with the same ID is retained during profile switch.
   


3. Review and vote for @Julian's feature request.
   

BTW there are many other examples where you would want users data to persist a profile change. For example, what if you use the rich admin features to create profiles that metered usage on the site based on level of paid subscription with a gold, silver, and platinum plan. When users elect different payment plans you want everything to be retained, but just adhere to the different resource constraints in the profile. Real-life probably has a mix of USER ROLE and METERED USAGE where USERTYPE1 could come in a GOLD, SILVER, AND PLATINUM subscription. Flexibility on the side of PayPlans and ES is needed here, but both do appear to have all the elements in place.

Is it the case the the table defines data entities "__social_fields_data" and maybe what we're wanting is a table that relates entities? Could one of the possibilities be to define the key as a constraint on multiple columns and change the key when the profile changes? I'm thinking of something like this MYSQL tutorial:

CREATE TABLE Persons

CREATE TABLE userroles(

   user_id INT NOT NULL,

   role_id INT NOT NULL,

   PRIMARY KEY(user_id,role_id),

   FOREIGN KEY(user_id) REFERENCES users(user_id),

   FOREIGN KEY(role_id) REFERENCES roles(role_id)

);

The details of how the capability is provided isn't important to users, but the ability to allow site owners to switch users' profiles and have persistent user data is important.

@Julian, @Cbais and other ES users, I have made an inquiry into ReadyBytes support forum to ask their PayPlans product to fully support their auto switch of user profiles to include persisting user data based on their subscription turning to "Hold" or "Expire" status. Also interested in support for "Upgrade"/"Downgrade" subscriptoin based on profile as well.

Thanks Eileen for also asking Readybytes. I have a feeling however that the payplans app just does what it says it does. It changes the profiletype of a user. nothing more. nothing less...Payplans cannot change things, which needs to be done by easysocial ;-)

Never the less, I think a lot of people are waiting for a good integration of payplans with easysocial ansd the profiletypes. I do for instance :-)

I have a feeling that everyone who is using jomsocial+payplans+jspt right now, cannot make the switch to easysocial at the moment cause of this.

@cbais that's the essence of their response:

1. EasySocial Profiletype app assigns the profiletype to user according to the subscription status. So, ultimately user will see the profile fields according to their profiletype in EasySocial. So, PayPlans does not handle anything in showing the profile fields according to the profiletype. It will be handled by EasySocial only.

@Mark, I didn't find the method "switchProfile" in this file /administrator/components/com_easysocial/controllers/users.php
Can you give a pointer to the method?

This is how one switches a person's profile while it tries to retain existing data

$model = FD::model('Profiles');

$model->updateUserProfile($userId, $newProfileId);

With this codes used, EasySocial will try to map back the data the user has (with specific field keys) with the new fields on the person's profile.

What Julian probably means, and what I also mean, is that a lot of custom fields are valid for all the profiletypes. We want a system that profiletypes can be changed during membership. No matter what reason. Some people like me, want it to give paying members more access, or give them more MB's or more amount of photo uploads and so on....

In regards to having a "global custom field" above, I really don't think what you said makes any sense at all. You are saying that the custom field is used across all profile types. So if you have 20 different profile types, and you want to order the custom field differently, how would that work? Or let's just put it this way, for the username custom field, on profile type 1, you want to call it "Username" but on profile type 2, you want to call it "Stacks Login". There's no way to achieve the above if you are centralizing all the fields.

@Mark: you think to hard about it. Look at it much simpler

I just want to be able to add a custom field, lets say for example a custom field 'hair color'.

I want to add this custom field not to 1 profile type, not to 2, but to ALL profiletypes there are on the site. So when a member changes profiletype, the custom fields will still be the same as is the belonging value the user has choosen.

Right now this is possible, by creating the same custom field for every profiletype. However, have You got any idea how much work this is? Lets say I have 50 different custom fields (hair color, left/right handed, which car they own etc etc etc) and 10 profiletypes. Then I have to do this trick in total of 500 times (and I will probably have typing errors then). Next to this, as Eileen and Julian also stated, the data will be very inconsistent the way it is implemented now.

A global custom field so to say or as Julian explains: a custom field bound to a user and not a profiletype, will solve all those troubles....

Link to the voice of Julian: http://stackideas.com/voices/easysocial/item/581

Hello cbais,

I think you are not understanding the point here. Yes, with a global field, you get to simplify your job but what about users who wants to have a more customized experience for each of these profile types? There's no way for them to do this.

It's not about looking at things in a more simpler way. We have tons of different customers and they have their own methods on using EasySocial on their site. The custom fields that we have allows them to have the ability to achieve this.

I know this for a fact because what you guys are requesting are based off JomSocial's custom fields and I wrote the global custom fields on JomSocial back then. There has been tons of users requesting to have different custom fields for different profile types and not sharing the same fields. So if we were to replace it with global fields, how about these users? Wouldn't they also complain in the forum and it's going to be an entire chicken and egg scenario again.

I do agree with you, but isn't there a way, to have both?

I never stated that the current system of custom fields should be replaced. There are indeed custom fields that need to be bound to a profiletype. I see lots af advantage in that system too..

I am just asking if it is possible to also have custom fields, which can be bound to a user. 2 types of custom fields so to say. Fields to use, bound to a profile, and fields which can be bound to a user (or in that matter, all profiletypes).

That way You can keep both type of customers happy and won't have complains on the forum of both type of users ;-)

Big apologies to this thread, but I misunderstood the stated problem/request and should have been actually testing this (I'll use the lame excuse that there's too much on my plate and I have about 70% less Mark has to do, I'm sure

Mark notes above there is a method to update a user profile when switched and it couldn't be simpler. When switching from the back-end, it works for me so in the example above from @cbais regarding 'hair color' I confirm it persists across profile types. The net effect achieved is analogous to a "global custom field", isn't it? Consider that the "field id" is what's "global", whenever you query for FIELD_ID for a particular user, the same value set by the user will be returned and in that way it is "global".

$user = FD::user('Eileen');

echo $user->getFieldValue('FIELD_ID');

I'd change my recommendation on how to proceed above:

1. Site Admins should consider up-front and start with a "Master" profile that contains all of the custom fields they might need. So for example of a school social network, add a new tab for "Student", "Teacher", and "Administrator". If a new field is deemed necessary later, you will have to add it carefully to all profiles but with up-front planning and design this should be infrequent.
   
2. Copy this "Master" profile and re-name it so you have "Student", "Teacher", and "Administrator" profiles with the same fields and ids.
   
3. Now change the settings "Appear During Registration", "Appear During Editing", and "Appear During Displaying" to fit your needs. For the "Teacher" tab, you will probably set those settings to "False" for the "Student" and "Administrator"
   
4. When you change a user's profile, all of the field values will move along with the user, the data is persistent in this way.
   
5. If you change the user profile outside of the back-end administrator, call
   

$model = FD::model('Profiles');

$model->updateUserProfile($userId, $newProfileId);

I made a screenshot of my current running solution. maybe that makes it a bit more clear.

Firstly: I don't use the jomsocial build in profiletypes. I use JSPT from ReadyBytes to achieve what I need for my custom fields. I defined 3 profiletypes in JSPT. Member, silver & gold.

With every custom field I have created, I can say to which JSPT profile type it should be part of. Only member? or only silver? or only gold? or maybe all three profiletypes I have defined. This way, people can have custom fields for only one profile type, but they can also assign a custom field to all profiletypes.

Screenshot is of the custom field 'woonplaats' (City on english). It is assigned to all JSPT profiletypes in this case....

@Eileen: so the data is persistence then, when using same keys? Thats good to hear.

The only thing I would die for to know, is how to make point 2 of the list You mention easier. Copy the master profiletype: Is this done by hand? Carefully add all custom fields exactly the same into the other profiletypes as the master? Or can this be done faster and more secure? Like copying something in the sql database for example?

@Mark: before I forget: I really appriciate what You guys are doing with easysocial. Just try to think along. I know for sure I am not the only one who is encountering those little problems ;-)

@cbais copying the master profile is super easy thanks to the ES design/implementation - just click one button and viola it's done. Here's a screen shot:

@cbais, this is where I refer to grouping your Custom Fields on a tab and then setting the availability of that tab after you copy the profile. Best way I think to get your profiles setup --- and even maintain them.

Hi Mark,

I think you are not understanding the point here. Yes, with a global field, you get to simplify your job but what about users who wants to have a more customized experience for each of these profile types? There's no way for them to do this.

I did missunderstand your point from the begining. When I realized what it REALLY is about, I created the Voice.
Let me explain:

Your solution for custom fields in profile types is very powerfull and very flexible. It is a complete other solution then "normal" custom fields. Whereever I look, in every other software custom fields are set "per user". It´s in JomSocial, in AcyMailing, in CB and in tons of other scripts. So I always was looking for the "normal" custom fields and I did not realize what your feature of "profile-type-based custom fields" really achieves.

Neverthenless ... the problem some users are facing is, that your solution does not cover some of the basics of custom fields. And in that moment I realized ... we are talking about TWO DIFFERENT FEATURES.

I totally agree in cbais statement:

I never stated that the current system of custom fields should be replaced. There are indeed custom fields that need to be bound to a profiletype. I see lots af advantage in that system too..

Facing this as two different features solves all missinterpretion. The "profile-type-custom-fields" will never be able to solve some of the basic features of custom fields. So they are a very powerfull feature ... but a different thing then the regular custom fields.
As "profile-type-based custom fields" does not fullfill the basics of "custom fields", but still is very powerfull, we should face it as two different features.

The custom-fields that we are looking for in this thread are the regular ones. Simply added in the database beside to the users. There is some data that will never change, regardless of the profile-type. Things like Username or Gender are hardcodet into the system. (Regular) Custom fields should make it possible to extend and customize the "regular fields". And this can´t be done right now.

This is, why I see that Easysocial has a very powerfull user-type-based-custom-fields-feature, but NO normal feature for custom fields.
So my voice is exactly what I described in the voice: Regular custom fields.

All the best, Julian!

I have updated my inquiry to ReadyBytes please add your own information and/or support of my request if it's helpful to your case as well. We could certainly do this but it's appropriate the 3rd-party take-on the responsibility.

The answer from the developer of PayPlans:

Yes, PayPlans EasySocial Profiletype app uses this method [the one referred to by Mark above] to update the profiletype in EasySocial. You can also check the code in file at this path :-root/plugins/payplans/easysocialprofiletype/easysocialprofiletype/app/easysocialprofiletype/easysocialprofiletype.php

Hey guys,

Sorry for the delay of this reply, I just got back from the conference in Thailand and I am really tired. I appreciate all your inputs on this but introducing 2 different types of fields would just complicate things more I am afraid. We have plans to alter the behavior of custom fields on EasySocial 1.5 but let's have a discussion over this again

Hi Mark,

Sorry for the delay of this reply, I just got back from the conference in Thailand and I am really tired.

Take your time!
EasySocial has such a great speed in developement and such stable releaes, you totally deserve it to take your time to rest.

introducing 2 different types of fields would just complicate things more I am afraid.

I don´t really agree on this thought.
We had a long discussion about "sitewide custom fields". You clearly statet that you don´t want to integrate this option.

After closely looking on that topic it seems, like the features you achieve with "profile-based custom fields" are different then the features that "normal custom fields" would achieve. So instead of trying to somehow migrate those features, the Idea was to look on them separately and make two different enhancement out of this.

For me it seems like you "love" your concept of "profile-based custom fields", and you try to protect this Idea by the statement that it would be "too complicated". I don´t agree on that. There are different ways of fullfilling the needs without making it much more complicated.

However, it seems that you don´t realize that for some users the "profile-based custom fields" are useless as long as they don´t fullfill the regular needs for custom fields. There are plenty szenarios shown in this thread that should make you aware there is a need. I totally agree that "custom-based profile fields" fullfill features, that regular custom fields will never do.

But there are plenty of szenarios how to easily integrate bouth kinds of custom-fields without messing anything up.

Imagine it like this:


-> In the Users-Section a custom field can be created for the user-profile. This custom field will be connected to the user-profile and is valid globally.
-> In the Profile-Types-Section a custom field can be created for the profile-type. The behaviour is the recent one.


This setting would be very transparent. If an admin creates a custom field "inside" of a profile-type, then the custom fields is present only in the c ustom field. If the admin creates it in the users-section, then it is valid for all users. Where is there anything complicated`?

All the best, Julian!

You have your points and we have our points as well and nobody is actually wrong about anything. I am just stressing out that having this would just complicate things even more. For instance, if you have a custom field for user and custom field for profile type, when you edit a user, how would you want to know which fields are for users and which are inherited from profile types.

Since you have already posted this in our feature request area, let's see how many users actually vote for this