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.
Hi, I discussed quite a few of the challenges associated with shortcodes, texturize and autop with johnbillion on Saturday at WordCamp London contributor day. He suggested that I raise a new TRAC containing my proposals, but I see you have already raised https://core.trac.wordpress.org/ticket/29661 so maybe we can continue the discussion there.
My proposal is to take a step back and start again, with a new approach to filter priorities; a solution which you have also suggested. I believe the problem with ‘no_texturize_shortcodes’ can be handled by pre and post processing, introducing a new string that wptexturize() will respect and eventually remove.
In this solution wptexturize() will not have to worry about shortcodes at all.
There should also be fewer problems with handling “just in time” shortcodes which aren’t registered until a shortcode is detected.
We might also be able to find a better solution for handling shortcode expansion of nested content.
Herb
Hi Herb, thank you for writing. These are all legitimate possibilities. Changing the filter priorities would have some good advantages. While my proposal above did have merit when I wrote it (before 4.0.1), I think the overall direction has changed and it might not be possible to allow all special characters in the future. Likely there will be more focus on increasing performance in wptexturize and potentially removing the restrictions for unregistered shortcodes. So I agree with most of your ideas, and we should not get our hopes up about ticket #29661.
Just to let you know that I have now developed a 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’s not ready for submitting as a patch. I’ll try to run unit tests.