A new embed parser has been introduced in Embedder version 1.3, as an alternative to the native WordPress shortcode parser Embedder was using up to this point.
While it is only an option at the moment, the Embedder plugin will eventually move over to this parser (in version 2.0, most likely) and drop support for the old parser. Therefore I recommend that you begin using the new parser (just select the option at the top of the main Manage Embeds page) as soon as possible.
The new parser solves the following problems the old parser had:
- Nested embeds did not work properly (e.g. [more]…[more]…[/more]…[/more]).
- Adjacent embeds did not work (e.g. [image_1][image_2] would only embed [image_1]).
- Embed tags were case sensitive, meaning that all tags had to be in lower case.
- Embeds nested within other shortcodes might not work (depending on what the other shortcode did).
Not only that, but the new parser will also make it easier to add new Embedder features going forward, including validation of embed attributes (important if you want to allow embeds in comments, for example).
The new parser is functionally identical to the old one with the following exceptions:
- The nested embed workaround I added to the old parser (i.e. adding a digit to the end of the nested embed—[more]…[more2]…[/more2]…[/more]) will no longer work. Since nesting is now fully supported, all you have to do is remove the trailing digits in the nested embeds and it will work with the new parser.
- Self-closing embed tags of the form [emb/] will no longer be recognized. Use [emb] instead.
- Embed tags will no longer be required to be in lower case.
Otherwise, your existing embeds should work with the new parser, unchanged.
New Embed Attribute Format
There is one other change you do need to know about, however, and that is the embed attribute format is also changing:
- Old Format: %attr_name=def_value%
- New Format: {$attr_name=def_value}
In addition all reserved attribute names will have an underscore as a prefix. At the moment, %content% is the only reserved attribute name, and that will become {$_content}.
For example, an existing embed containing attributes like this:
<span style=”color:%c=blue%“>%content%</span>
Will look like this:
<span style=”color:{$c=blue}“>{$_content}</span>
using the new attribute format. As you can see, it is a very simple change.
(Note: there are several more reserved attributes in the new parser, which I will document once they have been tested.)
This is an improvement on the old format for a couple of reasons:
- It is easier to see where the attributes are in the embed value
- There is less chance that the {$…} format will be confused with the HTML in your embed value.
The existing format (%…%) will continue to work until version 2.0 (I will give plenty of warning before 2.0 is released) and I should be able to have the Embedder plugin automatically convert all your embeds to the new format when the time comes.
I would, however, recommend that you begin creating all your new embeds using the new format from this point on.
User Functions with the New Parser
If you are using an embed that calls out to a user function when you switch to the new parser, you may notice a couple of differences:
- If you dump out the $value parameter, you will find that all the attributes in the embed (if any), have been converted the new attribute format internally, e.g. {$_content}, when your user function is called—even if you are still using the old %…% format. This is because the parser requires the attributes to be in the new format before the parsing commences. But unless you are actually substituting the parameters yourself instead of letting the parser do it, then it won’t affect you.
- The array of attributes will contain a number of extra reserved attributes that the parser adds. All existing attributes will still be present, of course. Again, unless you are doing something extremely unusual in your code, this should not require any changes on your behalf.
Performance
Finally, a short word about performance. WordPress shortcodes are implemented using regular expressions, which means that they are processed very quickly. The new parser Embedder is using is a full-blown parser, which even though it has been optimized for speed, means that there will be some slight performance hit when you switch over. But I am convinced that the benefits the new parser brings with it are worth the small performance cost it causes.
However, I suspect that most people will not notice the difference, since when processing normal post-sized chunks of text, it is still very fast, especially when compared to all the other processing WordPress does when building a web page. And if page-building time is a concern, then you should probably be using a page caching plugin anyway, which would completely eliminate use of the Embedder parser 90% or more of the time for busy blogs.