[Resolved] None Of The Wcpf Fields Are Available To Filter On

[Author]

Posts

[EricP9341]

We just launched our site and noticed the member search is no longer working when you select the filters for languages: it does not filter for those. We narrowed the issue down to the fact that none of the wcpf fields are available to filter on. This was fixed before in an update of one of your plugins, if I remember, but again it is an issue.
hidden link
The filter in question has the structure as seen in the screenshot.

My programmer is saying the wpcf fields are not available. Specifically, wpcf-language-skill and wpcf-language-learning, which were originated in User Fields. See screenshots.

I updated all the Toolset plugins on the development site (hidden link - now unusable because of a WPML update to string translation plugin) and it made no difference (Yes I've posted to WPML support!).

[Beda]

Is that a Post view?

Post views can not be Query Filtered by a User Custom Field.

I need more information on how:

1. The Field is set up (type, content type applied to)
2. What View type this is (what does it display)
3. Is this happening only on translation or also on native language filters?

I remember that Site was mainly developed with the help of Shane, I am not as familiar with it as he.

But I am eager to help if you can provide me the additional informations.

Filtering by Custom Fields on a Post View works great on my localhost, it must be something I did not catch on your description that I miss in my reproduction.

I will enable Private Form in case you need to show me the problem online.

Thank you

[Beda]

1. I know one can't normally Query Filter Post views by a User Custom Field, but we got it working by writing a JS routine that uses the plugin filter and how it makes the meta fields available.

I am sorry but this is a Custom code you used here and I can not debug this.
https://toolset.com/toolset-support-policy/#getting-help-with-custom-coding

User fields are not available in the Post Views (a View that queries Posts or Custom Posts) because those are not related to the Content Queried.

You can not filter successfully something that is actually not there

If you query a Post Type, you can with the WP Query, filter this Content by it's associated Data, which are Custom Fields, relationships and it's taxonomies.

In a Query Filter additionally you can filter by native Post Data like Title and Author.

User Custom Fields will not appear in a view that Query a Post Type.
It never did.

Of course they will appear in a View that actually queries a USER role.

Is this the case? I still do not see if this is a User view or a post view.

Unfortunately I can not see the Site you provided, the Server can't be found so tells me the Browser.

To clarify and make clear any doubt:

A User Custom field will not, did not and will never appear in a View, where you actually query Post Types.
I also checked this with my colleagues, just to be sure.

Thank you

[EricP9341]

I apologize, I misspoke, it's a view on Users, not Posts, and the query filter is a Usermeta field filter.

I have restored an old version of the site so you can see the filters are working to search for users on the custom user fields for language and language learning:
hidden link

To be clear, I am not asking you to debug our custom JS script, we simply need to know why the value that was retrieved via the URL is no longer stored the same way in the database in the updated Toolset.
(You can use the same login I supplied to you to see the View in question)

We have User Fields for language set as checkbox fields, but these apparently are stored differently such that our search script broke.

Here is a specific example. With the older version, the search worked because the value
was stored in the database this way:
a:1:{s:64:"wpcf-fields-checkboxes-option-5708fc5485a6c1a27b2e306605050c07-1";s:8:"Japanese";}

This was changed in the Toolset plugin update such that string "Japanese" no longer appears:
=a:1:{s:64:"wpcf-fields-checkboxes-option-5708fc5485a6c1a27b2e306605050c07-1";}

thus our script that looks for the language selected in the filter no longer finds it when the string is returned by the URL in the filter (see screenshot).

Please talk to your developers let us know how this Toolset functionality this can be restored. This is very urgent, as member search is central to the purpose of the site, and it seems very fragile the way it keeps changing after updates how data is stored.

Thank You

[Beda]

OK, then the Custom User Fields should definitely be stored in the Database, be available as a option when creating your Query, and the user Field should be stored as this arrays:

If we set the Checkboxes Field to Save a numerical value (1,2,3) to the Database if saved (which is default)

a:1:{s:64:"wpcf-fields-checkboxes-option-531b126e55e7c24391dc24cb90938006-1";a:1:{i:0;s:1:"1";}}

If we save a string like "Checkbox title 3" as value to the Database:

a:1:{s:64:"wpcf-fields-checkboxes-option-531b126e55e7c24391dc24cb90938006-1";a:1:{i:0;s:16:"Checkbox title 3";}}"

Your above array which you provided is completely missing the last argument of the actual value.

I can right think of subsequent issues:

1. Depending on the Field's settings you have, it could be those values are not stored anymore.
Are the values for each user visible in the User Interface?
If you re-save them, do they appear in the Options for Queries and in the Array?

2. Do you perhaps set to save "0" to the database when nothing is checked?
I noticed, it seems there is a problem when saving "0" instead of nothin, and you do not check any Checkboxes, and save a Profile, the "0" is NOT saved but instead nothing is saved.

Anyway I also checked the correct behavior.
I can create a user Field or use a older Field and save it at least once for a single user.
Then I see this Field in the User View Query Filter Options and can set the Query Filter to filter by the URL Parameter.
This also returns the correct Result.

It must be a edge case issue where some values of the Checkboxes are not save correctly to the Database, are you see, the syntax of the Array is still the same.

If you can not solve this by above steps, I need the access details in the private answer below.

And I need permission to re-save users, deactivate Plugins and install other Themes

Thank you

[EricP9341]

Thank you for your work in this. I think we are getting closer to hopefully a solution.

To answer your questions:

"1. Depending on the Field's settings you have, it could be those values are not stored anymore.
Are the values for each user visible in the User Interface?
If you re-save them, do they appear in the Options for Queries and in the Array?"

Yes the values are visible to the user interface, because I'm able to display them, such as via shortcodes in the View on the member search page.
Example:

 [types usermeta="language-skill" separator=", "][/types] 

This will show the language on the page properly.
hidden link
So that's a good question: so those values must be in the database – are they stored in different array than the one the filter query is accessing?

By re-saving them do you mean on the User's page in the backend Users / a user / Update user ?
I tried that – including adding new values (checking new boxes) on a user that never had any - and it did not help the query.

"2. Do you perhaps set to save "0" to the database when nothing is checked?"

No, we do not have that option checked.

The login credentials I gave you are valid for all three sites. It would be best for you to work on, experiment on the following one, which has all the plugins updated and is a development copy:
hidden link

Again, the site where the search is working, that has older versions of Toolset is:
hidden link

The live site (plugins not completely updated yet):
hidden link

Thanks

[EricP9341]

Addendum:
To be clear, when you say:
"Anyway I also checked the correct behavior.
I can create a user Field or use a older Field and save it at least once for a single user.
Then I see this Field in the User View Query Filter Options and can set the Query Filter to filter by the URL Parameter.
This also returns the correct Result."

– are you talking about on your own test site? Are you talking about returning the result in the database or in the filter setup on your test site, not in our search program on our site?

[EricP9341]

Any progress on this? It's been 3 days.

So I've set up a duplicate test site of the one with the working member search, so we can experiment with updating plugins or whatever is needed to isolate the issue:
hidden link

Credentials for Toolset support are the same as the other site.
I've given host login (for database investigation) in many other threads - they are all on the same host.

[EricP9341]

OK I found which update broke the search: going from Types version 1.8.11 to the revision – Types 1.9.

THESE ARE DUPLICATE SITES EXCEPT FOR THE TYPES VERSION:
WORKING member search, with Types 1.8.11:
hidden link

NOT WORKING with Types 1.9:
hidden link

Address this fix as soon as possible please – our project hinges on member searches – what changed and how soon can it be fixed in the newer versions, particularly the latest (2.0.1 as of this writing)?

[Beda]

I seriously apologize, that this thread has not been handled.

A Colleague was supposed to cover me here.

So:

1. Types version is not 1.9 but 2.0.1 (the latest)

And that is what your Debug Infos also show me as you have installed.
I understand, the errors start to happen with Types 1.9?

2. On that test site where you use Types 1.9 you have not updated WordPress
This could be a issue.
Please ensure that you update all, the WordPress, Toolset and WPML

3. I would need to see the Database.
For this, can you install the Plugin "Adminer"?

Also it is required to make sure this happens only with Toolset and WPML + the latest WordPress.

I can not update all Plugins on your site as the Site's Registrations are invalid.

I did update the ones I could, and also WordPress.

As soon I did that, these errors happened:

WordPress database error: [Duplicate column name 'id']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY

WordPress database error: [Duplicate column name 'name']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `name` VARCHAR(250) NOT NULL

WordPress database error: [Duplicate column name 'hash']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `hash` VARCHAR(50) NOT NULL

WordPress database error: [Duplicate column name 'status']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `status` INT(11) NOT NULL

WordPress database error: [Duplicate column name 'created']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `created` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'

WordPress database error: [Duplicate column name 'owner']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `owner` VARCHAR(60) NOT NULL

WordPress database error: [Duplicate column name 'package']
ALTER TABLE gvq_duplicator_packages ADD COLUMN `package` MEDIUMBLOB NOT NULL

WordPress database error: [Duplicate key name 'hash']
ALTER TABLE gvq_duplicator_packages ADD KEY `hash` (`hash`)
Skip to main content
Skip to toolbar

Those seem to be related to the Duplicator Plugin.

Also this errors appeared:

Notice: add_object_page is deprecated since version 4.5! Use add_menu_page() instead. in /home/eplatt30/public_html/all/wp-includes/functions.php on line 3658
Skip to main content
Skip to toolbar

Notice: force_ssl_login is deprecated since version 4.4! Use force_ssl_admin() instead. in /home/eplatt30/public_html/all/wp-includes/functions.php on line 3658

 Notice: get_currentuserinfo is deprecated since version 4.5! Use wp_get_current_user() instead. in /home/eplatt30/public_html/all/wp-includes/functions.php on line 3658

If your Custom Search us using get_currentuserinfo() this must be updated as well.

Can you ensure a valid Site's Key so we can update Toolset, WPML, disable all other Plugins, use a native theme and ensure the above Error list, also is handled?

Thank you for your patience.

[EricP9341]

Hi Beda.

Thanks for you attention and work on this.
Was the test site you updated hidden link ? I was keeping that one at the earlier version of WordPress just to have a working example of the member search. Yes, it will get errors if WP (and Duplicator apparently) is updated. But i t doesn't matter, because in the meantime I got the search working on
hidden link
by downgrading *only* Types to 1.8.11. Everything else was updated to the latest at the time (a few days ago).
However, the crazy thing is, I did the same downgrade of Types on the live site at
hidden link
and half the search (the top, for Native Language) works, but the bottom doesn't (Language Learning). The script is the same. It's the same host - Siteground – but in Asia instead of the US (the test sites).

As far as installing Adminer, I could no log into all.eplatt.com, because you updated WP and so it gets errors.
I installed Adminer on both of the following test sites. They are OK to experiment on:
hidden link - updated version of site and plugin and WP, except for Types. Member search works
hidden link - older version of site to test member search before i understood it was plugin version issue.

I would really like to know what the difference is between hidden link and unilisten.net such that it breaks the member search Language Learning filter,
and also how to get it working with an updated version of Types.

[Beda]

I am sorry but on hidden link nothing works for me

I chose a language and hit "Search" and a load of JS errors appear in the Console.

The results are not updated and neither is the URL adjusted to your Custom URL arguments.
According you're above statement, it should work, right?

Please see the screenshot with all errors.

Those are the cause for the not working Custom user Search you use on that Page.

Can you clarify this?

[EricP9341]

My programmer says the plugin stripped out the backslash before the +
but if I remember right you said this was a new issue with WordPress 4.5.
In any case we fixed it - should work now, Try again.

Also fixed it on
hidden link
But as I said before, the second search - for language learning - doesn't work on unilisten.net though the sites are the same. Mysterious.

I've installed Adminer as you requested (both sites). I don't see it in the Dashboard left hand side so I can't help with it. Let me know what you discover.

Thanks

[Beda]

1. Can you show me a single user on the system that actually has "Esperanto" stored as "Language Learning" URL Param "languagelearning"
Because I can not find any.

2. I see the Search returns results that are also empty, instead of only matching results (as example if you look for "English")

It might be some cache issue due to previously stored values.

3. I tested some random users and with types 1.8.11 I see as example for user ID 3 the following language-learning value:

a:1:{s:64:"wpcf-fields-checkboxes-option-f0ef7b1be0fe52aeebd107f4649f25af-1";a:1:{i:0;s:7:"English";}}

Which makes sense so far.

4. I then went up subsequently in version numbers of Types.
I received a lot of

Gateway Timeout

The gateway did not receive a timely response from the upstream server or application.

Finally, I succeeded with all Pluging versions.

The stored value for the Test Use did not change.

It's still

a:1:{s:64:"wpcf-fields-checkboxes-option-f0ef7b1be0fe52aeebd107f4649f25af-1";a:1:{i:0;s:7:"English";}}

For time reasons I did not test over users or fields.
(I apologize, but the site takes too long to load given the delete/reactivate processor the plugin)

I then saw, on your View you do not evaluate the URL param "Language Learning" but only "Language Skill"

I went Ahead and created a new Test View. (Test Toolset)

3 URL Parameters are included:
Last name, Langauge Skill, Language Learning.
(The Fields are properly available in the Query Filter)

It's on this page:
unilisten.net/toolset-view/

The Search on there returns with NO arguments, 7 users.
Why, I do not know.
You have many more users, but the View simply returns me only 7

So this is where we need to start, as it seems, your Website is somehow either not Storing users correctly or Views is not able to get them in the Database.

It is absolutely impossible, that if the Users are stored the WordPress way, Views can not find all of them, unless you somehow modify the Limit or Offset with Custom Code in your theme, which I don't think, because I also tested with Twenty Fourteen.

Now, to proceed, and given the slow process on the online site, I request a Snapshot.
All themes and Plugins and other softwares used must be updated to latest version.

I would need a sites snapshot if possible.
We usually recommend the free Plugin "Duplicator" for this porpoise.

If you already know how Duplicator works
(http://wordpress.org/plugins/duplicator/),
please skip the following steps and just send me the installer file and the zipped package you downloaded.

★ Duplicator Instructions
hidden link
Send me both files (you probably want to use DropBox, Google Drive, or similar services, as the snapshot file will be quite big)

❌ IMPORTANT ❌
Remember to create or keep an admin account for me before creating the snapshot, or I won't be able to login. You may delete the new admin account once the snapshot has been built.

I will enable your next answer as private so you can provide me the information securely.

I will deploy it locally and see what is wrong here, as this definitely is not how Toolset works usually.

Thank you

[Beda]

I used your last provided URL:
hidden link

About the gateway issue, yes this IS a host issue.
The server is the issue here.
You may need to consult this with the Server Admin and elaborate on the issue.

You are right about my View, sorry about that.

Now I fixed it (to view it you need the Theme Twenty Fourteen as example) and it shows all 24 members

I added the Filters and since you store a Custom Field Value in the Database with Upper case letters, I tried this search:
hidden link
1 Result returned.

hidden link
8 Results (all hold English in the Learning Field value) returned

hidden link
7 results returned, all hold English in the Field's skill value

Note that some users du not hold any Language info at all, so as example User ID:
44, 47 and 48

The Toolset featured Query Filter is working perfectly fine on this site.
Toolset types and all other plugins are of course updated.

Thank you