Content Type: Link

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 pointer to a destination URL — an external site, a related article, a booking page. Not to be confused with the Link Post Type (/_docs/link), which is a whole Post that is a link; a Link ContentElement is a smaller building block usable by any Post Type, including several at once for a Post that just mentions related links.

Fields

• URL (mandatory) — the destination address.
• Label (key optional) — a title for the link.
• Note (key optional) — a short description.
• Descriptive metadata (optional) — a small set of fields (a label, source name/URL, rights, and similar) distinct from the Label/Note above — mainly useful for a Link brought in from elsewhere, to preserve facts about where it came from. Not currently rendered on the page itself. See /_docs/json-import for the full field list.

Semantic HTML and accessibility

Renders as a native <a href="...">, with the Label (or the raw URL if no Label is set) as the link's visible, accessible text — never an empty or icon-only link. An external-link indicator (a small SVG icon) is added visually alongside it in some contexts (e.g. the Link Post Type's Summary card) with aria-hidden="true", so it doesn't add noise for a screen reader. A long Label or fallback URL wraps safely wherever it renders (inline, Additional Information) rather than overflowing or breaking that context's layout.

Live health and archive fallback

A Link's live destination is checked periodically in the background (never on a page load) and cached — see /_docs/posts's "Link health and archive fallback" section for the full state model. Inline rendering (below) substitutes the href for the two states that change what's linked to: a Missing or Invalid/unsafe destination with a preserved copy available links to that copy's address instead (a Kartotek PDF is preferred over a Web Archive snapshot); with no preserved copy at all, the original address is kept. Every other state (Healthy, Restricted, Limited/temporary, or never yet checked) links to the original destination unchanged.

Status icon. Every managed Link — not only a Missing one — is followed by a small circular coloured letter, a separate link to that Link's own standalone page (never nested inside the Link's own anchor): green v (Active) for Healthy; orange p (available via local PDF) or yellow w (available via a Web Archive — Wayback Machine, Arquivo.pt, or Common Crawl) when Missing/Invalid and a preserved copy exists; red i (not available anymore) for Missing/Invalid with no preserved copy, and also for Restricted/Limited/Unknown — folded into the same red icon as a deliberate simplification, since none of those three states are a confirmed-reachable destination either. The letter, its hover text, and its accessible name always carry the meaning together — colour is never the only signal. The Link's own standalone page (below) still shows the fuller state in plain language, including every confirmed Web Archive capture (Wayback Machine listed first whenever it has one) and an Admin/visitor-facing Check now action.

Role, Rank, and Reference

A Post can hold several Links at once, each with its own Role (primary, booking, mission-brief, …), or several sharing the same Role, distinguished by Rank — see /_docs/posts. Every Link 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. A Role starting with citation- is reserved for an Image's own source citation — see the Image Content Type's "Source citation" field — and can't be set on an ordinary Link; a citation Link is otherwise a normal Link (same health checking, archival, and status icon), just edited from its owning Image rather than the generic Links section, and never listed among a Post's other Links or in Related information.

Editing

In the admin Post editor, the Links section holds one block per Link, with URL, Label, Note, Role, and Position (Rank) fields. Every Post Type's editor shows the same Links section regardless of which Type is active — see /_docs/posts.

Rendering contexts

Inline

{{link:booking}} renders the Link element with Role booking as a styled inline link, right where the reference sits, rather than a raw URL — see /_docs/markdown for the full content reference syntax.

Additional Information group

Every Post Type's shared Additional Information container's Links group (Article, Gallery, Image, Category Presentation, FullScreen) — every eligible standalone Link in one compact list, strictly Rank-then-stable-Version order, each rendered as <a>{{label or url}}</a> (the live/archive-fallback address, per above) followed by its status icon, with its Note (if present) appended after an em dash. Role and Reference are never shown here — see the standalone page above for where they are. A source-citation Link (citation-* Role) never appears here — it stays in its owning Image's caption instead. Repeated destination URLs used by separate Link Content Elements each still get their own row, in their own authored order — nothing here is deduplicated by URL.

Post metadata-page traversal

Every Link the Post has ever held (current Version, or full history via /metadata/history) is enumerated with its URL, Label, and Note as JSON-LD/native JSON — see /_docs/posts's Metadata page section.

Standalone Content Element page

/_element/link/:id shows the link (as a real, clickable <a>) plus its Note, gated exactly like the owning Post's own page. Also shows its current live-health state in plain language, a Check now button (rate-limited to once every 10 minutes), its Role and Reference (the canonical place either is publicly visible — both stay absent from Additional Information), and — whenever one exists — a link to view the Kartotek-captured PDF (with its capture date), the Kartotek-captured local WARC (alongside the PDF), and/or the single preferred confirmed Web Archive capture (Wayback Machine, Arquivo.pt, Common Crawl — Wayback Machine first whenever it has a usable capture, otherwise the best available alternative first), alongside the live destination itself. Precedence when several exist: live destination, then Kartotek PDF, then Kartotek WARC, then Web Archive. The page stays in this order — current destination/status first — with two further sections below it, kept concise rather than dumping every routine background check:

Archived copies. Beyond the single preferred Web Archive snapshot above, this section lists every individually confirmed capture Kartotek has discovered across Wayback Machine, Arquivo.pt, and Common Crawl — each shown with its own provider and capture date/time, sorted newest first. A capture opens the real archived page it points to; Common Crawl's own entries are clearly marked as an index record rather than a directly viewable page, since Common Crawl has no page-replay address of its own (see /_docs/posts's "Link health and archive fallback"). A long capture history doesn't load all at once — it starts with the most recent few and reveals more on request. This section is always built from already-cached discovery results, the same background check that populates the preferred snapshot above — opening this page never triggers a live provider lookup, so a slow or unreachable provider never blocks the page itself.

History. A concise, durable timeline of this Link's own operational lifecycle: when it was added, when it was first checked, when it was first confirmed working, each later transition between working and unavailable, each canonical URL change (the explicit HTTP→HTTPS Upgrade to HTTPS action described in /_docs/links's Admin visibility section, or another audited change), and when an archived copy was first discovered — never one entry per routine check that found nothing new. A fact reconstructed from before this feature existed, where the exact original date isn't recoverable, is clearly marked as an estimate rather than presented as precise, alongside a short explanation of why. This history survives an HTTP→HTTPS upgrade intact — the earlier facts about the Link stay in the same timeline rather than starting over under the new address. Every heading, event label, and explanation in this section follows the visitor's selected language (see /_docs/browsing's language selector section) — switching language only changes how the same underlying history is presented, never its content, order, or timestamps.