Ticket #2713 (closed defect: fixed)

Opened 3 years ago

Last modified 3 months ago

patch wptexturize to leave text inside (code|pre|kbd|style|script|samp) tags alone

Reported by: n8v Assigned to: anonymous
Priority: normal Milestone: 2.6.1
Component: Template Version: 2.1
Severity: normal Keywords: has-patch
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 &#8211;foo</samp>
baz &#8211;foo
</pre>

I tested my patch with the sample above, and confirmed that it resumes texturizing after the closing pre tag.

Attachments

detexturize_patch.diff (1.6 kB) - added by n8v on 05/09/06 22:48:32.

Change History

05/09/06 22:48:32 changed by n8v

  • attachment detexturize_patch.diff added.

05/26/06 19:29:03 changed by n8v

  • version changed from 2.0.2 to 2.1.

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)

08/31/06 08:58:23 changed by _ck_

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.

11/07/06 22:16:04 changed by n8v

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

02/16/07 18:21:06 changed by n8v

  • keywords set to has-patch.

02/16/07 22:24:25 changed by foolswisdom

  • milestone set to 2.2.

03/27/07 22:04:59 changed by foolswisdom

  • milestone changed from 2.2 to 2.3.

08/31/07 20:40:14 changed by Albertane

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.

09/13/07 05:11:11 changed by ryan

  • milestone changed from 2.3 to 2.4.

02/12/08 10:14:31 changed by pishmishy

  • 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.

08/11/08 01:21:15 changed by azaozz

  • status changed from new to closed.
  • resolution set to fixed.
  • milestone changed from 2.9 to 2.6.1.

Appears to have been fixed some time ago.

08/11/08 21:15:58 changed by n8v

Yay!! Fix confirmed.