Originally posted on make.wordpress.org/core.
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 in HTML.
- 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. 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 galery shortcode 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 that can have display information. Again, think about how images are embedded in HTML.
<figure class="alignright"> https://example.com/galleries/yummy-chocolates/ <figcaption>Chocolates.</figcaption> </figure>
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, 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!