[Assigned] can't access user fields

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

You are not logged in. You can view support threads, but not post.
If you are already logged in, please refresh your browser.

This topic contains 31 replies, has 2 voices, and was last updated by  eliseD-2 1 week, 2 days ago. The support staff assigned to this topic is Beda.

Viewing 15 posts - 1 through 15 (of 35 total)
Author
Posts
#556763

I am having some trouble with accessing user-meta fields to use in Views and Cred forms.

I created custom user fields for information like address, city, state, zip, in a user group called Contact Info.

I am using the plugin WP-Client to allow my users to edit their profile info, and in order to do that I had to "map" the custom fields to corresponding custom fields in WP-Client. This works fine for the profile - my users are able to update their own information.

But now I can't seem to create my own views and CRED forms for viewing and editing my users data.

On my WordPress dashboard for a particular user, I see two different groups of fields for each user:

"Further Information" and "Contact Info". The "Contact Info" fields seem to correspond with my custom field group, and if I enter info there, I can use it in a View.

But my users seem to be accessing the fields under "Further Information" - and I can't access those fields.

When I reveal the source code on the page, BOTH sets of fields have names like "dbem_address" - but using that name in a View only yields the one from Contact Info, not the one from "Further Information" that my users are using.

I seem to have created quite a mess, and I can't for the life of me figure out how to get this working.

Thanks for any help you can offer.

Elise

#556772

I am now able to use my custom fields in VIEW - but still can't access them in a CRED form.

In a View - I am able to see them with this code:
[types usermeta="dbem_address" user_is_author="true"][/types]

But in a CRED FORM, when I use this code:
[cred_field field='dbem_address' post='user' value='' urlparam='' class='form-control' output='bootstrap']
I get an error.

The "Add User Field" button offers this version of the field:

[cred_field field='wpc_cf_address1' post='user' value='' urlparam='' class='form-control' output='bootstrap']

This one doesn't cause an error, but it shows an empty field.

So I can't get the info that is already in the field show up on the CRED Edit User form.

Can you help?

Thanks!

Elise

#556801

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

Well, we do not develop that Plugin, and we cannot help when it creates problems on the site.

Can I ask, why you have had to port the Types Fields to another Plugin?
You can use CRED to let users edit their - or others, Profiles.

I am not sure why you mapped those fields in a Plugin that seems to do what CRED also does just fine, but now want to edit them again with CRED?

I also logged into the site to see around for myself:

On my WordPress dashboard for a particular user, I see two different groups of fields for each user:

"Further Information" and "Contact Info." The "Contact Info" fields seem to correspond with my custom field group, and if I enter info there, I can use it in a View.

Further Information is not of Types.
Contact Info is not.
You can "prove" that by adding "EDITED" to the Toolset Types User Field Group Title and save it.
In the User Edit Profile you will now see:
Contact Info EDITED
Further Information

You mention that your Users access Further Information.
I do not know where, but, if that plugin provides some mapping and front-end edition of those fields, it's up to that plugin to make sure the plugin ports the data correctly to the Field.

To me, it seems it is instead creating NEW Fields of a particular type.

I would suggest to contact that Plugin and ask what they exactly do when "mapping" a field.

Also, I would advise you to use CRED for the Front End instead.

Unfortunately, in Views for Users, there is no way to access 3rd party User Fields, as there is in Views for Posts.
We just log natively stored user Fields there, and Types user fields.

So, that means, 3rd party user Fields are not accessible in Views for users.
This is different in CRED.
In Toolset > CRED > User Forms > Manage non-Toolset User Fields with CRED you can take control over third party Fields.

I think it could be a useful feature, at least, for SIMPLE Fields like single lines and similar.
(In Views)

I will file this as a request.

#556863

