Tell us what you are trying to do?
I have a view that displays all non-admin users for the app I'm creating, see screenshot 'UserSettings'. I need to be able to filter/search the view for a user by name, or by email address. I read in the documentation and in the view that it's not possible using the native wp fields, so I created custom user fields, see screenshot 'UserMods', to hold some custom fields I need as well as a duplicate email field, and a full name field that combines the first and last name user fields into one.
I am still unable to filter/search the view by the custom fields, as the view will not allow it. I just found the below support thread suggesting the answer is to create a new post type, duplicate the needed fields, and use that to create the view. However, this is an app that will have a customer portal with potentially hundreds or even thousands of customer users. That is a lot of data to duplicate and store, surely there is a better way to do this, no?
Is there any documentation that you are following?
https://toolset.com/forums/topic/searchable-view-showing-user-fields-of-post-author/
https://developer.wordpress.org/reference/functions/get_userdata/
https://developer.wordpress.org/reference/functions/get_user_meta/
https://developer.wordpress.org/reference/functions/update_user_meta/
Thanks,
Matt
Hello, if you're referring to front-end filters, as in a parametric search View for Users, that is actually not possible in Views. Views supports parametric search filters when displaying posts of some type(s), but not Users or Taxonomy terms. As you mentioned, a workaround is to use a proxy post type that represents Users, something like "Members" instead, and create a custom search View of the Members post type, where you can filter by the various custom fields. This is the best solution. Instead of storing the relevant custom fields in the User profile, you'll store the custom fields in the Member post type. I wouldn't duplicate the custom fields, I would just store them in a post instead of the User Profile. There will be an intrinsic link between the User profile and the post because the post author will be the User. This way you can easily access standard User fields like login and email from the context of the Member post. You'll be able to use more powerful features this way, for example, repeatable field groups, custom taxonomies, and post relationships are incompatible with User profiles. The proxy post type concept is explained at length in this document: https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/
Let me know if you have questions about this, and we can discuss in more detail.
Thank you for getting back to me so quickly Christian. Since this is the official workaround for this issue I'll implement it as the documentation states. Unfortunately we are still going to be duplicating data in the database, but I suppose it can't be helped at this point. It does also seem like quite a bit of work for something I would have thought would be pretty standard functionality, but it is what it is. Thanks again for pointing me in the right direction!
Christian,
Sorry I must have missed this part when I first reviewed your response, and now that I'm attempting to implement the work around I'm seeing that it isn't going to work in this situation.
"There will be an intrinsic link between the User profile and the post because the post author will be the User."
Unfortunately that will not be the case here, admin users will be the ones creating new users of different types like Technicians, Dispatchers, and other admins. The only other thing I can think of right now would be to create a function that would change the author on the custom post to the newly created user, but it's late and I'm not sure I have that in me right now. I'll give it another look in the morning when my brain is a bit less foggy, but if you see any flaws in this approach please let me know.
Thanks,
Matt
Unfortunately that will not be the case here, admin users will be the ones creating new users of different types like Technicians, Dispatchers, and other admins. The only other thing I can think of right now would be to create a function that would change the author on the custom post to the newly created user, but it's late and I'm not sure I have that in me right now.
You're saying the admin would be creating these custom posts in wp-admin manually? In wp-admin, the admin could set the post author to any User account manually from the post editor screen. Seems a bit more reliable than choosing the most recently created User account as the author of a new post, but that's just my opinion.
If the admin is using Forms on the front-end of the site to create new User accounts, then you could use custom code to automatically generate the custom post using fields from the User Form, or generic fields. When the post is generated, the new User account could be set as the post author automatically.
So there are a few different ways you could set this up, depending on the desired workflow.
Christian, yes the app admin (not a wordpress admin) would be creating the user on the front end with a user form. After looking at it a little more I think creating a post field with the user info that I need to search by, as well as a user id field that I'll use as the link back to the original user record will likely be the best way to go. The view that will display this info will also have links to update the password as well as the user data, disable/enable a user (by setting the role to 'no role'), and delete a user. I'll let you know how it all comes together.
Thanks,
Matt
Okay I'll stand by for an update here. Or, you can feel free to close this ticket and open new tickets for any new issues or questions that arise from implementing this approach. Also I wanted to let you know there is no built-in feature for deleting Users from the front-end of the site, so a more custom solution is required. Another ticket here in the forums includes details about one such custom solution: https://toolset.com/forums/topic/add-the-link-delete-account/
Christian,
Thank you for your help here, and for being pro-active with the link regarding user deletions from the front end. I believe I have enough to go on now to complete this part of the project, your help has been fantastic and greatly appreciated.
Matt
