Components in Posts
Embed reusable, branded site components inside blog posts with <bo-component>. Resolved server-side from your component library and rendered on your custom domain.
Embed reusable, branded site components directly inside a blog post body with a single tag:
<bo-component slug="pricing-table"></bo-component>
Components let you reuse rich, owner-authored building blocks — pricing tables, CTAs, testimonials, animated hero blocks — inside posts without pasting raw HTML into every article. Update the component once and every post that references it updates too.
How it works
A blog post is written in Markdown. When it renders, any <bo-component slug="..."> reference is resolved server-side into that component's HTML and CSS, scoped to your site's own library (the components you manage under Admin → Components). Only components that exist and are enabled render; everything is tenant-isolated, so a post can only pull in components belonging to its own site.
Animations
You don't need to know how an animation is made or learn any syntax — just describe what you want, and it's built and dropped into your post for you.
Example. Say you have a static "Export / eject site" card and you want it to feel alive. You ask:
"Animate my eject card — when you hit Eject, show the files collecting into the zip."
…and you get back a polished animated version: the Eject button presses, each file streams in with a green check, and they pack into your-site.zip. No tools to learn, no code to write — you describe the motion, and the right thing is produced and embedded for you. It plays inline in the post and works anywhere your post is published.
The same goes for any motion: an animated explainer, a feature walkthrough, a looping hero. Describe it in plain language; the system picks how to build it.
Live and responsive
Animated components play live in the post — crisp at any size, not a flat video. They also adapt to the screen: a component can carry a desktop and a mobile version, and the right one is shown automatically based on the reader's screen width (and switches live if the window resizes). You don't wire any of that up — autoplay, looping, and the desktop/mobile switch are handled for you.
Where components render — custom domains only
Components (and the older richembed blocks) render only when the post is served from your site's own custom domain — e.g. yourbrand.com. They are intentionally not rendered on a *.blackopscenter.com address.
This is a security boundary, not an arbitrary limit. A component injects rich, owner-authored HTML; isolating it to your own domain keeps it from ever running on the shared platform origin. Because the feature is offered to sites with a custom domain, most readers never encounter the restriction. When it does apply — for example if a post is opened via your *.blackopscenter.com address instead of your custom domain — the component is replaced by a small placeholder rather than disappearing or breaking the page:
- Author / preview view: an actionable note telling you which component was hidden and where to see it.
- Public reader view: a neutral “interactive content isn’t available on this page” notice.
Tip: If you reach a post through your
*.blackopscenter.comaddress and see placeholders, open the same post on your custom domain — that's where components render.
Usage
-
Create the component once under Admin → Components (give it a lowercase, kebab-case
slug, e.g.trial-cta). -
Reference it anywhere in a post body:
<bo-component slug="trial-cta"></bo-component> -
Publish the post and view it on your custom domain.
Components are inlined at render time, so editing the component later updates every post that references it — no need to re-edit posts.
Authoring via MCP / API
post_posts and patch_posts_by_id accept <bo-component> references in the post content like any other Markdown. If you create or update a post that contains a component (or a deprecated richembed block) on a site that is not on a custom domain, the response includes a warnings entry letting you know it won't render until a custom domain is connected — so you learn at authoring time, not after publishing.
Configuration
- Slugs must be lowercase kebab-case and unique per site.
- Enable / disable a component to control whether it renders anywhere it's referenced — this is also the kill switch if a component ever needs to be pulled.
- Custom domain must be connected and serving the site for components to render.
Deprecation: richembed
The older ```richembed fenced-block mechanism is deprecated. It is now gated to custom domains like components, and shows the same placeholder elsewhere. Move richembed content into a reusable <bo-component>.