#17571 closed defect (bug) (invalid)
bad double quote replacement in wp_texturize
Reported by: | csanquer | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | |
Component: | Formatting | Keywords: | has-patch dev-feedback wptexturize |
Focuses: | Cc: |
Description
Bug seen in Wordpress 3.1.2. with buddypress 1.2.8
Some database fields that contain a string like this 'a string with \"escaped double quotes\"' are displayed this way : 'a string with >>escaped double quotes>> ' instead of 'a string with <<escaped double quotes>>'
The bug come from wp_texturize function in wp-includes/formatting.php .
I join a patch to resolve this issue.
Attachments (5)
Change History (22)
#2
@
13 years ago
SergeyBiryukov, he says about not double escaping, but that direction of quotes are not correct. This bug makes much work to me and probably to other wp users.
i can show a test case:
"<a href="http://example.com">123</a>"
shown as
«123«
(in wp 3.0.4)
#6
follow-up:
↓ 7
@
12 years ago
- Keywords needs-patch added; has-patch removed
Patch is no longer valid for 3.4.0. This was invalidated by #19602. The example string:
"<a href="http://example.com">123</a>"
Is broken down to:
Array ( [0] => " [1] => <a href="http://example.com"> [2] => 123 [3] => </a> [4] => " )
The beginning and ending quote are treated equally by the replacement regexes, so they both come out as an opening curly quote.
#7
in reply to:
↑ 6
@
12 years ago
- Keywords has-patch added; needs-patch removed
Replying to kurtpayne:
This was invalidated by #19602.
I was wrong about this. This ticket has 2 example strings given that produce undesired output. One is HTML ("<a href="...">link</a>"
) and one is escaped quotes (double \"quotes\"
).
This patch will not work with the HTML input. There is a separate ticket for this at #4539.
This patch will work with the escaped input. The patch has been refreshed for 3.4 and the unit tests pass, too.
#10
follow-up:
↓ 11
@
12 years ago
- Keywords needs-unit-tests removed
Patch is fine, but I'm curious — Why should quotes ever be escaped, and why would we want to then go ahead and curl them? Obviously that they're curled in the same direction is the bug we're trying to fix, but I'm just wondering why they shouldn't just become ".
#11
in reply to:
↑ 10
@
12 years ago
Replying to nacin:
Patch is fine, but I'm curious — Why should quotes ever be escaped?
Original reporter claims "Some database fields that contain a string like this."
Are you concerned that having wptexturize()
eat "backslash-quote" and spit out "curly-quote" could be seen as a bug?
Obviously that they're curled in the same direction is the bug we're trying to fix
Alternate patch forthcoming.
#13
@
12 years ago
- Keywords wptexturize added
- Milestone changed from 3.4 to Future Release
While it is backed up by unit tests, it is too late to make a change for an edge-case issue with texturize.
I didn't understand the nature of the bug report here originally. The issue appears to be that \"
gets curled in the incorrect manner. When are backslashes ever going to be used? If it's ending up in the database, we should be looking at storage and retrieval, not texturize. Should the quote be curled in this case at all? Should the backslash be quietly stripped, or should it be kept? Are there any performance implications of the negative lookahead here?
Where exactly do you see those double-escaped values?