Opened 11 years ago
Closed 11 years ago
#26115 closed defect (bug) (fixed)
Fix \' being expressed when searching for users & add display_name to searchable columns
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Users | Keywords: | has-patch commit |
Focuses: | administration | Cc: |
Description
First Part
Whether or not display_name
can be included (see second part), this does fix the issue I am having where, when searching, it says "Search Results for: O\'Rourke" when I am searching for "O'Rourke" and my plugin comes in and lands a user with _wp_usermeta.last_name = "O'Rourke"
.
This fixes it so it says "Search Results for: O'Rourke"
Second Part
I am using a self-made plugin to search by usermeta
using wp-admin/users.php
which allows an administrator to search for "Josh" or "Shawn." This is not included in core, so part of this patch asks to include display_name
in search_columns
again, see #18183 and #16366. Since http://core.trac.wordpress.org/attachment/ticket/16366/16366.diff core has added:
'ID', 'user_login', 'user_email', 'user_url', 'user_nicename'
...so I thought I'd try again.
If core could get display_name
included, then first and last names could be searchable as long as the display name was set to First Last, etc, which would make the first part more important to core. If not, it just become's a simple fix to something core doesn't even really do (search my names where you might use '
), but might be used with a plugin or a filter like #16366 and it would display O'Rourke last names weird.
May need testing around MS
Attachments (1)
Change History (11)
#1
in reply to:
↑ description
@
11 years ago
#3
@
11 years ago
Before: https://cloudup.com/copFH2t3XiG
After Patch: https://cloudup.com/c5PfiQGBqkw
#4
@
11 years ago
- Component changed from General to Administration
- Severity changed from trivial to normal
- Version changed from trunk to 3.1
The concern in ticket:16366:4 is still valid, so I don't think display_name
is going to be added to core at this point.
wp_unslash()
seems fine, but looks like 26115.patch calls it twice for the same variable in both files. I guess it should only be applied to $_REQUEST['s']
.
@
11 years ago
Fix to \' being presented and setnt to WP_MS_Users_List_Table and WP_Users_List_Table
#5
@
11 years ago
Patch modified.
Also note that I added trim()
to WP_MS_Users_List_Table
which wasn't there before, but was for WP_Users_List_Table
. I'm assuming trim()
should have been applied to both.
Also, I'm sure you're busy, but I guess I don't really understand ticket:16366#comment:4, so if you have time I'd love to understand why display_name
can't be added.
#6
@
11 years ago
You changed the version to 3.1? I'm patching off of develop, should I be basing my version on @since 3.1.0
?
#7
follow-up:
↓ 8
@
11 years ago
The version in the trac header refers to when the issue was first observed/introduced. Nothing to do with how you make your patches!
#8
in reply to:
↑ 7
@
11 years ago
Replying to sabreuse:
The version in the trac header refers to when the issue was first observed/introduced. Nothing to do with how you make your patches!
So now that the patch doesn't have to do with display_name
anymore (since it isn't getting a pass), would it be changed back to trunk?
Thanks for tolerating my ignorance!
Replying to aubreypwd:
> Since http://core.trac.wordpress.org/attachment/ticket/16366/16366.diff core has added:> {{{> 'ID', 'user_login', 'user_email', 'user_url', 'user_nicename'> }}}Sorry, I don't actually think this is true. My mistake.