Making WordPress.org

Opened 8 years ago

Closed 8 years ago

#1856 closed defect (bug) (fixed)

Attendance UI search does not handle apostrophes

Reported by: johneckman's profile johneckman Owned by: kovshenin's profile kovshenin
Milestone: Priority: normal
Component: WordCamp Site & Plugins Keywords: has-patch
Cc:

Description

If your attendee name is O'Brien or O'Donnell - you won't be able to find them in the Attendance UI

If you just search for Brien or Donnell it will find them, but if you try to type O'Brien it will not.

Attachments (3)

Screen Shot 2016-07-23 at 12.05.05 PM.png (101.3 KB) - added by johneckman 8 years ago.
showing the o' attendees
Screen Shot 2016-07-23 at 12.04.57 PM.png (49.1 KB) - added by johneckman 8 years ago.
Showing the filter not finding them
fix.diff (806 bytes) - added by jeffSLOfish 8 years ago.
Fix for this bug.

Download all attachments as: .zip

Change History (8)

@johneckman
8 years ago

showing the o' attendees

@johneckman
8 years ago

Showing the filter not finding them

#1 @iandunn
8 years ago

  • Owner set to kovshenin
  • Status changed from new to assigned

#2 @kovshenin
8 years ago

  • Keywords good-first-bug added

#3 @iandunn
8 years ago

  • Keywords needs-patch added

@jeffSLOfish
8 years ago

Fix for this bug.

#4 @BandonRandon
8 years ago

  • Keywords has-patch added; good-first-bug needs-patch removed

Tested Patch, works as expected. cc @kovshenin

#5 @coreymckrill
8 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 5531:

WordCamp: Handle apostrophes in Camptix Attendance UI

Apostrophes in the search string are getting escaped when they are first
submitted, which means they are getting escaped again when they go
through $wpdb->prepare etc. So strings that have an apostrophe (like
"O'Brien") will not turn up the expected results in the query.

This fixes the issue by stripping slashes before the string goes through
esc_like and $wpdb->prepare. It uses wp_unslash instead of the
stripslashes in the original patch simply because using WP-specific
versions of functions is a best practice.

Stripping slashes in this instance doesn't cause a vulnerability because
the escaping is handled again later by esc_like and $wpdb->prepare.

Props jeffSLOfish
Fixes #1856

Note: See TracTickets for help on using tickets.