In his ‘WordPress Core Proposal: Shortcode Tracking’ yesterday, Eric proposed what I think would be an incredibly useful feature for WordPress core.
Adding better visibility for shortcodes to core is useful beyond just being a developer feature. It will allow us to build simple, usable interfaces for site owners. This will enable them to maintain their sites better in the long-term without needing as much developer support for plugin maintenance or swaps.
It’s also a time-saver for clients and devs. Manually removing shortcodes is something I’ve done manually in the past, and it’s somewhat error-prone due to the use of regexes. A shortcode taxonomy would also allow some interesting combinations of shortcodes with post meta structures once those are enhanced.
I think the overhead of an additional taxonomy like this is negligible for typical/traditional blog sites and a positive shift for larger sites with dedicated admin servers and read/write split DBs.
Use-Case #1 – Fragment Caching
Writing to the DB may be heavier than pure reads, but since this would only happen on ‘save’ it’s a relatively rare event. In particular, by updating this taxonomy during saves the work shifts from every-time frontend requests to one-time backend events.
This is a positive shift for site users and improves our ability to move to fragment caches. For example, the shortcode taxonomy would offer an easily-cached flag for has_shortcode( $code ). Caches could then have additional caching rules specific to content containing shortcodes. Or, the results of shortcode parsing could be implemented in a worker/scheduled event and cached separately from the post content*. Then on post generation the cached shortcode results could be imported instead of parsing the code.
(*I’m aware this could be done with transients at present, but that’s implementation-specific and not easy to pass to a worker process. This taxonomy would abstract implementation from the theme files and make things easier to pass to workers.)
Use-Case #2 – UX for User-Updates to Shortcodes
As plugins are updated their shortcodes are often extended with new attributes or options for existing attributes. The shortcodes saved to content, however, must be manually updated in order to take advantage of the new content.
Even worse is being forced to delete shortcodes when a plugin is uninstalled or isn’t updated to support a new version of WP.
These manual updates to shortcodes in content are a tedious task, and might even bring a site down. While developers will generally be able to perform these updates quickly with a few queries and a regex or three, typical site-owners can’t do this on their own. They currently rely on plugins that perform long-running queries (sometimes on their live DBs) and run regexes that occasionally partially or over-cut.
Having a shortcode taxonomy would make it easy to have a general-purpose shortcode editing/search/replace plugin. Or, every plugin that offers shortcodes could provide their own update & management interfaces or automate upgrades with narrower regexes.
Use-Case #3 – UX for Editing & Reporting on Shortcodes
How do users know how much they rely on a plugin’s shortcodes? Would they pay for a premium version if they realized 75% of their posts used a single plugin?
With a shortcode taxonomy plugins could easily offer analytics and reporting on their own usage (without crashing the DB). This might help drive purchases of premium plugins, or just help site owners know what plugins to move to ‘mu-plugins’ so their sites won’t break.
Use-Case #4 – Improving Related Posts
Related post interfaces are some of the more common and valuable plugins for publishers. Not all of them index shortcode content though. And those that do don’t have great ways of detecting when it’s changed.
Adding a shortcode taxonomy would enable related post plugins to offer options (included/excluded) for the indexing of shortcode content. Performance of relationships could also be improved and full re-indexes reduced by using this taxonomy.