Opened 14 years ago
Last modified 18 months ago
#2776 new defect (bug)
Most content is double-escaped in the database
Reported by: | DJPaul | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Contributions | Priority: | major |
Severity: | normal | Version: | |
Component: | Core | Keywords: | |
Cc: | nacin |
Description (last modified by )
Throughout BuddyPress, a lot of input (i.e. xprofile data, group name, group description) is being stored double-escaped in the database. This is demonstrated by creating a group with an apostrophe in its group description field, and then by creating a regular WP post with the same phrase, and comparing the contents of the database tables.
This is because WordPress, in wp_magic_quotes(), escapes everything in $_POST, $_GET and $_COOKIE. BuddyPress needs to stripslashes() on relevant content before we put it into the database, as $wpdb->prepare() escapes the input again.
This problem hasn't been very visible due to stripslashes() being added to most template tag's output functions, and a few local workarounds, but ticket #1209 led me to find this issue.
Attachments (4)
Change History (17)
#1
@
14 years ago
The patch for bp_core_action_search_site fixes this issue when performing a search from the site-wide search box in BP-Default's header, as well as improving logic of the patch and catching a few WP_DEBUG warnings.
#2
@
14 years ago
bpcore-2.patch is updated to include a bit I missed including in the patch, and also handles the other directories' search boxes in the same way.
#6
@
14 years ago
xprofile-1 address double-escaping of data in the database throughout the xprofile component.
This patch also has fixes for #2694 and #2777 as they are related. It also reverts [3509] #2283 as the issue is best addressed when data is put into the database, rather than on output.
I have tested it a lot and it seems to work as expected, both in the database as well as in the front-end and admin UIs. I have not tested the impact of the patch on existing xprofile data; search will not work on previously-escaped characters, such as apostrophes, but we need to check if we get any slashes output on the front-end and admin UIs. If so, we may need to (re)add extra stripslashes() to maintain this backwards compatibility.
#10
@
14 years ago
- Milestone changed from 1.3 to 1.4
Yes, not enough time to go through this properly.
bp_core_action_search_site