#2713 closed defect (bug) (fixed)
patch wptexturize to leave text inside (code|pre|kbd|style|script|samp) tags alone
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 2.6.1 | Priority: | normal |
Severity: | normal | Version: | 2.1 |
Component: | Template | Keywords: | has-patch |
Focuses: | Cc: |
Description
My issue was initially similar to ticket #2647 but I fixed it a different way (see patch) because I wasn't sharp enough to spot the missing parenthese.
Also, I noticed that it didn't seem to properly skip texturizing text inside tags nested within code/pre/etc. blocks. So for example, even after applying Justinsomnia's patch from #2647 :
<pre> foo --bar <samp>bar --foo</samp> baz --foo </pre>
gets texturized as:
<pre> foo --bar <samp>bar –foo</samp> baz –foo </pre>
I tested my patch with the sample above, and confirmed that it resumes texturizing after the closing pre tag.
Attachments (1)
Change History (12)
#2
@
19 years ago
Here's a vote for this improvement.
People claim that wp-texturize is 20% faster than smartypants but wp-texturize makes a much bigger mess than smartypants. Your fix addresses one part.
this ticket addresses a speed improvement that I am not sure has been applied yet either.
Now if someone could just fix how texturize gets endquotes wrong half the time. It's a mess and should be embarassing for a 2.x release.
#3
@
18 years ago
I reapplied this patch to my WordPress 2.1-alpha3 release (from the Subversion trunk) but I guess it should apply to 'wp-includes/formatting.php' now, instead of functions-formatting.php as the diff suggests.
This is the Unix syntax to apply the patch:
cd wp-includes patch formatting.php detexturize_patch.diff
#7
@
18 years ago
Patch fails on 2.2.2.
$ patch formatting.php detexturize_patch.diff patching file formatting.php Hunk #1 FAILED at 3. Hunk #2 FAILED at 37. 2 out of 2 hunks FAILED -- saving rejects to file formatting.php.rej
I think this might be causing some of my problems with <pre> on my blog. It'd be great if this were fixed. Thanks.
#9
@
17 years ago
- Milestone changed from 2.5 to 2.6
Not entirely sure if this is a bug fix and not an enhancement. Bumping up to 2.6 - if you can write a working patch bring it back to 2.5.
so, I submitted this problem/fix almost a month ago and haven't seen any change here. Did I miss something? Should I assign it to myself? How can I check to see if it has been committed to the repository?
(the patch works with 2.1 too so I'm changing that field here)