The reason I use the 3rd party plugin is because nearly three years ago, when I started my site, CRED could NOT be used for users. (see this post: https://wp-types.com/forums/topic/using-cred-to-register-a-new-user/)

So I used WP-Client for my clients to register and update their profiles.

Recently, I realized the CRED now had that function, but I didn't want to change my WHOLE site - it would be too much work. I just want to allow for my staff to be able to add and edit users without having to use the WordPress dashboard - so I decided to try to set up a User Edit and a New User form.

You mention that Views cannot access 3rd party custom fields, but CRED can.

My experience now has been the opposite.

I am able to show the 3rd party custom field in my Views with no problem.

But I am NOT able to access them in CRED - even though I have used Toolset > CRED > User Forms > Manage non-Toolset User Fields with CRED to "manage" those 3rd party fields.

One thing you could check to see my issue - if you make a user account and then add information into the "Further Information" section - it won't stay when you submit. BUT if you add info into the "Contact Info" section and submit, it will show up in BOTH sections because those fields are mapped through WP-Client.

Also, if you put info into "Further Information" when there is already info in that same field in "Contact Info", when you save, the change you made to "Further Information" will NOT change. It will only change if you change it in "Contact Info".

I really want to try to avoid having to re-design my entire site for my users registration and profile editing ... I just want to ADD this option rather than have to re-write all my other pages.

Any other thoughts on how I might be able to accomplish this?

Perhaps you can help me understand why even though when I make a CRED user form and use the auto-generate function and it inserts fields that are 3rd party fields that I have controlled with Access - those fields will show up in the form but they are EMPTY (even if the fields do have info in them when I look through the dashboard) and if I put info into those fields in the User Cred form, they not only do not save, but they DELETE the info that is already in the fields.

You can see this behavior by doing this:

check out my User form called User Edit Admin.

If you find the "address" field - you will see that I have entered the field that is being offered through the "Add User Fields>Custom Fields" tab:
[cred_field field='wpc_cf_address1' post='user' value='' urlparam='' class='form-control' output='bootstrap']

When I view that form, I can see that field - but it is EMPTY even for a user who has info in both "Contact Info" and "Further Information".

(You can check this out for my own record in the database through this link:
http://nmi.org/admin/contact-management/?content-template-id=60792&user_id=43

If you enter information into the BLANK field for "Address1" in my form and then SUBMIT the form, NONE of that info gets saved. And yet, if you look at my USER page through WordPress, those fields are all populated in both "Contact Info" and "Further Information".

So what I don't understand is: if I am using Toolset > CRED > User Forms > Manage non-Toolset User Fields with CRED to take control of a 3rd party field, and then when I make a User Cred form, that field is available to me under Add User Fields>>Custom Fields - why is that field blank in the form even when I add info and click SUBMIT on the form? Where is that info going?

Elise

#557591

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

If you would not mind, can you show me a screenshot where you see those user Field in a View?

Please see my screenshots that show there is no such GUI.

1. Add any Custom Field for a user (in my case, test_field, value 1)
2. Save it against a user
3. head to any View and query Users of that role
4. Try to add that field

You will see there is no such Field.
Note that the Field "Toolset Test Field" is a Field I set up with Types.
What should show, but does not, is the Custom User Field "test_field" wich is a third party field (registered manually).

I can see that Field Toolset > CRED > User Forms > Manage non-Toolset User Fields with CRED
(also see the screenshot)

I do also not experience any other situation in your website.
I created a Dummy View (Toolset Test View), where you can see that only Types user Fields are present in the Loop GUI.
(From the group "Contact Info")

No other User Field from any third party is there.
You can see that when you head to the View and click "Fields and Views" in your Loop.

Please correct me if I am wrong.

In your Toolset > CRED > User Forms > Manage non-Toolset User Fields with CRED screen, I can 312 non-Types User Fields.
Please also correct me if wrong, I checked that on your site.

I am quite sure those Fields are there as well.
Please correct me if wrong (I do not know the exact slug of those 3rd Party fields)

if you make a user account and then add information into the "Further Information" section - it won't stay when you submit.

I understand. But these fields are not made by Types.
What is working, is the field set created by Types, correct?

Hence, I must suggest you contact the Author of that plugin and explain the issue.

Perhaps you can help me understand why even though when I make a CRED user form and use the auto-generate function and it inserts fields that are 3rd party fields that I have controlled with Access - those fields will show up in the form but they are EMPTY (even if the fields do have info in them when I look through the dashboard) and if I put info into those fields in the User Cred form, they not only do not save, but they DELETE the info that is already in the fields.

Previously you stated you cannot control 3rd Party user Fields.
Such fields will only appear in CRED when they are also managed by CRED.

In Access there is no such field control, what there is is a control to what/who can do where, but this is not related to CRED if controlled in Access.

Also here the issue is the same. It seems those Fields, created by the 3rd Party, are not passing the information in a user meta but somewhere else, eventually.

It would be very helpful to know:

1. Where exactly are the 3rd Party Custom user Fields stored in the Database?
(the meta_key and meta_value)
2. What does the Author of that plugin say regarding this?
==> Where and how are those fields supposed to be stored?
3. It might be that CRED cannot communicate fine to the Database, that would then be a BUG in CRED, but we should first solve the core problem:

The fields of the 3rd Party do not get updated even if you edit them in a user Profile.

I suspect once that is fixed, or clarified; we will also be able to shed light on all other issues.

I am quite confused about the issue you mention that you are not able to control 3rd Party user fields with CRED, but you say:

So what I don't understand is: if I am using Toolset > CRED > User Forms > Manage non-Toolset User Fields with CRED to take control of a 3rd party field, and then when I make a User Cred form, that field is available to me under Add User Fields>>Custom Fields - why is that field blank in the form even when I add info and click SUBMIT on the form? Where is that info going?

Maybe you mean that you can control them, but it does not work in CRED itself once added?
==> that would be the same issue as in the WordPress Admin > Edit User.

Please also inform me on this:
- what type are those fields?
==> any non-arbitrary field will probably be destroyed upon control with CRED
(Such as WYSIWYG, Checkboxes, select, etc.)
This is because we need to convert them to control and cannot guess the 3rd Party Field's structure.

#557901

Go to this page:
http://nmi.org/admin/contact-management/?users-filter=43

On this page, you will see a View that shows the phone and address for me (Elise Dewsberry).

The View is called "Contact Management" and it calls custom user fields from the "Contact Info" custom user fields group using this code:

[types usermeta="dbem_phone" user_is_author="true"][/types]
[types usermeta="dbem_address" user_is_author="true"][/types]
[types usermeta="dbem_address_2" user_is_author="true"][/types]
[types usermeta="dbem_city" user_is_author="true"][/types], [types usermeta="dbem_state" user_is_author="true"][/types]  [types usermeta="dbem_zip" user_is_author="true"][/types] [types usermeta="dbem_country" user_is_author="true"][/types]

Those are exactly the slugs used in the Contact Info custom user fields ("dbem_phone" etc.) and they are all single line type fields.

So that works fine for me - I created custom user fields, and I can show them in a view. (I can't imagine why Toolset would let you create customer user fields and then NOT show them in a view?)

HOWEVER if I go to USER FORMS and ask to make a new User Form and use the "Auto Generate User Form" button, CRED automatically offers fields with names like this:

[cred_field field='wpc_cf_address1' post='user' value='' urlparam='' class='form-control' output='bootstrap']

BUT - those fields show up EMPTY in the CRED form when you use it, and if you add something to those fields, it doesn't save.

When I go to "Manage non-Toolset User Fields" - I can see that "dbem_address1" is being managed by Types - but if I try to call that in the CRED Form, it says there is a problem with the field.

So I don't understand why if the field is offered by the auto-generate function in CRED, it doesn't work. Or, why the fields that I have marked to be managed by Toolset throw an error in CRED.

Elise

#558072

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

Hello Elise

You must have missed my last reply.

I never said that you cannot add User Fields created with Types in Views.

I have shown instead, that this works. And I have also shown, that any other User Field (not created with Types) cannot be added to Views.

You confirm that with your own reply:

Those are exactly the slugs used in the Contact Info custom user fields ("dbem_phone" etc.) and they are all single line type fields.

So that works fine for me - I created custom user fields, and I can show them in a view. (I can't imagine why Toolset would let you create customer user fields and then NOT show them in a view?)

Yes, Toolset Types User fields can be added to Views, and just to be sure, they do not need to be brought under CRED Control because they will already appear in CRED Forms.

In CRED; when you autogenerate the Form, and did NOT bring any 3rd Party Fields under CRED Control, then the CRED Fields must hold the slugs as you coded them in Toolset > User Fields.

So, the Field "wpc_cf_address1" for example should be available in Toolset > User Fields > your_group > Edit with that exact slug.
Is it?

I am sorry I cannot check for myself as the website is not reachable at the moment.

Now, Types User Fields added to CRED User Forms do work properly, I have tested that.

As far I see it, you do not need to add your 3rd Party Fields to CRED forms but only the Types Fields.
And those work, I tested them.

Please, if they do not work on your end, do this:

1. Disable all Plugins but Toolset
2. Disable the Theme and use a WordPress native Theme
3. Test any user Edit Form with Fields that have been created by Types

Does it work?
If not, please send me a site's snapshot to assist you as fast and effective as possible.
https://wp-types.com/faq/provide-supporters-copy-site/

Thank you!

#559242

I do still need help on this issue but am out of the country at the moment and will provide more info and screenshots when I return.

What do you mean my site is not available?

#560214

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

Hello Elise

Just let me know when you have more doubts, and you are back.

The site cannot be loaded in the backend.
The front end loads fine, but the wp-admin shows:

Error 503 Service Unavailable

Service Unavailable

Guru Meditation:

XID: 1159062301

Varnish cache server

I was, therefore, not able to confirm this by mayself:

So, the Field "wpc_cf_address1" for example should be available in Toolset > User Fields > your_group > Edit with that exact slug.
Is it?

#561620

I will be back in town next week. In the meantime, please try to access my site again...I tried it myself and did not get an error logging in.

Thanks.

#562259

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

I can access jsut fine http://your-site.com/admin/.

But not http://your-site.com/wp-admin/

That's where the issue happens.

Do you use a GeoBlocker?
My IP:
219.78.174.155.

Please let me know once you are back and have seen my elaborated eplanations on the previous posts.

#563839

I get back into town Monday...please kerp this thread open.

In the meantime...I have a redirect on the site that takes you to admin instead of wp-admin but the WordPress toolbar is accessible on that page and you can just click WordPress Dashboard to get to the regular wp-admin page.

Elise

#564653

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

OK, thanks for the heads up.

I was now able to access the backend.

1. In a View, when users are queried, I can see your Types user Fields:

2. I can not see 3rd party Fields

3. In CRED, User Forms, Fields Control, I see over 300 Fields you can index, and in CRED forms, I see all Types Fields available in the Form generator.

Therefore my previous statements are also confirmed on your site.
Please correct me if I am wrong.

Thanks!

#564951

I've created a page on my site with the results of a User View and User Cred Form; as well as my notes about it.

Please have a look and let me know if you can help.

http://nmi.org/admin/01-test-pages/elise-test/

Thanks!

Elise

#565042

Beda
Forum moderator

Supporter languages: English (English ) Spanish (Español ) German (Deutsch )

Supporter Timezone: Europe/Zurich (GMT+02:00)

We have some confusion here.

1. dbem_phone is a Types Field.
But for each of the fields you also have a wpcf-dbem_phone and cred-dbem_phone field, not controlled by Types, some are controlled.
Why this mix up, I do not know, but please acknowledge that wpcf- is a prefix used by Types, and Types only. It should not be used by other plugins or code to create Fields, if possible.

Some of those fields are managed by Types, some not, some are in groups, others not.
I do not really know which came first, and if they all where created by Types or not.

The same is valid for wpc_cf_phone, wpcf-wpc_cf_phone and many more.

2. It seems to me, the Fields in the Types Group "Contact Infos" are not initially created by Types.
At least not the dbem_ ones.
Those disappear from CRED.

3. The dbm_ field are in Toolset > CRED User Forms > User Fields control, as I elaborated earlier
(see screenshot)

Why they are there, I do not know, but most likely, you have not created those dbem_ fields with Types at the first, but rather you controlled them with types later.

What I suggest here is a Clean Up.
Remove that Fields group, delete the Fields in the Fields Control Screen, and set up a new, Types only User Fields Group.

That will work as it is expected to.

Or, control the Fields with CRED.

But given the confusin mix of fields I would rather suggest to refactor this.

Viewing 15 posts - 1 through 15 (of 35 total)

You are not logged in. You can view support threads, but not post.
If you are already logged in, please refresh your browser.