After upgrading to WordPress 4.4 on a couple sites I manage, I noticed that some shortcodes weren’t rendering (“Rendering” is the fancy word I use to describe what happens when WordPress changes a shortcode into whatever text or code that shortcode is supposed to become). With no changes to the text in pages or posts, the shortcodes were simply being displayed in their shortcode form instead of interpreted and rendered.
Here I present an example. I have a private post on this site which I use to test my Responsive Video Light plugin. It’s simply two shortcodes – one for YouTube and one for Vimeo.
Curiously, when this post was viewed, the top shortcode would not render, but the bottom one would. It’s not a syntax problem, they’re both correctly formed, or at least appear to be. After much Google-foo, I finally stumbled across an article that instructs you to re-type any spaces in your shortcodes not working after upgrading to WordPress 4.4. I thought to myself “no, that can’t be it,” but decided to give it a shot anyway. Lo and behold, it worked!
To figure out why this was so, I reverted to the earlier, non-working version of my test post, and copied and pasted its contents into a file that I could inspect with a hex editor. My hunch was that the spaces were in fact different, but the difference couldn’t be seen by eye. Take a look at the following screenshots. This first one highlights the space between “responsive_youtube” and the video URL in the shortcode, which is the one that doesn’t render. This space is not a simple single-byte ASCII space (0x20), but is actually a two-byte sequence, 0xC2 0xA0. Google reveals that is a Unicode symbol for a non-breaking space!
In this final screenshot, the highlighted part is the space between “responsive_vimeo” and the rest of its arguments. This is a true ASCII space (0x20), and so this shortcode renders properly.
I cannot imagine why upgrading WordPress would cause this. My hunch is that some older version of TinyMCE (the visual editor) inserted the Unicode space instead of the ASCII space. Wordpress comes along and adds some Unicode support in a parser somewhere in the newest version, and now that no longer sees a Unicode non-breaking space as identical to a simple ASCII Space. Things break, nerds weep and shake their fists. Oh well. At least I know what’s causing it – I won’t dig any further into WordPress to find the root cause – I’ve spent enough time just figuring this much out. Enjoy your newfound knowledge ;-)