Docs

This page isn't translated yet

Listings and sharing

The posts block, share buttons and related posts.

On this page

Posts reach visitors through listings, through the share buttons under each post, and through the related-posts rail.

The posts blockLink to this section

A built-in Posts Lexical block lets editors drop a listing into a page body — the same listing capabilities as the Archive template (automatic query or fixed picks, view, highlightFirst, the lead posts split leadCount + leadView, Row dividers dividers, loading strategy). It behaves like a Section block: it is a root-level (page-body) block only — offered in the root editor's BlocksFeature, never inside another block's region/fragment/slot body — and carries the same section-level presentation controls as a Section: a color system / theme (theme), a background variant (layoutBg), and (in an Advanced Settings drawer) a padding slider — defaulting to 0 for the block — plus the per-axis Items Gap X (gapX) / Items Gap Y (gapY) sliders (the listing gap). The block's drawer additionally carries the block-only presentation controls — Media aspect ratio, Thumbnail width + Body alignment (Row layout), and Media ↔ body gap — all documented under the Archive listing field-set; the archive listing omits them. The converter wraps the listing in the same <Section> (which renders its inner container), so the rendered structure is Section › Container › Posts and choosing a color system / background / padding on a posts block produces the identical result it would on a Section block. It has no search/filter UI — those controls live on the Archive template's hero. The block only exists when the module is enabled (gated at registration and in the root editor's BlocksFeature). Its server-resolved query result is injected by populateLexicalPostsBlocks (a pre-pass mirroring populateLexicalFormBlocks) before the sync Lexical converter renders the listing through <PostsList> inside that section.

Composable chrome (prepend / append). The block carries two optional region-level Lexical editors — a Prepend rendered above the listing and an Append below it — so a page composes titled "Latest videos" / "Articles & News"-style sections with a hand-built heading + CTA instead of fixed fields. In Prepend, drop a Stack (row, space-between) holding a Heading and a "See all" Button; in Append, a centered Button for a bottom CTA. The region level gives Heading + Button + Stack blocks but not the posts block itself (no recursive nesting). The converter pre-renders both editor states to JSX (via nodesToJSX) and PostsBlockView lays them out prepend → listing → append with a token-driven <Stack gap>; when neither is set the listing renders bare (existing blocks unchanged). This mirrors the Archive template's page-level prepend / append — the block just owns its own pair.

Both are editor-controlled in General Settings → Posts with code-level defaults from posts.*:

  • Share buttons — toggle share.enabled, pick networks (facebook, x, linkedin, whatsapp, email, nativeShare), and choose the bar position (inline / sticky-bottom / floating-sidebar) + button style (icon / icon-label / pills) — the same knobs as the code-level posts.share default (table above). Rendered after the post body by the Single-Post template via ShareButtons. An empty network list hides the control. nativeShare self-hides when the Web Share API is unavailable.

  • Related posts — each post has a relatedPosts relationship, and General Settings → Posts → Related posts controls how the rail is populated:

    • Strategy — Manual, then automatic (default; hand-picks win when set, otherwise automatic), Manual only (only hand-picks, never auto-relate), or Automatic only (ignore hand-picks, always auto-relate).
    • Automatic match — which taxonomy automatic matching uses: Tags or category (default), Tags only, or Category only. Hidden when the strategy is manual-only.
    • Maximum posts — how many to show (default 3).

    resolveRelatedPosts reads this config (via getPostsDisplaySettings) and branches accordingly. Automatic matching queries each taxonomy dimension separately and merges newest-first + deduped (the shared listing query ANDs its filters, so a single call would require BOTH a shared tag AND the same category). The defaults reproduce the original behavior exactly, so an un-configured project is unchanged.