[Resolved] can't access user fields

[Author]

Posts

[eliseD-2]

I'm so sorry this is dragging out so long.

I created the WP-install file you requested, and exported my database.

But when I tried to upload them here, I got this error:

writiol6_NMI.sql (68.8 mb) File extension error.
NMI for Toolset.zip (287.9 mb) File size error.
NMI for Toolset.zip (287.9 mb) File size error

How else can I get those files to you?

Elise

[Beda]

You can use the Google Drive Service.
Upload the ZIP to your Google Drive (it's free) and then share this with me.

When sharing, you can ask Google to produce a link that will give access to the data to "anyone who has this link".

Since the reply you will use is private, only me and you can see it.

Then I will download that package, deploy it, and look how we can proceed.

Thank you, Elise, for the patience and collaboration!

[Beda]

Elise, when you import that Database, you will not see Posts table, Options table, and more.

This is not a multisite install, that is why I am surprised that this happens. The Database dump should include all those tables.

If you try to deploy this locally, it will fail.

Maybe you can pass me the phpMyAdmin Log In Data, so I can try to fetch a Database Dump myself as well?

[Beda]

Finally. I did not see that the Database has more than 50 tables and those where hidden in a paginated element in PHP admin 🙁

Now, when I deployed the site I run in some issues:

- Access was complaining about a missing file.
- Replacing access brought up some other hidden errors, related to:
-- cjPluginSeriesHowdy Plugin (deprecated constructor line 43 file cj-change-howdy/cj-change-howdy.php => same name as class)
-- register_sidebar was called incorrectly. No id was set in the arguments array for the "Layout Builder Widget Area 1" sidebar. Defaulting to "sidebar-30" (and this repeats for several widgets)
-- Notice: Constant AUTOSAVE_INTERVAL already defined in /Applications/MAMP/htdocs/eliseD2/wp-config.php on line 108
-- Warning: Cannot modify header information - headers already sent by (output started at plugins/cj-change-howdy/cj-change-howdy.php:43) in wp-includes/pluggable.php on line 1210

After solving these issues by disabling that Plugin and the Theme, I was greeted with a waring that autosave was defined twice, so I removed that from the wp-config.php as well.

Now I was able to log in, after also editing the Database URL settings and user passwords.

Now I will start to debug this according this description:
https://toolset.com/forums/topic/cant-access-user-fields/page/2/#post-565396

Please stand by for news.

[Beda]

I see there is an error when I save the Field to be added to CRED:

Notice: Undefined property: CRED_Fields_Model::$_custom_user_fields_option in cred-frontend-editor/library/toolset/cred/embedded/models/Fields.php on line 263

And I can replicate this issue even on a clean install. This is what keeps you from saving those Fields.

I am analyzing this for the Developers now so to fix ASAP.

Thank you Elise, for your kind patience and guidance in this issue. I believe this BUG was hidden in there because this feature is rarely used, and when you save the field, at first, you will not notice there is an issue, unless you revisit the page (as it happens on my local test).

I will be back ASAP with a solution.

[Beda]

We have an errata that solves this issue:
https://toolset.com/errata/cred-user-fields-control-is-failing-due-to-a-undefined-property/

[eliseD-2]

Thanks so much! I installed the errata, and was able to successfully convert the field dbem_phone to be under CRED control.

However, we're still now back to my old problem that when I use that field in a CRED form, it throws an error. (Also note that it is not OFFERED by CRED as a possible field - even though it is presumably under CRED control - it does not show up under "Add User Fields/Custom Fields").

What DOES show up is "wpc_cf_phone" - which is also under CRED control - but when I save that line in the form, it doesn't show up anywhere in the User's WordPress User record.

hidden link

So what do we try next?

Elise

[Beda]

There is some mess there.

1. There are fields with this syntax:
wpc_custom_fields

2. There are fields with this syntax:
wpc_cf_phone

Both are not of Toolset, so much is sure.
wpc_cf_phone Appears in the CRED scaffold, even I did not control it with CRED.
dbem_phone does not, even thou I added it.

Where from are wpc_custom_fields and wpc_cf_phone?

Those are NOT Toolset Fields, at least, not native.
Eventually those are Fields created with TYPES, and you gave them that slug?
Then, they should not appear in CRED Fields control (because controlled already)

So those fields are the ones from your 3rd Party plugin, right?
And then it makes sense it is added to the list. But it does not work with the Scaffold.

I have to make a full round of Tests here and report each new issue I will find.

Please await my news here.

[eliseD-2]

I do know it's a mess, and I apologize! It evolved over time because of a couple of plugins I'm using.

The wpc fields are from WP Client - the plugin I use to manage documents.

But you will see that in Toolset, I created a group of User fields called "Contact Info" - and the phone number I created there has the slug "dbem_phone".

In WP-Client, I am allowed to "map" other fields to WP-Client custom fields - so I mapped "dbem_phone" to the WP-Client field "wpc_cf_phone" - you can see how this works at this link:

hidden link

I don't really remember why the "dbem" got added - that happened years ago when I first tried to set this up and somebody helped me - it might have been related to yet another plugin but I don't quite remember.

But what continues to confuse me is that I have a Toolset group of User fields that has the custom field with the slug "dbem_phone" and I CAN access it in views, but not in CRED.

hidden link

Thanks so much for your continued help with this mystery!

Elise

[Beda]

I started a full review of this feature also using your site as a base.

It will take me some time to gather all the problems and eventually escalate them to the Developers for fixes or instruct you how to proceed.

I will keep you updated here in this thread.

[Beda]

Hello Elise

I have finished the review and want to share with you here what has now been escalated or requested to/from the developers:

1. Screen options not respected:
There is a "Screen Options" in each of the CRED Control screens for user or post fields.
It is supposed to let you customize the amount of items per page.
It does not work.
I requested to either remove it or fix it.

2. A free Text Search is missing, This is a must in a list of meta_key string based data.
It's not a bug, thou.
Hence a feature Request is filed, where I will put some weight on so to increase it's priority.
If you have 900 fields in that table, you are simply lost, also because the amount of items per page cannot be changed.
So I requested to add this free text search.
No ETA thou.

3. CRED Post Fields seem to recognize only standard post types, as example groups of BuddyPress are not seen, neither their Emails Posts.
This is OK (It is the same in Toolset > Post Types), I just do not see any DOC in regard of what will recognized.
A Post Type, to appear it's fields in that CRED Screen, must have at leasts these arguments:
'public' => true,
'publicly_queryable' => true,
'show_ui' => true

I asked for an update on the Documentation:
https://toolset.com/documentation/user-guides/letting-cred-edit-custom-fields-created-by-other-plugins/

4. When I add a user field to CRED Control, I do not see it in the scaffold, even thou I checked that option in the settings
It is not in the Auto-Generated, not in the User Fields nor generic fields.
Now, the field for tests was a Checkbox Field of User Profile (show_admin_bar_front ) and added to scaffold as checkbox, value to save 1 .

Also simple line fields cannot be added successfully.

I tried to register my own custom user field with the WordPress Codex

add_user_meta( $user_id, $meta_key, $meta_value, $unique );

and also that field is not added to the scaffold.

I reported this as a BUG and our Developer already is on this.

2. I may not even find all user fields in the list.
As example, the description is not in the list, but is already the User Fields in CRED's form edit area as "biographical info"

The table in CRED User Field Control has an own query that follows special custom rules.
It excludes all fields that are:
'_edit_last',
'_edit_lock',
'_wp_old_slug',
'_thumbnail_id',
'_wp_page_template',
'first_name',
'last_name',
'nickname',
'description'

Some of them are re-added automatically to the User CRED form edit area when you add User Fields.
This is hence not a bug but a good piece of information.

I am not sure it is the best choice to remove those fields from the control and add them instead directly to the CRED Form edit screen... but since that is working I think we leave it as is.

Now, these are the issues I found in a clean, vanilla install.

I think once those are fixed, your issue will be too.

But I am also working on your specific Duplicator now, to see how to solve the issue right now for you.

I will update you ASAP

[Beda]

Related to your site:

1. Only when the BUG is fixed you will one able to add User Fields to the Scaffold.

2. The examples dbem_phone and wpc_cf_phone behave as follows due to these reasons:
- dbem_phone is a field that is filed under Toolset > Post Fields.
- But it was not created by Types, most likely it comes from a plugin called YWW?
- Probably you brought it under TYPES control that is why it's now in Toolset > User Fields.
- You have a pendant wpcf-dbem_phone, created with Types, not anymore under Types control, and a pendant cred-dbem_phone as well.
- There is no way to know which is the correct field, as I did not set it up.
Only one should remain and it should (for now) be as the plugin who registers it - that means, if this field wasn't initially a Types field, it shouldn't be controlled with Types to be added to CRED.
- wpc_cf_phone seems to be once again that "YWW" plugin registering the field.
- It is as well registered once as types field but not managed by types anymore and once as the 3rd party's field, not controlled with types either.

So, I have no solution to somehow clear up this confusion of fields.
The wrong ones need to be deleted and the right ones need to be kept, and managed possibly only by the registering plugin.
If you then want to add them to CRED; this will be possible only after the ominous bug is fixed, and usually only for simple fields (Checkboxes and similar may fail)

So, I can not suggest more than wait for that fix, and carefully remove the fields once you are sure which to be used, and which not.

[Beda]

Dear Elise, I have something for you:
https://toolset.com/errata/cred-user-fields-control-does-not-add-the-fields-to-the-scaffold/

Please let me know if you have time to apply the patch, it solves the issue where the User Fields where not adde to the CRED User Scaffold, if the fields were controlled by CRED.

Please let me know if that works for you as well!