new search field in admin

You have limited ability to add content to the user list table. I think you’re better off using the default search box and modifying the search query to get the users you are looking for. Similar to “pre_get_posts”, there is a “pre_get_users” action hook where you can modify the query as desired, but limited to what query vars are available. WP_User_Query accepts meta data query vars similar to what WP_Query does for posts.
https://developer.www.ads-software.com/reference/classes/wp_user_query/prepare_query/#parameters

So I just replace “pre_get_posts” with “pre_get_users” ?

That might almost work for custom_search_query(), but search_by_post_id() would not work since it’s specifically for posts. If you want to search for users by ID, set “include” query var instead of “post__in”. And there is no concept of user type, so the post_type line does not apply.

In both cases, the search query var is not “s”, it’s “search”. You’ll need new function names for both since you cannot use the exact same function even though they’re fairly close.

I’m working only on the “search by ID” that is more important, this could work? https://pastebin.com/uBPveBXD , I replaced all the “s” by “search”

“search_by_post_id2” is a confusing name since you’re searching for a user ID. It’s valid PHP, but it’s not good for future maintenance after you’ve long forgotten what the function is for.

$query->is_search is not a property of WP_User_Query. Instead you’ll need to check if the value of $query->search is not an empty string

There’s no ‘post_type’ query var in WP_User_Query. You could instead check for a particular role or something; or just remove the post_type line altogether.

‘pre_get_users’ is an action hook, not a filter, you should be using add_action() instead of add_filter(). Oddly, add_filter() will still work for action hooks. They are both functionally similar, it’s more of a semantic difference. The main functional difference is actions do not require a return statement while filters absolutely require it. It’s OK to return from an action callback, but it does not accomplish anything.

I think I havent explained myself clearly, the starting point of the search field is the user page https://test.sacconicase.com/wp-admin/users.php?role=subscriber, but the function is identically to the custom field in the post table https://test.sacconicase.com/wp-admin/edit.php, that is to say I’m still searching for a post ID, not a user ID

OK, but the default search field searches for users, you cannot use it to search for posts. The users.php screen is not even capable of displaying post search results, only users. What do you hope to accomplish by searching for post IDs on a users screen?

A customers calls me and I open a specific table done with subscribers, a have custom fields, I take note of his request, sometimes the customer has seen a specific apartment and can tell me the code of this apartment. When I have saved him and its data, it’s usefull if I can immediatry take the requested code and pass it into a search fields, without changing of page (and table), so that I save time.

As I said, the users.php screen is not capable of displaying post search results. Even if it did, you’d lose the users while posts are being displayed, so you’d be changing the page anyway.

It is possible to add view links which are used to display users in certain roles on users.php. I don’t think added views have to be links, one could probably add HTML for a custom post search box. It’s not feasible to add another search box in the upper right corner or alter the existing one.

It’s also possible to add HTML content after the “Change role to…” dropdown and button. Where ever you add a custom search box, you could use JavaScript and the API to get search results and display them in a modal or pop-up box. It’s the only way I can see doing a post search without leaving users.php.

I’ve no doubt such a feature would save you time, however, developing such a solution would take much time and effort. What I would do in your place is simply keep two browser tabs open. One for users and one for posts. If I’m on the users.php and need to search for a post, I’d just jump to the other tab and do the search there, then switch back afterwards. If the post search box is currently active, the two tab approach doesn’t involve any more clicks than a custom search box with modal would take. It does initially take a couple extra clicks to set up the two tabs when you begin working, but after that there’s no extra effort involved and a lot less development effort.

Is it possible to add a custom search box near the selector “change role into”? or anyway on that line?

Some list tables such as posts have this ability, but not the users list table. You could however add HTML content to all of the “views”, the line under the topmost Add New User button, the one with links to views by various roles. Use the “views_users” filter. Your callback will be passed an array of HTML links. Add another element to the array whose key is arbitrary and whose value is the desired HTML for your search form. Don’t forget to return the entire modified array in the end.