We saw a great amount of feedback on the first draft of the Shortcode API Roadmap. The resounding concensus was that the shortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. syntax we already know and love should not be replaced.
Now we need to bring that enthusiasm and more feedback to the first official meeting to help create a second draft of the roadmap.
On Wednesday at 17Z, which is 9 Sep 2015 17:00.
It is scheduled in the #feature-shortcode channel.
In case you can’t make it to the meeting, here are some of the items up for discussion.
The biggest issue with keeping the BBCode style syntax is that we don’t have a scalable way to make these shortcodes work in PCRE. The current pattern searches for all registered shortcodes by name, because searching for matching pairs of braces leads to backtrack limitations and segfaults. If someone has an idea or knows a good library, now is the time to tell us! With that said, we are also bringing some new proposals of our own. One theoretical solution should make it possible to preview the first word of each shortcode tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) so that the full search pattern then only includes the names of shortcodes already found in the input, rather than the names of all registered shortcodes. This is the best idea so far and could be easy to implement.
HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. vs. Shortcode Syntax
We still want to expand the shortcode syntax to allow multiple enclosures. So which new tags would work best internally and still look nice for users? We are now thinking something more like this:
[shortcode] HTML [=part2=] HTML [/shortcode]
Let’s also have a brief discussion about preparing for the eventual removal of HTML-in-shortcodes and shortcodes-in-HTML combinations. As we saw in 4.2.3, it is better to plan for this rather than allowing it to become an urgent surprise update.
Version Issues and Breaking Things
We still need to plan out a change of filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. priorities so that shortcodes will be processed first, before paragraphs and curly quotes. How much impact will this have on plugins now that we will be changing the way existing shortcodes work instead of adding a whole new system? Is it adequate to offer paragraphs and curly quotes as an opt-in only feature?
Will we need weekly meetings after this first one?
Are there other tickets or features, such as nested shortcodes, that need to be roadmapped?