Publishing and Appearance

Private sites and view/edit permissions (user management)

You can make a site private and then grant "only these people can view" and "these people can co-edit". Configure it under the dashboard's site detail → "User management".

• Viewer — can view a private site (cannot edit).
• Editor — can view and co-edit the top page (CMS) and settings.
• Admin — same as editor (member management later).
• Allowed domains — e.g. add u-tokyo.ac.jp and anyone signed in with that email domain can view without an individual invite.

Viewers must sign in (with Google) first, then open the private site URL. Unauthorized or signed-out access returns 404 (hiding the site's existence). Only the owner (and admins) can toggle public/private.

How it works

Signing in issues a secure server-readable cookie, which the site uses to decide whether the visitor may view a private site (no external generative AI is used).

Visibility

Setting a site (database) to public makes it appear in:

• the "Published sites" directory on the platform top page (archivebase.ldas.jp)
• its own URL /{account}/{database} (it returns 404 while private)

Items flagged private stay hidden from listings, search and the API even on a public site (see Items and Collections).

Standard site pages

Every library automatically gets a top page plus listing/search pages per resource type. A page whose type has zero resources is hidden from the nav (data-driven).

URL	Contents
/{account}/dl/{db}	Top (per-type counts and links to each search)
…/items	Item search
…/collections	Collection listing
…/pages	Image (facsimile) listing
…/annotations	Annotations (tag / motivation facets)
…/map	Map of georeferenced resources
…/fulltext	Per-page OCR full-text search (supported backends only)
…/visual	Visual search (supported backends only)
…/assoc	Associative search (indexed libraries only)

The site card (how your site looks on the top page)

In the "Published sites" directory each site appears as a card with a thumbnail and description. Set it under the dashboard's site detail → "Site card" (image, description, English description).

When unset it falls back automatically: the image uses the hero image → the newest item's thumbnail; the description uses the footer description → a summary of the site description. The description can be set separately for Japanese and English.

Custom domains

A public site can be served under its own host name such as xxxx.ldas.jp (the same idea as a Vercel custom domain). Once assigned, the contents of archivebase.ldas.jp/{account}/{database} appear as the top page of that host name (the address bar keeps the custom host — it is resolved to the tenant internally).

• Configure it under the dashboard's site detail → "Custom domain". Enter the label you want (e.g. haga) and click "Add" to assign haga.ldas.jp.
• DNS and the TLS certificate are automatic (Cloudflare); an addition takes effect within seconds.
• The site must be public (assigning a domain to a private site still returns 404) — publish it first.
• Reserved labels such as archivebase and www cannot be used. A site can have more than one domain.

Using your own domain (external domains)

You can also serve a site under a domain you own (e.g. archive.example.org), not just an ldas.jp subdomain. This uses Cloudflare for SaaS (Custom Hostnames): Cloudflare issues the TLS certificate automatically and its WAF / edge protection still applies.

1. In the dashboard's site detail → "Custom domain", enter the full domain in the your own domain field and click "Add".
2. Add the DNS records shown (a CNAME and a TXT) to that domain's DNS (for ownership verification and certificate issuance).
3. After the records propagate (a few minutes+), click "Verify" — once validated, the domain becomes live.
4. While pending it is not yet served (shown as "pending"). DNS propagation can take some time.

Canonical URL

Pages served under a custom domain emit a canonical / OG URL pointing at that domain (https://haga.ldas.jp/ or https://archive.example.org/).

Editing the top page (blocks / CMS)

You can compose the top-page body from blocks, with no code. Edit it under the dashboard's site detail → "Top page content (CMS)".

Available blocks:

• Heading / Body (Markdown) — Japanese and English entered separately
• YouTube video — just paste a URL or video ID (privacy-enhanced embed)
• Image — a URL (optional link and alt text)
• Featured — auto thumbnail grid / News — latest announcements

Once you add one or more blocks, they replace the default auto layout (search cards, etc.); the header nav is always shown. "Clear all" reverts to the auto layout. The background-image hero stays under "The top-page hero" below.

Safety

Raw HTML cannot be pasted (YouTube uses a dedicated video block; body is HTML-stripped Markdown). No external generative AI is used.

The top-page hero

A site with a hero configured shows a full-bleed top page (background image + gradient + buttons) and a "featured" thumbnail grid (otherwise a simple header). Set the background image and subtitle in the dashboard's site detail.

Detail-page viewer

The display of an item's detail page (/{account}/dl/{db}/item/{id}) can be chosen per site (dashboard site detail → "Detail-page viewer").

• simple (default) — metadata table + thumbnail
• osd — an OpenSeadragon viewer layout; child resources' images are shown as views with a view-list tab on the right. Falls back to simple when there is no image
• av — an audio/video player (Clover IIIF), supporting IIIF manifests and WebVTT captions
• corpus (sites with settings.dts.source = "corpus") — a reading viewer for materials that have transcriptions. Alongside the OpenSeadragon image it shows line-level transcription highlighting (coordinates from the corpus IIIF text layer), per-page translation/summary tabs, in-viewer full-text search, and a list of named entities (people / places / organizations) extracted from the text. Corpora whose places are geocoded get a "Map" tab that plots place-names across the whole corpus with occurrence counts (the same map as the analysis page). It keeps the shared layout (below) and swaps only the player for this reading viewer

Materials that carry a IIIF manifest can show a "View in VR gallery" link (off by default; enable it per site in the dashboard when needed). An item with a 3D model (metadata.model3d) is shown in a 3D viewer regardless of the site's viewer setting. If a scan-derived GLB shows up tilted (face-down, on its side, etc.), set metadata.model3dOrientation to a model-viewer pose ("roll pitch yaw", e.g. "-169.94deg 37.50deg -152.31deg") to right it.

Whatever the viewer type (osd / av / 3D), the same shared layout sits below the player — metadata on the left and, on the right, sharing, "URL of this item", related links (IIIF manifest, etc.), terms of use and a citation. Only the player itself differs.

Sharing and citing a specific frame

For multi-frame materials, the frame you are looking at is the frame you share.

• Adding ?canvas=3 to the URL opens the item at frame 3 (frame numbers are 1-based). Paging through the viewer rewrites ?canvas= in the address bar, so copying the URL straight from the browser shares that frame
• The "URL of this item" field in the right rail always shows the current frame's URL and has a copy button. The share buttons (X / Facebook / LINE / copy link) share the same frame-aware URL
• The citation in the right rail ("Title", Site. URL (accessed date)) also carries the current frame in its URL
• ?pos=3, used by inbound links from legacy sites, is accepted as the same 1-based frame number and is normalised to ?canvas=3 once the page opens

Terms of use (license)

The right rail can show the terms of use for your material. Set it per site (PATCH /{account}/{db}/api/database with rights): a Japanese and an English statement, plus an optional link to the full terms.

"rights": {
  "ja": "CC BY 4.0 (表示 4.0 国際)",
  "en": "CC BY 4.0",
  "url": "https://creativecommons.org/licenses/by/4.0/"
}

When rights differ per item, put a value in that item's license (or rights) metadata and it overrides the site default for that item alone. Terms of use are shown as a rights statement in the rail, so they are not repeated as a metadata row.

Image download

Items with the image viewer (osd) can show a Download panel in the rail (like the NDL Digital Collections). Viewers can choose:

• File format — JPG (single frame) / PDF
• Resolution — standard (lightweight) / high resolution
• Range — all frames / a specific range (1,3,6 or 5-12)
• Add margins and print bibliographic info (PDF only) — adds a margin to each page and prints the title, frame number, and terms of use

Single-frame JPG is fetched straight from the existing IIIF delivery URL, so it adds almost no server load. Multi-frame bundles (ZIP) and PDF are assembled on the server, so there is a cap on how many frames you can fetch at once (default 200). For large items, specify a range. The button shows a "Preparing…" state while generating.

Because this is a non-core, heavy operation, the server limits concurrent generation (default 1, tunable via DOWNLOAD_MAX_CONCURRENT). When busy it returns a "retry shortly" message (HTTP 429), and if a single generation is too large (≈300 MB by default, DOWNLOAD_MAX_MB) it asks you to narrow the range or use the lightweight resolution. These are safeguards so crawlers or bulk automated requests cannot bring the server down.

Configure it per site (download in PATCH /{account}/{db}/api/database). Public sites are enabled by default. Sites that need to restrict downloads for rights reasons can disable it or limit the formats.

"download": {
  "enabled": true,             // when omitted, on for public sites only
  "formats": ["jpg", "pdf", "zip"], // allowed formats (empty array = effectively off)
  "maxFrames": 200,            // cap for PDF/ZIP bundles (1..1000)
  "defaultSize": "reduced"     // panel's default resolution (reduced | full)
}

Download on private sites is off by default (set enabled: true to allow it explicitly). The images themselves are still protected by per-asset visibility (is_public) and the view gate as before.

Other display settings

The dashboard's site detail also lets you configure:

• Search facets — per type, the metadata keys and labels used for filtering (Postgres-backed sites)
• Item-detail metadata display — on the item detail page's metadata list, rename (Japanese / English), hide, or reorder each key. Standard vocabulary keys like dcterms:date are labelled automatically even without configuration (e.g. dcterms:date → "Date"). Via API key: the detailFields setting ([{key,label,labelEn,hide}]) on PATCH /{account}/{db}/api/database
• Other site settings — everything else (hero, footer, site card, provider name, OG image, rights statement, default OCR model, …) is editable under "Other site settings". Every setting the API can change is editable from the dashboard too
• Result sorting — replace the search page's "Sort by" options with ones that match the site's own data. Without this the built-in list (call number / sender / publication year …) is used, so a site without those fields shows options that do nothing. Via the API key: sortOptions ([{field,dir,label,labelEn}]) on PATCH /{account}/{db}/api/database. field is a metadata key, or title / slug / relevance (ranking); dir is asc / desc (default asc)
• Header menu — control the tabs' visibility, labels (Japanese / English), order, and custom links:
  • Menu visibility — hide individual header tabs (items / collections / pages / map, etc.)
  • Rename menu items — override the default tab names (e.g. Items → Holdings)
  • Order — reorder the tabs with ↑ / ↓
  • Custom links — add your own menu entries; the target can be a site-relative path (e.g. /about-us) or an external URL (opens in a new tab)
• Gallery view — enable a gallery page that pairs parent materials with cropped regions

Footer and static pages

• The footer (site description, related links, copyright) currently has no dashboard editor and is set via an API key (PATCH /{account}/{db}/api/database, the footer field)
• Static pages — "About this database" and similar are surfaced via the page (About) feature

Work in progress

Screenshots, how to enter bilingual text, the conditions under which each backend (full-text / visual / associative search) becomes available, and a dashboard editor for the footer are yet to be documented.