The WordPress Shortcode API is going through a great deal of a refactoring process, which was necessary since a long time ago. Though still in its initial stages, one of the main goals is to provide more strict guidelines about the way shortcodes should be used, specially regarding what can and what cannot be passed as attributes, being HTML code the more complicated case. This is part of an ongoing discussion that began when WordPress 4.2.3 was launched, and lots of sites broke because they were using shortcodes in a way the update didn’t support anymore. I’ll skip my point of view about the way the update was managed by the Core team, and I won’t dare to say that there’s a “wrong” way to use shortcodes, since I think that any provided tool should be used in any possible way that’s allowed by its internal logic. I’m just gonna stick to talk about a practice that can help to prevent some issues with the Shortcode API. What do I mean with this? I know for a fact (because I published a couple of plugins and people often ask me about this) that a lot of developers write shortcodes right inside their template files. For example, I’m used to see things like this inside templates:
Share This