# Content Type: Contact Changes to how this Type behaves are requested through a GitHub Issue and implemented, together with this reference page, through the repository's normal workflow. See /_docs/posts for how Content Types, Roles, and Rank work in general, and docs/Internal/type-doc-templates.md for the Content Type Doc template this file follows. A way to get in touch — one Contact Content Element can hold several related entries at once (e.g. a Work and a Private Mail address under the same card), each rendered as an actionable link. ## Fields A Contact Content Element holds zero or more ordered **entries**. Each entry has: - **Kind** (mandatory) — one of a fixed, ordered list: Mail, Mobile (SMS Capable), Phone, Signal, Telegram, WhatsApp, Facebook, LinkedIn, Instagram, Home Page. - **Value** (mandatory) — the address, number, or service handle — never a complete service URL. Kartotek builds the actual link itself; pasting a full URL is rejected with an explanation, except for Home Page, where a URL/domain is exactly what's expected. - **Description** (optional) — free text describing the purpose of that one entry, e.g. "Work", "Private", "Press enquiries", "Booking". Repeated Kinds are allowed (e.g. two Mail entries). ## Handle storage and generated links The Value is stored as a bare handle, not a generated URL — Kartotek owns the canonical link template per Kind (`mailto:`, `tel:`, `wa.me/…`, `signal.me/…`, `t.me/…`, `instagram.com/…`, `facebook.com/…`, `linkedin.com/…`, and a plain `https://` prefix for Home Page). A leading `@` on a handle-based Kind is stripped automatically; a telephone number's own readable spacing (e.g. "+45 12 34 56 78") is preserved in what's stored and displayed — only the generated `tel:`/`wa.me:` link itself is normalized to bare digits. Mobile and Phone are visually distinct Kinds, but both link via `tel:`; SMS is a capability of Mobile, not a second action. A legacy entry whose stored Value still looks like a full URL (from before this Issue) remains fully functional — the link still works — but is flagged for Admin repair rather than silently accepted as the new normal. ## Semantic HTML and accessibility Each entry renders as a native `` with the Kind's own generated `href` (see above), a small fixed icon per Kind (decorative, `aria-hidden` — the Kind is understandable without color and without recognizing the icon shape, since an accessible name/hover title carrying the full Kind label always accompanies it), and the entry's own Value as the visible link text. `mailto:`/`tel:` links invoke the platform's own handler; every other Kind opens a normal external link. ## Role, Rank, and Reference A Post can hold several Contact Content Elements at once, each its own card of one or more entries, typically distinguished by Role (e.g. `presentation`) and Rank — see /_docs/posts. Entry order *within* one element is preserved as authored. Every Contact element also has an optional **Reference** — a separate, Post-unique name for addressing it inline instead of by Role/Rank — see /_docs/posts's "Reference: inline addressing" for the full detail. ## Editing In the admin Post editor, the Contacts section holds one block per Content Element, each with a Role field, a Position (Rank) field, and its own nested list of entries — a Kind selector, a Value field (with a live preview of the generated link, and a warning if the value still looks like a full URL), and an optional Description, with Add/Remove controls for entries within the block. Every Post Type's editor shows the same Contacts section regardless of which Type is active — used most heavily by the Category Presentation Post Type (/_docs/category-presentation), which requires at least one. ## Rendering contexts ### Inline `{{role}}` or `{{contact:reference}}` embeds one Contact element's compact block at that position in the text: every entry, icon + linked Value, in authored order. A Description shows in parentheses after its entry's Value only when that entry's own Kind is repeated more than once *within this element* — never merely because a Description happens to be set. ### Additional Information group Every eligible Contact Content Element gathers into one Contacts group — the same icon + linked-Value rows as inline, Rank then stable Version order for elements, entry order preserved within each. Here the Description-shown-only-when-duplicated rule is scoped to the *whole group*, not just one element — a Kind appearing twice across two different Contact cards still triggers the Description display for both. Equal Values are never deduplicated; separately authored entries stay separately shown. **Contact is a documented duplication exception** (alongside Image): a Contact element referenced inline still also appears here, unlike every other kind. ### Post metadata-page traversal Every Contact element the Post has ever held (current Version, or full history via `/metadata/history`) is enumerated with its full entries array (Kind/Value/Description each) as JSON-LD/native JSON — see /_docs/posts's Metadata page section. ### Standalone Content Element page `/_element/contact/:id` shows every entry on that one Content Element — Kind, the generated actionable link, and its Description always shown as text (never gated on whether the Kind repeats, unlike the compact inline/Additional Information views) — gated exactly like the owning Post's own page. ## Migration note Existing Contact rows (an earlier `email`/`phone`/`social` model) were migrated automatically: each became its own single-entry element at its existing Role/Rank/address, with `email` → Mail, `phone` → Phone, and `social` → Home Page (the closest generic fit, since `social` previously covered six now-distinct services with no way to tell which one a given row meant). Nothing was merged — a genuinely multi-entry card only exists from this point forward, built explicitly in the admin editor.