The idea is that any objects embedded in a post’s content have their own home and should be seen as separate resources. Data would be stored elsewhere.
This approach could be good for:
- Forms such as contact forms, surveys and polls.
- Visualised data such as diagrams, charts, graphs and tables.
- Lists of items such as a galleries, playlists and lists of posts.
- Albums or manually composed collections of items where the presentation is uniquely different from a normal list.
- Any content that needs to be reused or organised separately. Anything that can be re-sourced. 😉
- Any external resources.
This is not good for:
- Text conversions.
- External embeds work similarly in WordPress through oEmbed.
- Images, audio and video are embedded by their URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers..
- Media have their own “attachment” post type in WordPress.
- Many plugins already have a separate post type to store their data.
- I’ve seen some news media do this already for things for like graphs (post, resource).
- A URL (or “link”) is a concept that is already familiar to many users.
- URIs are designed for these sort of things. Think about images — it would follow the same paradigm.
- The content is treated as a separate resource, and can be reused, just like shortcodes, but it forces separation.
- WordPress allows you to create “pretty” semantic URIs, so the resource can be described for a better experience.
- A cool side effect is that others could embed these easily on their site through oEmbed. WordPress already supports this.
- If there’s a problem, the URL will act as a fallback.
A quick way to implement this for WordPress 4.4 and higher is registering a new post type. This will handle most things, you just need to provide a custom embed template with the
template_include 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.. An external resource can be filtered with the Embed API and TinyMCE View API, even if it doesn’t support oEmbed.
Challenge: Variants and Settings
Either each variant of an resource needs its own ID, or settings could be passed with a query string. I think the use of settings should be minimised — for example, columns for a gallery object may be better set per ID. Settings can certainly be useful for things like autoplay, for example YouTube allows you to set the start time.
This is great if the URL is added on a separate line, but aligning the object is not evident. This is a challenge for shortcodes too. At the moment the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. galery 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. does not allow you to allign it, and the caption shortcode has an attribute for it. Similarly the URl could have a query parameter for alignment, but that doesn’t sound ideal. Alternatively the paragraph could be floated, or it needs to be wrapped in a `div` element to float mid-text. Another approach is to always wrap the URLs in a (custom) 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.) that can have display information. Again, think about how images are embedded in HTML.
Shortcodes would have a similar problem, though slug clashes are probably more likely. Ideally plugins should use their own prefix, but this may be seen as ugly. Another way to avoid clashes with other post types is a sub type for “attachments” or “resources”.
Challenge: Extra Queries
I don’t see this exactly as a challenge, as it’s the nature of the concept, but it may be used as an argument against it. Many shortcodes already make use of custom post types to store data and embedding media (or anything else) also requires extra queries. If and how this should be cached is another problem.
I would love to hear your thoughts on this alternative, especially from those who use shortcodes for this type of objects in the post content. If you already use a custom post type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept., why not take advantage of embedding instead of creating shortcodes? If you want to embed external resources, why wrap it in a shortcode?
If you have other alternatives, I’d love to hear about those too!