[wp-trac] [WordPress Trac] #63948: Distinguish between “Link Preview Card” and “Embed WordPress (full post)”

[WordPress Trac]

#63948: Distinguish between “Link Preview Card” and “Embed WordPress (full post)”
-------------------------+------------------------------
 Reporter:  kimjiwoon    |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Embeds       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by kimjiwoon):

 I am currently deeply immersed in the connection between the Fediverse and
 WordPress. Regardless of personal preferences, this is also in line with
 Automattic’s direction.

 [https://github.com/Automattic/wordpress-
 activitypub/issues/2157](https://github.com/Automattic/wordpress-
 activitypub/issues/2157)
 **Reader: Add support for link previews**

 > Personally I still don't see a need for such functionality and there
 haven't been any additional feature requests for this since the above
 ticket. And plugins like [https://wordpress.org/plugins/visual-link-
 preview/](https://wordpress.org/plugins/visual-link-preview/) and
 [https://wordpress.org/plugins/link-preview-
 cards/](https://wordpress.org/plugins/link-preview-cards/) have very few
 installations.

 My preference is not to inflate functionality through additional plugins,
 but rather to have link previews supported natively at the core level,
 ensuring clean and consistent behavior across the entire WordPress
 ecosystem.

 The current level of demand might not be high enough to justify standalone
 plugins, but that does not diminish the value of having this as a baseline
 feature in core.

 Full-text embedding is already possible via WordPress’s Mastodon proxy.
 This is exactly why I believe improving the embed structure in WordPress
 core itself is necessary to provide seamless support by default.

 ---

 Thank you for pointing me to #32955 and for highlighting the plugin
 landscape. I agree that historically, “oEmbed vs. Open Graph preview” may
 have felt like duplication, which is probably why the feature never gained
 traction in Core.

 However, the situation today is slightly different:

 1. **We already have conflation in practice.**
    What we call “Embed WordPress” currently behaves like a **link
 preview** (title + excerpt + image), but does not actually deliver the
 post body. This creates ambiguity both for authors and for users consuming
 embeds.

 2. **Other ecosystems draw a clear line.**
    Mastodon (and more broadly, ActivityPub contexts) explicitly separate
 `PreviewCard` (Open Graph) from the `Note`/`Article` body. WordPress today
 does not make that distinction, which causes confusion when bridging
 across platforms.

 3. **The demand is not just stylistic, it’s semantic.**
    A “preview” and a “full embed” serve two different purposes. Conflating
 them into a single oEmbed-like behavior leaves us with inconsistent UX
 (e.g., Avada case, where the entire theme shell tries to render).

 4. **Opt-in solves the risk.**
    I agree that site owners would not want their content fully embedded
 without consent. But the solution is to treat **“Full Post Embed”** as an
 explicit, opt-in mode for WordPress targets only. By default, all external
 URLs would continue to resolve to a **Link Preview Card**.

 So rather than proposing “three competing implementations,” the proposal
 is:

 * **Preview Card** = lightweight, Open Graph–driven (consistent, theme-
 agnostic).
 * **Full Post Embed** = opt-in for WordPress posts only (fetch post
 content, not site shell).
 * **oEmbed** continues to power both under the hood, but with explicit UI
 labels that separate the semantics.

 This reframing means we are not introducing “another” embed type, but
 clarifying existing ambiguities and giving authors predictable control.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63948#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform