[wp-trac] [WordPress Trac] #29608: wptexturize messes up shortcode with parameter meta_compare=">="

[WordPress Trac]

#29608: wptexturize messes up shortcode with parameter meta_compare=">="
-----------------------------------------------+---------------------------
 Reporter:  bobbingwide                        |       Owner:
     Type:  defect (bug)                       |      Status:  reopened
 Priority:  normal                             |   Milestone:  Awaiting
Component:  Formatting                         |  Review
 Severity:  normal                             |     Version:  4.0
 Keywords:  needs-patch wptexturize 4.2-early  |  Resolution:
                                               |     Focuses:
-----------------------------------------------+---------------------------

Comment (by bobbingwide):

 OK, I have reviewed miqrogroove's blog and appended my comments, which
 were to agree on implementing the filters using different priorities.

 I have developed a local patch that

 1. implements the priority change
 2. supports ‘no_texturize_shortcodes’
 3. and replaces wptexturize with a new filter function that
 a) detects no texturize tags created around shortcodes which don’t like
 having their output texturized AND
 b) calls a stripped down version that doesn’t do any regex processing on
 shortcodes…

 It is currently a combination of one of my plugins and some changes in
 formatting.php

 Changes are:

 do_shortcode_tag() now wraps the result of a 'no_texturize_shortcodes'
 shortcode with
 <!--notext:--> and <!--dotext:-->

 the replacement for wptexturize() loops through the output finding
 notext:'s and dotext:'s

 - stuff before a notext: is passed to the stripped down texturize function
 - everything between notext: and the next dotext: is left as is
 - then the loop continues after the dotext:

 In my solution I also reprioritize wpautop() - invoking it so that it
 doesn't convert newlines to <br />.
 I don't call shortcode_unautop() either.

 I'm now in the process of moving the plugin code into core so that I can
 run unit tests.
 But I'm happy with what I see. My shortcodes work as they did in 3.9 and
 wptexturize logic works as well.

 Another option that I discussed ( with johnbillion ) was to implement a
 solution that supports condition expressions. LT, LE, EQ, GE, GT etc... I
 can develop this solution for my own code, OR it could be implemented in
 WP_Query. Comments?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29608#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform