When WordPress first introduced its Shortcode API, it included an all-too-simple line of code that was supposed to help curly quotes not appear inside of the shortcode attributes while still adding curly quotes outside of the shortcodes. But there were several known problems with this one line of code, such as what would happen if a URL contained square braces, and what would happen if a plugin author wanted to use HTML inside a shortcode.
In version 4.0, I made a substantial effort to fix these problems, but it resulted in some new limitations being placed on the ways shortcodes could be used. Although I couldn’t find any documented examples or official support for the HTML features, I did hear from several members of the WordPress community who enjoy the full power of customizing their website HTML by using shortcode attributes and HTML values.
My proposed solution is to write a new parser function that will exactly identify the shortcodes and HTML elements being used, so that the function wptexturize() will finally be able to create its curly quotes without interfering with shortcode features. Click on the diagram to see how this new code works.
Advantages of the parser function strategy:
- Official support for full HTML and related special characters inside of shortcode attributes.
- No more problems trying to add curly quotes in plain text phrases like [ This is where I want my “quotes” ].
- The ‘no_texturize_shortcodes’ filter still works to disable curly quotes in specific enclosed content.
- There are no changes to the way website authors and plugin authors use shortcodes in blog posts.
- Nested shortcodes, special characters, and curly quotes can still work together, and it just requires an extra call to wptexturize().
Disadvantages of the parser function strategy:
- The function occupies roughly 300 lines of code and may seem internally complicated.
- The function runs about 2.5 times slower than the same bits of code in version 4.0.
- Shortcode registration is strictly enforced, which is an issue with old versions of the Jetpack plugin.
One alternative solution to be considered is simply adjusting the WordPress filter priorities so that the Shortcode API processes all of the shortcodes before wptexturize() gives the input its curly quotes treatment. This seems like an easy idea at first, but it comes with its own set of disadvantages. If shortcodes are processed before wptexturize(), then the ‘no_texturize_shortcodes’ filter will stop working or will be removed entirely. Plugins that rely on the existing order of filters could be broken by such a change. Plugins would also lose the ability to control whether or not the shortcode output becomes modified by wptexturize().
Clearly, there is no easy solution, and many tough decisions will have to be made to help fix these old bugs.