Admin / Site manual Back to the site

Updating the site

The operating manual for traveller.org — kept current with every publish that changes a process. Sits with the CMS portal behind the admin door.

Google Search Console — the one rule (owner, 7 September 2026: “This is SO important for me to remember”). Do not press anything on “Page with redirect”, “Duplicate”, or the legacy URLs in “Crawled — currently not indexed” — those reports emptying is the goal, and requesting indexing on them works against it. Same for the whole http://www.traveller.org property: it’s a museum of the old site; let it decay. The only place a manual index request helps is a current page you want in (URL Inspection → Request Indexing, rationed ~10/day). The full reading of a coverage report is on the pipeline page; calendar reminders for the check-back dates (21 Sept, 15 Oct, 16 Nov) are on your Google Calendar.

Until the /admin CMS ships, updates happen one of two ways: tell Claude what you want in a session (it edits the data files and publishes), or edit the JSON files directly on GitHub. Every path below ends the same way — a commit to the repo, which triggers the automatic build and deploy. The CMS will be a friendlier skin over exactly these same records.

One login for every admin page

The admin login lives at the foot of the left-hand menu (as a card near the top on a phone) — and since 3 September 2026 it asks for one thing: the passphrase, the same one as the upload page. The worker address is machinery and waits behind a small Change the worker address button; it reappears on its own when the worker cannot be reached, which is the one time it needs looking at. Sign in once on any admin page and it holds across all of them: each tool page connects itself the moment you arrive, and the prompt only reappears when the passphrase is absent or wrong. While the check runs, a band at the very top of the page says CONNECTING… in ink with a light sweeping along it — the phone uploader’s own language — and turns into the gold CONNECTED band the moment the session holds, so the page underneath stays readable instead of hiding behind the form. With Remember on this device ticked it survives closing the browser (and switches on the Rotate / Remove controls on photo pages); unticked, it lasts until the tab closes. Sign out in the same spot clears it from the device — photo pages drop their admin controls at the same time. Hiding the fields is convenience, not the security: the Worker re-checks the passphrase on every call regardless.

One button carries your login to the live site (30 August 2026)

A browser cannot share a login between two addresses, so being connected on the staging admin used to leave www.traveller.org a stranger to you: the friends door bounced you off your own unlisted albums, and the photo-page controls stayed hidden. Now the connected bar on every admin page carries Unlock the live site. One tap opens a new tab in which production recognises you completely:

  • the friends door opens — unlisted albums, the signed-in banner, the woven friends-only photographs, the Share button;
  • the photo controls appear — rotate and remove on photo pages, and the unlisted album cards in the country timelines.

The button is the purple one on the bar — the same purple as everything the friends layer touches. If the live site ever looks signed OUT when you know you unlocked it, check the address bar first: the bare traveller.org used to serve the site as a second host with none of your keys; since 30 August it forwards to www, where your unlock lives.

Under the hood the button hands your held passphrase to the live site, which checks it against the upload Worker — the passphrase’s one home; no second copy exists anywhere — and only then lets that browser in. Once per browser is enough; it lasts about a year, like a friend’s sign-in. A wrong or rotated passphrase unlocks nothing.

Finding your way: four groups (3 September 2026)

The admin menu is grouped by the job, in the order the work flows: Add (the photo uploader, the phone uploader, the iPhone Shortcut recipe — each with its own icon), Content Mgmt (Gallery cleanup, Journal, Banknote pages, Cards & strips), Publish (the Publish button, zip records, the launch runbook) and Manual (these pages). Nothing inside any tool changed — only how you reach them.

  • On a desktop the left rail shows all four groups open, with the page you are on lit.
  • On an iPad the rail becomes one row of four group chips; tapping a chip shows that group’s tools underneath it.
  • On a phone the menu lives in a bar along the bottom of the screen — tap a group and its tools rise in a small sheet. In Gallery cleanup’s Select and Arrange modes the mode’s own buttons take over the bottom edge; leave the mode and the bar is back.
  • The two uploaders are in the menu now, under Add. They are the Worker’s own pages, so the links work the same from the staging admin and the live one.
  • Journal is one entry with two doors. The menu opens the editor (the letters); a Letters / Photos switch at the top of either journal page reaches the other half.
  • The admin front page shows a status strip once you are signed in: how many changes are waiting to publish, what the last import brought in, and how many albums sit in storage not yet imported. Every number is read from the worker at that moment — nothing on the strip is typed in by hand.

Publish to the live site — review on staging first

  • Every change lands on staging (the test site) by itself, within minutes. The live site does not change until you press Publish on the Publish page — same passphrase as the upload page.
  • The page shows exactly what is waiting to go live, newest first, with a link to staging so the review and the button sit together. Publishing takes everything staging has — it is not per-change.
  • To undo a publish: say what to revert in a session (or revert the commit on GitHub), check staging, publish again.
  • Until cutover the button only moves the production branch — the live traveller.org is still the old InMotion site. From cutover day onward it is the real switch.

Add or edit a journal entry

  1. Each entry is one record in src/data/journal.json: title, city, date, country, body text, optional images and pull quote.
  2. Interim path: give Claude the text (and any images) — it creates the record, places the images, and publishes.
  3. The entry appears in the journal listing under its year, on its country's page, and (if flagged) as a "Letters home" card on the home page with the city/year passport stamp.
  4. Via the CMS later: "New entry" page with title/city/date/hero/text fields, an "+ Image" button for inline figures, and a Feature-on-home-page switch.

Add photos — upload, then one click

  1. Open the bulk upload page (the traveller-upload Worker — bookmark it) and enter the passphrase (or check "remember on this device" once so the bookmark opens ready to go).
  2. Pick a Destination from the drop list — it reads Country — year — album name and is sorted that way (13 September 2026), so the two Havanas sit apart as Cuba — 2009 — Havana and Cuba — 2015 — Havana; the count and the storage path stay at the end of the row:
    • An existing high-resolution gallery — the photos are added to it. This is how a trip gets uploaded across several sessions or folders.
    • A legacy 800px gallery — creates its high-resolution replacement. The path fields open pre-filled with the new-style address (e.g. picking 2009-saigon suggests vietnam/2009/saigon) — edit it there if the replacement should live somewhere else. The old gallery stays visible as a deprecated reference until launch.
    • + New gallery… — type the path yourself as country/year/name, e.g. vietnam/2009/halong-bay, plus an optional display name.
  3. Drag the folder in — hundreds of files at once. Name subfolders by place (Cat Ba/, Rangoon/) — one level below the gallery path, e.g. vietnam/2009/halong-bay/Cat Ba/ — and the photos arrive pre-tagged, so the gallery page groups itself into city sections. (The Cloudflare dashboard's own uploader caps at 100 files and flattens folders — use it only for tiny batches with no place folders.)
  4. The destination starts empty and has to be chosen. On a phone it is a tinted card marked 1 Destination — tap anywhere on it (or its Choose button) to get the list of every gallery on the site; + New gallery is one entry in that list rather than the default, so the page never opens already committed to creating something. The photo well below is marked 2 Photos, and the button at the bottom is step three.
  5. Nothing uploads until you approve the plan. Once photos are picked, a bar pinned to the bottom of the screen states exactly what is about to happen — "Upload 43 photos → Halong Bay" — and the upload starts when you press it (✕ cancels). Change the destination while the bar is waiting and it re-checks and re-labels itself for the new address. This is the moment that would have caught the four batches that merged into one 968-photo album: the plan is stated before any bytes move.
  6. A status ribbon sits pinned along the bottom of the screen the whole way: dark while photos upload (with a live count), green the moment everything is up and again when the import has started, red if anything needs a retry — so on a phone the answer to "did it go through?" never requires scrolling. Tap it to dismiss.
  7. And the next button is always under the ribbon, not below the fold. When the upload lands, the bar becomes Start import → Halong Bay; if files failed, it becomes Retry 3 failed. The same buttons stay in the card with their full receipt — the bar is the reachable copy of whichever one matters now, and pressing either one does the job exactly once.
  8. When the upload finishes, click Start import → right there on the page. It resizes, generates thumbnails, updates the data, and the gallery goes high-res on the test site a few minutes later — no chat message needed. (If the page says automatic start is not set up, it will tell you to message Claude with "batch uploaded: burma/2001" instead — same result, one extra step.)
  9. Duplicates look after themselves: a file with the same name replaces the old one (the page says how many before it starts), and the same photograph under a different name is spotted at import, removed from storage, and listed in your email. A re-export with different pixels is the one case that slips through — see the pipeline notes.
  10. If the upload page seems to be missing a recent fix — a file type it should now accept, a button that should exist — look at the version stamp pinned in the bottom-right corner of the window (it stays put as you scroll) and see the pipeline page under "A fix isn’t showing". Short version: your browser may be holding an old copy, and opening …workers.dev/?fresh always gets the current one.
  11. The Upload settings are switches, not tick boxes (21 August 2026). Every on/off setting on the upload page — Remember passphrase, Ignore subfolder names, Shrink big photos, Unlisted album — is a sliding switch: grey and to the left when off, purple and to the right when on. A native tick box renders about 13 px on an iPhone, and beside three lines of small grey explanation it was not possible to tell on the phone which of them were on (owner, 21 August 2026). The switch is 44 px across, and the whole row is tappable, so it is legible and hittable at arm's length. Nothing about what they do changed.
  12. Upload speed — the Parallel uploads setting. The page sends several photos at once; 8 is the default. If your connection is fast and wired, 16 or 32 can be quicker still; on a slow or flaky line, 2 or 4 finishes more reliably because there is less to retry. (The default was 4 until 21 August 2026. Eight streams is the setting that had been chosen by hand on every real upload, so it became the one you get without choosing. A number you already picked on this device still wins — changing the default does not overwrite a decision you made.) The progress line shows a live MB/s and the finished message reports the run — "180 MB in 95s at 1.9 MB/s on 8 parallel uploads" — so you can try a setting and actually see whether it helped rather than guess. Your choice is remembered on this device. More streams only help while the connection is not already full: past that point they divide the same pipe and the total time stops improving.
  13. Two upload pages at once? It works — uploads are independent — but it rarely helps for the same reason, and it splits one connection into twice as many slower streams. Raise Parallel uploads in one page instead. The one thing to avoid is switching on Ignore subfolder names in two pages uploading to the same album at once: the rename counter that stops two photos claiming one filename cannot see across pages. For very large archives, rclone straight to the bucket beats any number of browser tabs — then start the import from this page as usual.
  14. A photo that cannot be read is skipped, not fatal. If a file is corrupt or its upload was cut short, that one photograph is left out and named in your import email; the rest of the album publishes as normal. Re-upload just those files (same names replace them) and import again to add them.
  15. Upload into an album folder, not beside one. If you upload to southkorea/2008 when that already holds albums like southkorea/2008/busan, the photos land next to the albums rather than in one — a valid path with no gallery of its own, so they publish nowhere and the import for the album you meant reports "no images found". The page now catches this: it names the album folders already there and offers a corrected path before uploading. If the photos have already gone astray, nothing is lost — they can be moved into an album from Actions (mode import with from_slug set to the parent path), which is a storage-side move, not a re-upload.
  16. One destination, one album — no matter how many batches you send it. Uploading four batches to india/2007 does not make four albums; it makes one album holding all four, named by whichever batch you sent last. The gallery name is a label on the destination, not a divider between batches. To get separate albums give each batch its own path — india/2007/agra, india/2007/kerala — or drop the folders together and pick Separate galleries. The page now warns before uploading when the destination already exists under a different name, and offers the sub-path.
  17. An album that already swallowed several batches can be split without re-uploading. Ask for it and the photographs are separated inside storage by their filenames (all the agra… files into one album, all the kerala… files into another) and each is published under its own name. Nothing goes back up from your machine, so it costs minutes rather than hours — but it only works when the filenames say which batch they came from.
  18. Camera sidecars are dropped for you. A Minolta card gives you a .THM thumbnail beside every .MRW; other cameras add .XMP, and the Finder adds .DS_Store. None are photographs, and none are uploaded — only .jpg, .jpeg, .jpe, .png and RAW files (.mrw .nef .cr2 .arw .dng .orf) go up, in any mix of upper and lower case. (.jpe is an ordinary JPEG — the third spelling the standard allows, which some scanners still write.) The page says what it skipped and how many it is sending, so a drop of 400 files uploading 200 is never a mystery. If sidecars reach storage some other way (rclone, the Cloudflare dashboard), the import ignores them and names them in its log.
  19. The passphrase collapses once it works. Enter it once and it folds into a single "Unlocked" line, so the destination picker and drop zone sit near the top of the page. With Remember passphrase switched on the page opens already unlocked. Change passphrase reopens the field; Forget clears it from this device. If a remembered passphrase ever stops working, the field reopens by itself and says so.
  20. Folders in your upload — the page asks what they mean. A drop that contains folders can be read two ways, and both are real, so the page asks before uploading: Separate galleries — each folder becomes its own gallery under the destination (drop 14 city folders on india/1993 and get 14 galleries, each titled from its folder name, imported in one click of Start N imports) — or Places inside one gallery — folder names become place tags, the way Burma’s Rangoon/ and Bagan/ sections are made. Dragging one wrapper folder still works as always (its name is stripped; folders inside it prompt the same question). Switch on Ignore subfolder names to skip the question and file everything flat.
  21. Order within an upload: photos at the top level upload and publish first; folder contents follow, folder by folder. Flattened name clashes get a -1 suffix rather than overwriting.
  22. The country in a new album’s path must be one the site already has. Mistype it and the page offers the closest match and fixes the path for you.
  23. Clicking Start import twice is safe. If a run for that album is already waiting to begin, the page says so and does not queue a second one — the waiting run reads storage when it starts, so it already includes what you just uploaded. This is what used to produce a red Canceling since a higher priority waiting request exists on a perfectly good run.
  24. The form clears itself the moment the import is handed off — destination, gallery name and the file selection all reset, and the gallery list reloads — so the page is ready for the next batch without a reload. The green confirmation and its Track progress link stay on screen.
First run: pick any gallery you like — a small one is a fine dress rehearsal.

Setting this up for the first time, or rotating a key? See Publishing & image pipeline → Credentials & where to update them for direct links to the GitHub secrets page and the Cloudflare Worker editor.

  • Originals are fine in place of 2048 px re-exports; they're downsized on import. RAW straight from the camera works too (.mrw and other common formats) — the pipeline develops them with the camera's white balance. RAW files are not kept after conversion.
  • You get an email when an import finishes (21 Aug 2026) — “Ready to review: Halong Bay — 43 photograph(s)” — carrying the album’s link on the test site, a reminder that it is not on the live site until you press Publish, and every other album still waiting to be reviewed, each with its own link. See the pipeline page for how the waiting list is worked out. One email per album, and each one carries the whole list.
  • Zip record: after every import, a zip of the processed batch (organized by country and place) is listed on the zip records page, and its link is in that email and in the run log — download it for your own archive, then hit Remove to delete it from storage.
  • A brand-new country can be created during its first upload. In the destination builder, the country list's last entry is "+ a country the site doesn't have yet…". Choose it and two boxes appear — the country's display name ("Jordan") and its region (South Asia, Middle East, Asia-Pacific, The Americas, Africa, Europe; the region sets the country's colour and which band it files under on the home page). Nothing else changes: the name slugifies into the address exactly as the gallery name does, the live line shows jordan/2026/petra and adds "Creates the country Jordan", and you never type a path. (If you prefer typing one, "Edit the path directly" still works, and a path whose country the site does not recognise is challenged before the upload with the same two questions — it also offers the near-miss, so north-korea is caught when the site's slug is northkorea.) The import creates the country record — page, stats, chips, listings and the locator map are all live on that same import: maps draw from world-map data stored in the repository, framed to show the country among its neighbours. (If map generation ever fails, the import email says so, the country page simply renders without the map, and re-running is one workflow click.) A country the site already knows — even one with no photo albums yet, like a journal-only country — is never challenged: its first batch uploads like any other.
  • Deprecated galleries: once any high-resolution batch lands for a country, that country's remaining 800 px galleries are automatically marked Deprecated · 800px on the country page and carry a banner on their own page. They stay visible and clickable as a quality reference while uploads are in progress, and get pruned at launch. Nothing to switch on — it follows from the data.

Where to work, and what to type

Start at www.traveller.org/admin/ — that page lists every tool with a line on what each is for. Cloudflare asks for your email and a one-time code first; after that the whole admin door is open for the session.

The tools that talk to the worker — Publish, Gallery cleanup, Journal photos, the Journal editor, Cards & strips, Banknote pages, Batch zip records — need the login at the foot of the left column. The manual pages need nothing.

Staging admin or live admin? (22 August 2026)

They do the same thing. Every admin page on either host talks to the same upload Worker, which starts the same workflow in the same repository and writes to the same photo storage. Approving a gallery, hiding one, reordering photos, deleting a note — done from brarob100.github.io/traveller.org/admin/ or from www.traveller.org/admin/, the effect is identical. There is one set of data and one pipeline; there is no second copy to keep in step.

What differs is the age of the tools, not the data.

Staging admin (github.io)Live admin (www)
The pagesEvery commit, within a minute. Newest controls. Only what was there at the last Publish, so it can be missing controls that already work on staging.
The album listThe same list on both: the Worker reads it from staging, so a gallery imported ten minutes ago is offered on the live admin too, before it is published. That is deliberate and fixed — see which site the phone reads.
The doorThe passphrase only — the pages themselves are public (unlinked and noindex, but no login: GitHub Pages cannot take one). Cloudflare Access since 19 August 2026 — email and a one-time code — then the passphrase.
Signing inSeparately on each: the passphrase and the Worker address are remembered per website address, so signing in on one does nothing for the other.
Cross-site callsAn extension or privacy setting can block them (see the box above).Same-origin through /api — nothing to block.

Use whichever suits the moment, and treat staging as the master. It has the newest tools, and it is the site the album list comes from. The live admin is the same machinery one Publish behind — useful when a browser is blocking the cross-site call, and the only one protected by the Access door.

From the phone, the choice is made for you. The uploader’s Publish to the live site card and the tool links beside it (added 27 August 2026) all open the staging admin — the master set, and the one that does not stop a phone at an email-and-code login. See the rest of the admin, one tap away.

The uploader as a Home Screen app (31 August 2026). Open www.traveller.org/api/m in Safari, tap Share → Add to Home Screen, and the icon opens the phone uploader full-screen, no browser chrome. If you added the icon before this date, delete it and add it again: the old app manifest pointed its launch address at / — the uploader itself on the old workers.dev host, but the site’s home page once the Worker moved to /api, which is why the icon opened the wrong thing. It now names the uploader on whichever address it was added from.

Picked the wrong photos on the phone? Tap Clear (4 September 2026). While photographs are selected, the Photos card shows Clear beside Change — one tap empties the selection without reopening the photo library, and the upload button goes quiet again. The same Clear appears on the Currency screen’s card. (Change re-opens the library; on an iPhone, cancelling there keeps the old selection, which is why Clear exists.)

The phone uploader tells you it is unlocked, at the top (1 September 2026). While a remembered passphrase is being checked the same bar runs first in ink reading UNLOCKING… — it used to be a greyed label inside the bottom button, the least visible corner of the screen — with a light sweeping along the band so a slow network reads as working, not stuck (3 September 2026; the sweep stays still for anyone whose phone asks for reduced motion), then turns gold the moment the check succeeds. A gold UNLOCKED bar runs across the very top of every screen of /m, saying whether the passphrase is remembered on this phone or good for this session only — the two behave differently next time you open the page, and only one survives closing it. It replaces a small green word in the top corner that was easy to miss. The bar is absent on the unlock screen, which is by definition the locked one. The same screen now leads with the site’s own app icon — the Buddha that is on the browser tab and on the Home Screen icon — instead of a drawn symbol, so the page you unlock looks like the thing you tapped.

If an album is suddenly called by its path (27 August 2026)

An album named 2026/madrid instead of Madrid, with its year showing the same thing, means an import was re-run without a name or a year filled in and the album took its path as both. Nothing is lost — the photographs, the order and the unlisted flag are all untouched, it is two fields on the record.

The repair is one save: open the album on Gallery cleanup, put the real name and year into Album details, and save. It will not happen again — from 27 August the import reads the album’s own record before falling back to anything, so a re-run that leaves those boxes empty keeps the name you gave it. See what a re-import keeps.

What an album’s address must look like (22 August 2026)

  • Two parts or three. country/year or country/year/name — both are accepted everywhere photographs are sent. Forty-one albums on the site are two-part (botswana/1992, unitedstates/2012), which is how the early ones were made.
  • The upload page’s pickers always write three. Choose a country, a year and type a gallery name and the address writes itself as country/year/gallery-name; without a name it writes nothing. To send to a two-part address, press Edit the path directly and type it.
  • A two-part album is titled by its year — “2012” — unless you give it a name, on the upload page or afterwards under Album details. That is the only real cost of the shorter form.
  • The country part has no spaces or hyphens: unitedstates, hongkong, southafrica. Type united-states and it is folded onto the site’s spelling automatically, at both ends of the upload.

Two removals the page now refuses (22 August 2026)

Removing photographs deletes them from storage and then starts a short run that rebuilds the album’s record. Two cases broke that second half and reached you as a red “Run failed” email for something that had already happened:

  • All of them at once. Selecting every photograph and pressing Remove emptied storage, and the run then refused to take the record down to nothing — leaving an album on the site pointing at photographs that were gone. The page now stops this before anything is deleted and points at Delete this album, which takes the record and the photographs together. Removing all but one is ordinary work and still goes through.
  • A folder that was never imported (the mark). Its files can be deleted — nothing on the site points at them — but there is no record to rebuild, so the run died with “belgium/1996 is not an r2 gallery”. No run is started for these now, and the page says so: “This folder has never been imported, so nothing on the site had to change.”

Neither was a lost photograph — both deletions did what was asked. What was wrong was being told a failure had occurred by email, minutes later, with no way to tell which half had failed.

Getting out of a photograph (23 August 2026)

An album is two screens: the photo view you land on, and the grid of every photograph in it. The bar at the top of the photo view now offers both ways up — “▦ All 388 photos” for this album’s grid, and “‹ Burma — country page” for everything from that country.

Before this the bar had the country page only, and the way back to the album was a button below the filmstrip — off the bottom of a phone screen, and not where anybody looks for “back”. It matters most for a link to a single photograph (an address ending #p2), which is how one picture gets shared: whoever opens it has no idea what album it belongs to, and now there is one tap to find out. The button below the filmstrip still works and does the same thing.

Gallery cleanup on a phone (25 August 2026)

Open Gallery cleanup on your iPhone and it is the page you designed on the boards: albums first — a searchable list with the ⊘ unlisted and ◌ not-imported markers — then the album itself with three ways of holding it:

  • Browse (the default): tap a photograph to see it full size.
  • Select: tap photographs to tick them, and the actions appear along the bottom — rotate left / right / 180°, To front, Move, Remove. Move asks in a slide-up sheet where the destination is picked; Remove confirms in one too. Removing every photograph is still refused — that is Delete’s job.
  • Arrange (reworked 31 August 2026): tap a photograph to pick it up, then tap the one it should stand in front of — and while one is picked up, two buttons offer To the start and To the end, the places no tile can stand for. That is the way to carry a photograph across a long album; touch-and-hold-then-drag still works for a move between neighbours. Selected photographs travel together either way, and nothing is published until Save order. (The same date fixed two iPhone faults here: holding a photograph no longer opens Safari’s own Save Image menu, and once a photograph is lifted the page no longer scrolls out from under it.)

The button holds the rest: Album details (name, year, path, the Unlisted switch — or Import, for an album still waiting), Films, and Delete, which still shows the album’s path and makes you type it back, exactly as demanding as at a desk.

Everything here is the same machinery as the desktop page — the same checks, the same refusals, the same pipeline runs; only the room is arranged differently. The desktop page is unchanged, and a window wider than 700px always gets it.

Cards & strips on a phone (25 August 2026)

The same treatment: on your iPhone, Cards & strips opens on three doors — Hero carousel, Letters home, and Country cards & strips — each a screen of its own, with the photo and entry pickers sliding up as sheets.

  • Reordering is touch: hold the ⋮⋮ grip on a carousel slide or a featured entry until it lifts, then drag. Captions are typed right in the row.
  • One Save, wherever you are. The bar along the bottom appears the moment anything is unsaved, names it (“Unsaved: carousel · a card · a strip”), and follows you across all three doors — wander freely and save once. Every refusal you know from the desk — a ragged Letters home row, an emptied carousel, a slide whose photograph is gone — appears in the same bar, before anything is posted.
  • Pinned vs automatic reads the same: solid is yours, dashed was chosen for you, and Auto hands it back.

As with Gallery cleanup: same machinery, same save, same refusals — only the room is different, and a desktop window gets the page you already know.

Two photo counts, and which one to believe (22 August 2026)

On Gallery cleanup the same album shows a number twice, and during a working session they disagree. Both are right; they are answers to different questions.

  • The droplist — “Cambodia 2009 — Siem Reap (749)” is what the site currently publishes. It changes when the site rebuilds, a minute or two after each run finishes.
  • The line above the grid — “685 photos” is what is in storage, read live, every time you pick the album. This is the one to believe. The grid shows exactly these photographs, and Remove, Rotate and Move all act on them.

Remove sixty photographs and the grid drops to 685 at once while the droplist sits at 749 until the site catches up. Nothing has gone missing. When they differ the line now says so — “685 photos · 0 selected · the site still lists 749 — it catches up a minute or two after each change” — so the gap reads as a delay rather than as lost work.

If the two are still apart long after everything has finished, that is worth a look: it means the record and storage genuinely disagree, and a sync run rebuilds the record from what is actually there. Ask a session, or run sync from the import workflow with the album’s country and path.

“This is already published as…” (25 August 2026)

An import email may now tell you that a photograph you have just uploaded is already on the site in another album, and name it:

IMG_4471.JPG
  is already published as mexico/2019/vallarta/IMG_0031.JPG

Nothing was removed, and nothing needs doing. This is a notice, not a fault. The site now recognises a picture it already holds wherever it holds it, and the same photograph in two albums is often deliberate — a picture that belongs to a city album and to a later retrospective both. Only you can tell that apart from the same batch being uploaded twice, so the pipeline tells you and stops there.

If it is a mistake: open the album you do not want it in on Gallery cleanup, tick that photograph and Remove. The other copy is untouched either way.

Inside one album the rule is different and always has been: the same picture twice in the same album is a mistake by definition, so the import removes the second copy and lists it. That has not changed.

“Held back, not published” (25 August 2026)

The other new line in an import email. A photograph that is 90% or more the same picture as one already in that same album is not added to the site:

IMG_4472.JPG
  96% the same photograph as IMG_4471.JPG — held back, not published

It is not deleted. The file is kept in storage, out of the album, and the email says so. Nothing else in the batch is affected.

If it should have been published — and this will happen, because two shots taken seconds apart can read as the same photograph — ask a session, or run the import for that album again with direction set to keep-near. That brings back every photograph held for that album and publishes them all.

Why 90%: it is the number you set. It catches the copy whose file is genuinely different — a re-export, a screenshot, a photograph that came back through a message — which the exact match cannot see. The price of catching those is that it occasionally stops a real frame, so it stops it reversibly.

Making albums for the phone (23 August 2026)

On the phone itself this moved (24 August 2026): the phone’s own upload page at /m has a + New album row inside its album list — same markers, same rules, same Unlisted switch — so on a phone you no longer open this panel. The panel below is still how it works from a desktop, and everything it says about markers and years holds for both.

The iPhone share sheet lists albums; it cannot make one. So when a trip needs three or four new albums, make them first, on the upload page — which works perfectly well in Safari on the phone, so this is not a trip to a desktop.

  1. Open the upload page and press + Create albums for the phone… under the destination.
  2. Pick the country, pick the yearthe year of the trip, not today — and type the album’s name. The address appears beneath: france/2019/champagne.
  3. Add to the list, then do the next one. Leave the name blank for a year-only album (france/2019), which 41 of the site’s albums are.
  4. To keep one off the site while you sort it out, flick Unlisted before adding it to the list — the switch is in the same panel, under the name. The list then marks that album unlisted, and so does the line beneath it.
  5. Create the albums. They appear in the phone’s list within seconds, empty and marked ◌ not imported. Share each batch to its album as usual.
What Unlisted does here (24 August 2026). The choice is remembered on the empty album itself, and the import made from the phone reads it back — so a batch shared to that album days later publishes unlisted, with nothing to remember and nothing to switch on afterwards. Without it the first batch is public from the minute it imports until you get to Gallery cleanup, which is exactly the window the switch closes. The album is then reachable only by its address, and Gallery cleanup → Album details puts it on the site whenever you are ready.
The name you type is kept now (1 September 2026). Type Basílica de la Sagrada Família Barcelona and that — accents and all — is what the album is called when its first batch imports. It used to be thrown away: only the address survived creation, and the import re-invented a name from the address, so an accented name came back mangled (Bas Lica De La Sagrada Fam Lia). Both halves are fixed: the typed name is remembered on the empty album alongside the Unlisted choice, and the address now swaps an accented letter for its plain twin instead of dropping it — spain/2026/basilica-de-la-sagrada-familia-barcelona, not bas-lica-…. Renaming later in Gallery cleanup → Album details still works and still wins — including against the next batch: an import used to quietly re-derive the name from the address and undo a rename you had just made (it happened with this very album, twice in one afternoon); now a later upload keeps whatever name the album holds. If you already have a mangled album from before this: while it holds no photographs, the simplest repair is to delete it in Gallery cleanup and create it again — clean address, name kept. If photographs are already in it, open Album details, fix the Name, and — only if you want the address clean too — edit the Path, which moves every photograph with it.
Why this exists. Before it, a new album was made by uploading one throwaway photograph to it — which is how four albums in a single week ended up holding a picture of a kitchen table, and holding the wrong year: two took a camera’s 2018 and two took today’s 2026, because nothing asked. Each then needed correcting in two runs, since the year lives in the address as well as in the record. Here the year is a question, asked once, and the album is born at the right address.

What actually gets written is an empty marker file, not a photograph — so there is nothing to delete afterwards, the album counts as 0 photographs until a real batch lands, and no gallery page can show it. A country the site has never had is refused here, because a new country needs a region and a display name that only the importer can be told: its first batch still goes through the uploader above.

Which year the upload page fills in (22 August 2026)

The Year box fills itself, and the rule is different in the one case where getting it wrong is easiest:

  • A country the site already has — the year is read from the first photograph: its EXIF date, or failing that the file’s own timestamp. That is usually right, because a batch being added to an existing country is usually an old trip being filled in.
  • A country the site has never had — the year is this year, always, and a photograph dropped afterwards does not change it. Somewhere brand new is somewhere you have just been. The path preview says which year it used, under the line about creating the country.
  • A year you choose yourself beats both, in either case. Once you touch the dropdown nothing overrides it.
Why the rule exists. On 22 August 2026 three new-country albums were created from photographs whose cameras said 2018, and the site filed them as netherlands/2018/amsterdam and spain/2018/madrid — the year shown plainly in the preview, and easy to read straight past. They have been moved to 2026. If it happens again: Gallery cleanup → Album details corrects the year, but the year is also in the address, so correcting it properly means moving the album — ask a session and it does both in one go.

A new country can only be made on the upload page (22 August 2026)

Creating a country needs two answers nothing can guess: its display name (“Egypt”) and its region, which decides where it files on the site. The upload page asks for both — the country list’s last entry is “+ a country the site doesn’t have yet…”.

The iPhone Shortcut and the share sheet cannot. They have nowhere to ask, so sending to a country the site has never had is refused on the spot, on the phone, with a line saying a country’s first batch has to go through the upload page. Nothing is uploaded, so nothing is stranded. (Before 21 August the upload was accepted and the import failed three minutes later by email, which is how a batch of Iran photographs went missing for a day.)

The refusal can only work when the phone can read the site’s country list. In the rare case it cannot, the upload is allowed through rather than blocked, and the import then fails with “No country ‘X’ on the site” by email — recoverable, since the photographs are in storage: import them again with the right country and the batch relocates itself.

The Worker box on the admin login

The login is www.traveller.org/api everywhere (30 August 2026). That address has been the offer since the route landed — but a workers.dev address remembered from the early days beat the offer forever on the test site, and on a network that black-holes that hostname it read as being locked out of the admin. Every admin page now clears exactly that stale remembered value, on either site, and offers /api; an address you typed yourself is a choice and stays, and the login still falls back to the Worker’s own address by itself if the /api route ever goes missing.

Checking the address in a browser (30 August 2026): www.traveller.org/api now lands on the upload page rather than a 404 — the Worker’s mount needs the trailing slash, and the bare spelling used to miss it, which read as “wrong address” at exactly the wrong moment. Either spelling is fine in the Worker box; the login only ever calls addresses beneath it.

It should read https://www.traveller.org/api, and you should not have to type it: the box offers that address by itself, on the live site and on staging alike. It is the same Worker as traveller-upload.brarob.workers.dev, reached by the site's own name — which is what stops browsers, networks and blockers interfering with it, and they have.

The address to type for the uploader itself is upload.traveller.org (14 September 2026). Same Worker, same passphrase, same pages — upload.traveller.org for the desktop form and upload.traveller.org/m for the phone one, though a phone opening the plain address is sent to /m by itself. It exists because the other two are awkward to say out loud: this is the one to put on a phone’s home screen or read to somebody helping with a batch.
It does not replace anything. The box in the admin login should still read https://www.traveller.org/api — that one is same-origin with the admin pages, which is what keeps browsers and networks out of the way — and the iPhone Shortcut still carries the workers.dev address and needs no change. Three addresses, one Worker, all live.

You should not have to clear anything. The one address every browser was holding — the worker's own traveller-upload.brarob.workers.dev, left behind by the builds that filled the box with it automatically — is dropped on this domain the first time a page loads, since /api replaces it. An address you typed is a choice and stays.

If a page still shows an address you do not want, type over it and press Connect — it sticks. Or press Sign out, which now forgets the address as well as the passphrase, and let the box fill itself in.

What to expect when something is wrong. Every call the login makes gives up after fifteen seconds and says so. If you see “The worker did not answer within 15 seconds”, the address in the box is not reachable from that network — sign out and let it re-offer, or try another connection. What you should never see again is an admin page that simply sits there showing nothing, which is what a hostname being silently dropped used to look like.

“The browser blocked the call before it left.” That message means the request never reached Cloudflare at all — so the worker, the passphrase and the address are all innocent, whatever it looks like. Proof takes ten seconds: open https://www.traveller.org/api/galleries in a tab of the same browser. If it prints wrong passphrase, the network is fine and something in the browser is refusing the call the page makes.
Why it hits the staging site hardest. Staging is on github.io, so its admin pages must call the worker on another domain — a cross-site request, which an extension or a privacy setting can refuse wholesale. No address fixes that; there is no same-origin route to offer, and there cannot be one on GitHub Pages. Two ways through: use the admin pages on www.traveller.org, where the call is same-origin and nothing is cross-site (you will meet the Cloudflare Access code first), or open staging in an incognito window, where extensions are off.

“Unlisted” and “not imported” in the pickers

Two kinds of row are in storage but off the site's public lists, and until 20 August they shared one word. They are now told apart, because they need opposite things done to them:

  • · unlisted — a real album, imported, with a page of its own, that you deliberately took off the lists. The Unlisted switch under Album details is its control.
  • · not imported — a folder of photographs that reached storage and was never processed. It has no page, no name, no year, no thumbnails and no record, so none of the Album details fields apply to it: pick it and the card shows a single Import this album button instead of the fields.

The difference is read from thumbnails, which only the import makes. Before this, flicking the Unlisted switch on a never-imported folder started a pipeline run that could only fail — “No album at brazil/2004” — because there was no record to change (owner, 20 August 2026).

Both sit in alphabetical order with everything else (22 August 2026). They are found by comparing storage against the site’s public list, and for a while that showed: they were added after the site’s own albums and arrived as a clump at the foot of every droplist, so reaching the folder you had just uploaded to meant scrolling past every published album on a phone. Where an album sits in a picker is its name, not where it was found.

Because they are no longer grouped, each carries its own mark, and on the upload page the mark also leads the row — since on a phone the label wraps to three lines and a note at the end of it is off the bottom of the row. The words are still there; nothing depends on recognising a symbol.

The destination droplist

Belgium — 1996 (1 photos)  ·  belgium/1996  ·  not imported
Peru — 2010 (9 photos)  ·  peru/2010
Peru — Reunion (18 photos)  ·  peru/2004/reunion  ·  unlisted
Unlisted album Imported, with a page of its own, deliberately off the site’s lists. The Unlisted switch under Album details is its control.
Uploaded, never imported No page, no thumbnails, no record. Its control is the Import this album button.
none
An ordinary published album

The same two marks lead the lines of the iPhone Shortcut’s album list — see Photos from the phone.

So, with a · not imported folder: import it from Gallery cleanup (optionally ticking Import it unlisted on the way in, which you can change afterwards), or ask in a session to prune it if the files are strays. Pruning deletes only the files sitting directly in that folder — never an album nested inside it.

If the strays are inside a published album’s folder — one odd file among the album’s own photographs — ask for prune-files instead, which names files rather than sweeping a folder. It refuses to touch anything the site publishes, and when sweeping it keeps any file that is the only copy of that photograph and tells you which. See the pipeline page.

A photograph that arrives with no file extension is now sorted out for you. The iPhone share sheet sometimes hands a photograph to the Shortcut without its filename attached, and it then lands in storage as IMG_5064 rather than IMG_5064.jpeg. Those used to be counted as stray files and quietly left out of the album, while the run still reported success. The upload now takes the extension from the photograph itself as it stores it, and the import repairs anything already sitting in storage without one — the review email lists each rename. Nothing to do at your end, and nothing in the Shortcut to change. See the pipeline page.

Storage folder names are case-sensitive, and the site's country slugs have no separators in them (unitedstates, hongkong). The upload now folds a typed country onto the roster before storing anything — Mexico, united-states and Hong Kong all land in the country that exists — and the import folds the same way, so the two ends of one upload cannot disagree about where the photographs are. A country the site has never been to is left exactly as typed, and the import then asks for its region and display name. Folders that pre-date this are tidied with a prune, or imported with the right country from Gallery cleanup.

Banknotes: symbols, and currencies that are not countries

Every note headline leads with its currency's symbol₹100, €10, ₤1000and so does every heading that names a currency: the library page heads The Euro — €, and the banknote band on a country page reads The Peseta · ₧ — banknotes (2026-08-20). The symbol is a modern label, not a claim about what is printed on a 1975 note, and it is typed once per currency in the site's data. A country new to the library arrives without one, because nothing in a filename says “₱”: the build log names any currency still missing its symbol, and the test suite fails until it is added. Ask in a session and it takes a minute.

The euro is a currency, not a country. It has its own page in the Banknote Library and its own note pages, but no country page, no card on The Countries, and no share of any “N countries” the site quotes — the library's own line reads “from 51 countries and the euro”. Instead, every country that uses it shows the euro band on its own page, above that country's older notes: Spain leads with the euro and the peseta sits beneath it. Germany and Luxembourg, which have no notes of their own here, show the euro band alone.

Uploading euro scans works exactly like any other — name the files euro-50-f.jpg and the import takes them without asking for a region, because the euro has no country to file. If another shared currency is ever collected, ask in a session: it takes one line, plus the list of countries that use it.

The contact form, and where you can test it

The form at Contact is live on www.traveller.org — and, since 20 August 2026, on the staging site as well. A message sent from either one is a real email that arrives in your inbox, and hitting Reply answers the person who wrote it.

How to tell a live form from a dormant one at a glance: a dormant one carries a grey line under the button reading “Test build: the form is display-only” and shows a drawn checkbox that does not respond to a click. That is a build that was made without the two public keys — not a broken CAPTCHA. A live one has neither: it shows Cloudflare's own I'm not a robot widget, which ticks itself for most visitors.

The words now sit beside the form rather than above it, below the photograph, as the design had them originally.

Publishing by asking

The Publish button is one way; saying so in a session is the other. Tell Claude “publish it” (or “publish to prod”, “push it live”) and the live site is updated from the reviewed staging trunk, exactly as the button does it — Claude names what is going out first, runs it, and checks the result on www.traveller.org.

Without that phrase nothing reaches the live site. Every change — a fix, an import, a whole feature — lands on staging and waits there. That is the point: staging is where you look at it, and the live site changes when you say so and not before. Claude may offer to publish; it does not decide to.

One phrase, one publish: saying it today does not authorise tomorrow's work. And if anything is failing, Claude says so and asks first — “publish it” approves the deploy, not skipping the checks.

What has already gone live

Under the Publish button, Publish now lists Previously published — every press of that button, newest first, with the date and the changes it carried. The newest one is open; the rest fold. It sits below what is waiting to go out, because what is about to happen is the decision on that page and what already happened is reference.

The list is worked out rather than kept: each press of Publish is one run of the publish job, so consecutive runs bracket exactly what went out between them. Nothing to maintain, and nothing that can drift out of step with the branch. The oldest entry says “earliest publish on record” and lists nothing — it has no earlier run to be compared against, and an empty list there would read as a publish that carried nothing.

Delete a banknote

On Banknote pages, open a note and use Delete this note, set apart at the foot of the editor. It asks first, naming the note.

This is permanent, and it takes the pictures. The note comes off the site and its scans are deleted from storage — every tier, both sides. The only copies left are the batch zips on zip records, until you clear those too. Chosen deliberately over a record-only removal (owner, 2026-08-19), which would have left the scans in storage and put the note back on the next currency run.
If it was the country's last banknote and the site has no photographs or journal entries from there either, the country comes off the site with it — the same rule deleting an album follows.

An album only people with the link can see

An unlisted album is built and served exactly like any other, and appears nowhere on the site: not on the home page, not on its country page, not in Photographs, not in any of the counts the site quotes, not in the sitemap, and not in llms.txt. Search engines are told not to index it. The only way to it is its address.

What the album’s own page shows

To everyone who opens it: a single purple bar under the breadcrumb reading UNLISTED. One word, no explanation. Somebody you sent the link to should be able to see that the page is not part of the public site — that is orientation, and it costs nothing. And it is the same bar you use to check you are on the right album.

On both views (22 August 2026). An album page is two screens — the photo view you land on and the gallery grid behind View gallery — and the bar sits at the top of each. This matters because of how a single photograph gets shared: an address ending #p2 opens the photo view with the grid hidden, so a bar on the grid alone would disappear at exactly the moment one photograph is being passed around on its own.

The explanation is here and nowhere else. Until 22 August 2026 that bar was a paragraph, served to every visitor, which read:

Unlisted album — this page is linked from nowhere on the site, appears in no listing or count, and is not indexed by search engines. It is not private: anyone who has this address, or is sent it, can open it. Hide or unhide it on Gallery cleanup.

Every word of that is true, and it is the difference between a label and a briefing. The label tells a visitor where they are. The briefing told them the album is meant to be unfindable, that nothing guards it, and where the control that governs it lives — three facts that are yours, not theirs. It is recorded here so the explanation is not lost, and it is not on the album any more.

The bar is written into the page when the site is built, so it is there for everyone with no passphrase and no waiting. It is also the only thing on the page that mentions the word: a published album’s page never says it at all. The test suite counts the occurrences on both and fails if a paragraph creeps back in.

Unlisted now has a door on the live site (27 August 2026). On www.traveller.org, opening an unlisted album’s page asks for the friend password first — see Friends: the door and the password below. Two limits are worth holding in mind. The test site has no door at all: it is plain files on GitHub Pages, so there the link alone still opens the album, exactly as before. And the photograph files themselves still sit at ordinary public addresses on images.traveller.org — the door is on the pages, not the pixels; putting a gate in front of every image was offered and declined when unlisted albums were built (2026-08-19), and that call stands. So the old advice still applies to the photographs: fine for family, not for anything that would matter if it travelled.

Two ways to set it, and they do the same thing:

  • When you upload — on the upload page, open Upload settings and switch on Unlisted album before pressing Upload. The bar at the bottom then reads “Upload 43 photos → Halong Bay · unlisted”, so the decision is in front of you at the moment you commit to it. Set this way the album is never public, not even for the few minutes between the upload and your next Publish.
  • Afterwards — on Gallery cleanup, pick the album under Album details and flick the Unlisted switch, then Save changes. This is also how you put one back on the site. (The switch is the control; the paragraph under it is only the explanation, so clicking that cannot change anything by accident.)

You can see them on the country page (22 August 2026). Open a country’s page in a browser that holds the admin passphrase — the same one the admin menu remembers — and any unlisted album for that country appears in the country’s own list of albums, in its year’s place, as a purple-edged card marked ⊘ Unlisted. A note under the list says why you are seeing them.

What the card looks like (24 August 2026): a solid purple band across the top of it reading ⊘ UNLISTED — visible to you, not on the public site, with the album’s year, name and Gallery → link in the same purple beneath. It replaces the small outlined pill that used to sit under the photograph count: on a phone the card stacks into four short grey lines and the pill read as one more of them. It is the same purple, word and glyph as the bar on the album’s own page, so the two places an album says unlisted say it the same way.

In the timeline, not underneath it (24 August 2026). Until then the unlisted albums were collected in a block below the list, which answered what is hidden? — a question you can already ask on Gallery cleanup. The question a country page is for is what is there from 2019?, so that is where the album now sits: between 2024 and 2015 on Mexico’s page, in the same order as everything else, with the marker doing the work of saying it is not public. Legacy 800px albums stay at the bottom as they always have.

Two things about that are deliberate. The counts do not move: the galleries and photographs totals at the top of the page are the public ones, and an unlisted album is documented as absent from every listing and total — changing them for you would mean the number you see is not the number the site publishes. And the album is not in the page: the built HTML that anyone can download names it nowhere, whatever they do with CSS or View Source. Your browser fetches the list from the upload Worker, which asks for the passphrase before it answers. A folder that was uploaded and never imported is not shown here, because it has no gallery page yet — a card for it would be a link to nothing. Import it from Gallery cleanup first.

Finding one again is the part that needs saying, because an unlisted album is linked from nowhere: pick it in that same droplist on Gallery cleanup, where unlisted albums are marked · unlisted, and the page prints the album’s address for you to copy. That droplist is the only list of them anywhere — the site’s public gallery feed deliberately leaves them out, since it is a file anyone can read.

Uploading more photographs into one is the same as any other album: choose it as the destination and upload. It stays unlisted — a second upload cannot quietly put it back on the site.

If an album you created unlisted ever shows up public (it happened once, 30 August 2026 — the choice was lost when the album folder already existed at creation): flick the Unlisted switch on under Album details and it is repaired in a minute. Both ends now carry the choice independently — the builder re-marks an existing folder, and the import reads the mark itself — so the same loss cannot recur. Details on the pipeline page.

Friends: the door and the password

Since 27 August 2026 the live site has a friends door: one shared password that opens every unlisted album. It is made for the people you’d hand a printed album to — they sign in once and the device stays signed in for about a year.

What to send a friend

Either of these, whichever suits the person:

  • The address and the password. Send them www.traveller.org/friends/ and tell them the password. They type it once and land back on the home page with a slim purple banner across the very top — “Signed in as a friend — hidden albums and photographs are visible to you, but not publicly available” — on every page, for as long as they stay signed in.
  • The one-tap link. Send www.traveller.org/friends/login?key=the-password — tapping it signs them in and opens the home page, nothing to type. The password rides inside that link, so send it the same way you’d send the password itself.

A friend who follows a link to one unlisted album before signing in is not lost: the page asks for the password and then carries them on to the album they were opening.

Where a friend finds the hidden things (28 August 2026). There is deliberately no friends page to browse — a signed-in friend meets hidden content where it lives. On a country page, that country’s unlisted albums appear in the timeline in their year’s place, each carded ⊘ Unlisted · visible to friends — the same cards you see as admin. Inside a public album, the friends-only photographs are woven into their true positions, and each one carries a small purple flag — Friends Only — Not in Public View — across the top of its tile and above it in the photo view, so a friend always knows which photographs the public page does not show.

And one place lists them all (30 August 2026): the Photographs page (/galleries/ — where the nav’s Photographs goes) shows every unlisted album, whatever its country, in a block of cards under the public listing, each named with its country — Spain — Ibiza. This works signed in as a friend or holding the admin passphrase, and it exists because before it, a country’s own page was the only page that could show its unlisted albums — publish an album as unlisted, look anywhere else, and the site showed no trace of it, which reads exactly like the album being lost.

If an unlisted album looks missing on the live site (30 August 2026). It is almost always the browser you are looking with, not the album — so check in this order. 1. Are you on www.traveller.org? 2. Is the purple Signed in as a friend banner across the top? No banner means this browser is not signed in, whatever it did earlier: sign in again at www.traveller.org/friends/. 3. With the banner showing, the album is in three places — its own page, its country’s page, and the Photographs page, which lists every unlisted album whatever its country. 4. Signed in in a private / incognito tab? That sign-in does not carry to your normal tabs — each has its own cookies — so sign in again in a normal one. Different browsers are separate too: signing in on DuckDuckGo does nothing for Chrome. 5. Missing from the uploader’s album picker or a Gallery cleanup droplist rather than from the site? That is a different list, built by the Worker walking storage — and note it names an unlisted album by its folder, so it reads ibiza, not Ibiza. 6. Still nothing? Hard-refresh once. The whole journey — sign in, open the album, find it on both listings — is checked on every push by tests/friend-sees-album.test.mjs, over the real albums by name, so a genuine site fault would fail a test before it reached you.

Sharing one album over text (28 August 2026)

Open the album on the live site (for an unlisted album you’ll be signed in as a friend to see it at all) and press Share with a friend in the purple bar at the top. Since 4 September 2026 the same bar appears on a public album that carries friends-only photographs — signed in as a friend, you’ll see Friends-only photographs — visible to you above the album with the same button, since the mixed view is exactly the thing worth sharing. A stranger’s copy of the page has no bar at all — it only appears once the friends door has answered for you. On a phone that opens the share sheet straight into Messages; on a computer it copies the link. Either way the link is the one-tap kind: it carries the friend password, signs the person in for a year on that device, and lands them on the album you shared — nothing for them to type.

Treat the link like the password, because it contains it — fine to text a friend, not for anywhere public. The button appears only when you are signed in as a friend yourself, and the password inside the link is filled in by the server at that moment: it lives in no page. Rotating the password kills every link ever shared this way, along with every signed-in device.

Where the password lives, and how to change it

The password is the FRIEND_KEY setting on the Cloudflare Pages project — never in the site’s code and never on any page. In the Cloudflare dashboard: Workers & Pages → the site’s Pages project → Settings → Variables and secrets, add or edit FRIEND_KEY for Production, then redeploy (the next Publish does it). Changing it signs every friend out at once — that is the whole reset if the password ever travels too far. Until you set it the first time, the door stays shut: unlisted pages answer “switched off” rather than opening.

What it does and does not cover

  • Covered: every unlisted album’s pages on www.traveller.org, and the friends-only photographs inside public albums.
  • Not covered: the test site (plain files, no door — unlisted albums there open by address as they always did), and the photograph files on images.traveller.org, which remain public addresses.
  • Separate doors: the friend password is not the upload passphrase and not the admin sign-in — three different keys for three different rooms. You can sign in as a friend yourself on any device just by knowing the password.

One photo hidden from the public, inside a public album (27 August 2026)

Separately from whole unlisted albums, any photograph in a public album can be marked friends-only: it comes off the public page and out of every count, and a signed-in friend sees the album complete, each hidden photograph back in its true place. Nothing moves in storage — this is a visibility switch, not a file operation.

To mark or unmark: open the album on Gallery cleanup, select the photographs, and press ⊘ Friends-only (or Public again). Or do it where you spot it (3 September 2026): on any high-resolution album’s photo view, the admin bar above the photo has the same ⊘ Friends-only button for the photograph on screen — and on a friends-only photograph (signed in as a friend, so it is woven into the album) the button reads Public again and reverses it. It refuses the last public photograph, the same guardrail as everywhere else. On the phone the action bar has one Friends button that reads the selection: photographs already marked go public again, anything else gets marked. Marked photographs wear a purple ⊘ friends badge in the grid — the same purple as the Unlisted mark, one colour for “the public does not see this”. The change lands in a minute or two, like a rotation.

  • What the public sees: the album without those photographs — counts, opening frame and sharing image included. Their filenames appear nowhere in the page.
  • What a signed-in friend sees: the whole album, woven back into order, on the live site. On the test site everything is visible to anyone with the address, as always.
  • What you see: everything, always — Gallery cleanup lists storage itself.
  • Two limits: marking every photograph is refused — that is the Unlisted switch’s job — and a photograph moved to another album arrives public there (the run log says so; re-mark it in its new home if wanted).

A wrong guess costs a delay and the door never says whether it was close. The sign-in page is deliberately unlinked from the public site — a hidden address, which costs a stranger one more thing to know without costing a friend anything.

An unlisted film (1 September 2026)

A film can now be unlisted the way an album can: off the public site entirely — the films pages, the home-page strip, every count and every machine feed — while a signed-in friend sees it on the films pages in its country’s own group, marked by a small purple ⊘ Unlisted chip on the poster — the duration chip’s own shape, in the colour that means “the public does not see this” — and plays it there like any other film. A note under the list explains the chips once, the way the album pages do.

Two ways to set it:

  • At upload — both film upload forms (desktop and the phone page) have an Unlisted switch beside the description. The choice travels with the clip, so the film is never public for even the few minutes between conversion and curation.
  • Any time afterGallery cleanupFilms: each film’s row now has an Unlisted tick beside Country and Home. Tick, save, and the next build drops it from the public site; untick to bring it back. Unlisted films stay in this list always — it is the one place that shows you everything.

The one honest limit, chosen deliberately: unlisted means undiscoverable, not unwatchable. The film’s .mp4 file keeps its public storage address — the same standing rule as every photograph on the site — so someone holding the direct file link can still play it. Nothing on the site, in Google or in the AI feeds will hand that link out.

Choose the picture on a country card or a gallery strip

Both choose themselves already: a country’s home-page card shows a photograph from its first gallery, and each gallery’s strip on the country page shows four spread evenly through the album. Cards & strips is for pinning a particular picture instead.

  1. Open Cards & strips, connect, and pick a country. Only countries with high-resolution photographs are listed — there is nothing to pin in a legacy album that is being retired.
  2. Home-page card: Choose… opens every photograph in that country, gallery by gallery. Auto hands it back.
  3. Gallery strips: each gallery shows its four slots, already filled with the photographs the site is showing today — dimmed and dashed means chosen automatically, solid means pinned by you. Tap one to pin a photograph — the picker is locked to that gallery, since a strip only ever shows its own album. Auto on a row clears that whole strip.
  4. Save changes sends only what you actually changed, and the site rebuilds in a few minutes.
Pins are safe against re-imports. They live in their own records rather than on the gallery, so adding photographs to an album later does not disturb a strip you have curated. If a pinned photograph is ever deleted, that card or strip quietly returns to the automatic choice rather than showing a gap.
You can only pin what the album publishes. The picker shows the photographs in that album’s record — the ones the gallery page actually shows — not everything sitting in its folder in storage. The two differ when photographs were added to a folder after its last import: brazil/2005/rio held 159 files and published 18. Pinning one of the other 141 would have shown nothing, and the run refused it one at a time (owner, 20 August 2026). If a photograph you expect is missing from the picker, that album needs a sync or a re-import — ask in a session.
A folder marked · not imported is not offered here at all: with no record there is nothing to pin into and no thumbnails to choose from. Import it on Gallery cleanup first, and it appears here like any other album.

Add a film — one clip at a time

  1. On the bulk upload page, switch the toggle from Photos to Film.
  2. Fill in Country / year (e.g. vietnam/2009), an optional Location (e.g. Halong Bay), the Title, and a sentence or two of Description — the title and description are shown on the site exactly as typed.
  3. Drop one video (.avi / .mov / .mp4 — anything under ~5 minutes is ideal), then click Convert & publish →. GitHub Actions converts it to a web-playable MP4 (ffmpeg, H.264), grabs a poster frame, and the film goes live a few minutes later on the country page, the country's films page (/countries/vietnam/films/), and the site-wide films page.
  4. After the hand-off the film form clears — title, description, location and the video are emptied so nothing carries over to the next clip. The country / year is deliberately kept, since the next film is usually from the same trip.
  5. Repeat for the next clip — one at a time keeps each title and description attached to the right file.
  • The original file is not kept in the bucket: it goes into the emailed zip record (with the converted MP4) and is then removed — same policy as RAW photos. If a conversion fails, the original stays put untouched and the email says so.
  • Re-uploading a clip with the same filename to the same country/year replaces that film — handy for fixing a title or a bad encode.
  • To fix just a title or description after the fact, tell Claude — it's one line in src/data/films.json. (The CMS will make this a form field at launch.)
  • On a phone, tapping a film opens the big player straight away (24 August 2026). On a desktop it plays in its card, with ⛶ Enlarge video beside it; on a phone or a tablet that card is smaller than the poster that was just tapped, and the Enlarge button sits below the fold — so there the film opens full-width immediately, with a ✕ Close on it. The picture never restarts when the player changes size: it is the same video, moved.
  • Every film on the site starts silent. Pressing play begins the picture with the sound off, and a 🔇 Sound off chip on the player turns it on and then disappears. A film that starts talking is startling on a page somebody is reading — and browsers block an autoplay that has sound anyway, so unmuted would not have meant loud, it would have meant the film did not start at all. Nothing to set per film; it is how the player behaves everywhere films appear.

Remove photos (admin only)

Two ways, both permanent — the photo comes off the gallery and is deleted from storage to save space. No copy is kept, so download anything you want to keep first (the batch zips are the archive of record).

  • While viewing: on any high-resolution gallery's photo view, ↺ Rotate left, ↻ Rotate right ⊘ Friends-only and Remove from gallery sit above the photo, upper right — on a computer; on a phone the same five buttons live behind the single Admin ⋯ chip at the foot of the photo view, which opens them as a bottom sheet (see “The photo page on your phone” below) — so a sideways or unwanted frame can be fixed where you spot it, without opening the cleanup page. Rotation runs on the server like everywhere else: the message says so, and the turned photo appears after a reload a minute or two later. Remove asks for confirmation, then lands on the next photo in order. These controls only exist on this browser because it holds the upload passphrase — sign in once in the admin menu (any admin page) with "Remember on this device" ticked to switch them on (the upload page's own passphrase is stored under the worker's address, which the site cannot read) — visitors never see them, and the Worker re-checks the passphrase on every call, so hiding them is cosmetic, not the security.
  • In bulk: the Gallery cleanup page — pick a gallery, click thumbnails to select (Select all / Clear helpers), then Remove N selected. The grid lists what is in the bucket right now, so it's always current even mid-cleanup. Portrait photographs stand upright in the grid (2026-08-20) — the tile takes the photograph's own orientation instead of cropping everything to a landscape sliver, which also makes an upside-down portrait recognisable at a glance before rotating it.
    Finding the album in the droplist (changed 2026-08-18 at your request): albums are grouped by country, and within a country they run alphabetically by name — Agra, Bombay, Delhi, Goa, Gokarna… Where the same place was photographed on several trips those albums sit together, oldest first, and the path after the · tells them apart (india/1998/delhi vs india/2005/new-delhi).
    They used to be ordered by year of travel without looking like it: the sort tied on the album's path, and every path begins with the year, so finding a city meant remembering which trip it was on. Every droplist that lists albums reads one file (gallery-index.json), so the Photos, Covers and Journal pages and the upload page all changed together.
  • Rotate instead of remove: the same page's ↺ Rotate left / ↻ Rotate right / ⟳ Rotate 180° buttons turn the selected photos. An upside-down photo is one click now — 180° is its own run, added 2026-08-20 after a half-turn as two quarter-turn runs meant two waits with re-finding the photo in between. Rotation is image work, so it runs on GitHub Actions — allow a minute or two, then reload. A rotated photo gets a new filename (-r1, -r2, …): the old one is cached "immutable" for a year, so turning it in place would leave stale sideways copies in browsers and on the CDN. Its position in the gallery, place tag, and any home-page cover reference all carry over — and the grid on this page now shows it in that position straight away. (It used to show a just-rotated photo at the end until the site redeployed, which read as the photo having moved; it never had.)
  • Move photos to another album: on the same page, select the photos, pick the destination under Move to… (any high-resolution album), and hit → Move. The files are copied inside storage — no re-upload, thumbnails included — then removed from the source. They append to the end of the destination's publishing order, untagged (place folders describe the source's geography, so retag on the destination if wanted). A filename already taken there gets a -m1 suffix. Moving every photo out of an album is refused — that is a delete or a rename, done deliberately instead.
  • Arrange the publishing order: the photo grid on the Gallery cleanup page runs in the album's publishing order — the sequence readers see. Drag a photo to a new spot — or select a series and drag any one of them: the whole selection travels as a block, in its own order, with a count on the tile so you can see how many are moving (2026-08-20). Hold the drag near the top or bottom of the window and the page scrolls itself, so a group from the bottom can be walked all the way up a long gallery in one motion. ⇤ To front stays as the shortcut for the classic "lead with the best shots" move; then Save order. The order survives later removals, rotations and added batches: survivors keep their positions, new photos append at the end.
  • Curate the films: the Films card on the same page. Pick a country, drag its films into order, and tick where each one features — Country shows it on the country page (first three ticked; none ticked = first three in order), Home puts it in the home page's "Films from the road" section. Save, and the site rebuilds with the new arrangement. Every films page (country page row, per-country films page, the site-wide films page) follows this order.
  • Correct an album's name or year: the Album details card on the same page. Pick any album — legacy ones included — and its current name and year fill in; change either and hit Save changes — the button reads Saved ✓ for a moment and a green confirmation line appears under it, naming what was saved. The site rebuilds itself and the new name appears on the gallery page, the country listing, and everywhere the year is derived (sort order, the country's travel span). Save only lights up when something actually changed and the year is four digits.
  • Correct an album's path (a mistyped year or name in the address itself, like china/2025/great-wall for a 2005 trip): the same card shows the Album path field for high-resolution albums. Type the corrected country/year/name and hit Save & move album — every photo is relocated inside storage (no re-upload) and reprocessed at the new address, done in a few minutes. Two things to know: links to the old address stop working, so correct a path early rather than after it has been shared; and the field refuses to move an album onto a path that already exists — that would merge two albums, which is what the photo Move tool is for, done deliberately. Legacy albums have no path field: their images live on the old server, untouched.
  • Delete an entire album: the red card at the bottom of the Gallery cleanup page. Being signed in is all it needs; no album's photos have to be loaded first. Pick any album from the red card — every row is the album's own name, with · legacy 800px or · unlisted after it when that is what it is — then type its path to confirm (a click alone can't do it). The path to type is shown in the label and in the box itself, the album's own address rather than an example (24 August 2026): pick the album, read burma/2001/rangoon beside TYPE THE ALBUM PATH TO CONFIRM, type that. A high-res album is purged from storage and comes off the site: permanent, with the batch zips as the only archive. A legacy album just comes off the site (record + repo thumbnails); the old scans stay untouched on the legacy server — use this to retire a deprecated album early once its replacement is uploaded, instead of waiting for the launch prune. A confirmation email arrives either way.

After a removal the pipeline syncs the gallery record and the site redeploys itself — allow a few minutes for the public pages to catch up. The photo view updates instantly for you. Legacy 800px galleries have no removal controls; they're deprecated wholesale and pruned at launch.

The photo page on your phone (6 September 2026)

Opening a single photograph on a phone used to spend the screen on everything but the photograph — masthead, crumb, album title and, for you, the five admin buttons, with the picture squeezed to about a tenth of the glass. You chose Option A of the photo-view design boards and it is built:

  • One slim bar under the masthead: the country chip on the left, the album’s name in the middle, the all-photos chip on the right. Both ways out of a photograph are still one tap away.
  • The photograph takes the full width of the screen, with a 5px sliver of the white mat above and below — about a third more picture than before, and it is on screen the moment the page opens instead of below the fold.
  • The album name and photo count moved below the picture, where the caption already was.
  • Your admin buttons collapsed into one chip. Only you ever see it: a small red-outlined Admin ⋯ chip below View gallery. Tapping it slides the same five buttons up from the bottom — Rotate left, Rotate right, 180°, Friends-only, Remove — each full-width and thumb-sized, with Done to put them away. They are the same buttons doing the same things; only where they sit changed, and only on a phone.
  • Nothing changed on a computer, and nothing changed for visitors except the bigger photograph.
  • A chevron on each edge of the photograph says it slides (9 September 2026: “needs an indicator to slide to change photo”). Two small round ‹ › marks ride the picture’s edges at mid-height, upright and sideways both — the cue that a swipe turns the page, and buttons in their own right. They are the same Previous/Next the desktop’s edge strips use, restyled small enough to cover nothing.
  • Turn the phone sideways and the photograph takes the whole window (added later the same day: “iPhone horizontal should snap to the window”). Rotating used to squeeze the desktop layout into a sideways screen, leaving you pinching; now the picture fills the height on a dark ground with just the photo count in the corner, which fades once you have read it and flashes back at each swipe. Swiping still turns the pages; rotate back upright to get the page — and the admin chip — back.

Swiping left and right still turns the pages, and Previous / Next are still under the caption. If the photograph looks small in a way these changes should have fixed, check you are not in an old tab — a page open from before a publish keeps its old layout until it reloads.

Tag photo locations (bulk)

  • Country is always inherited from the gallery; place (city/site) is the taggable field, stored in src/data/places.json.
  • Interim path: tell Claude the ranges — "tag Burma 2001 photos 1–124 as Rangoon". Ranges, lists, or "the rest" all work.
  • CMS later: open the gallery's tagging screen, click/shift-click to select, pick or type a place, Apply. Same gesture to retag; clearing a tag returns photos to the ungrouped pool.
  • Tagged galleries render with the place subnav and section headers; untagged ones stay a single grid. No tag is ever required.

Uploading from your iPhone

The upload page now works fully from a phone: tap the big box and it opens your photo library — multi-select as many as you like — and a new gallery needs no path typing at all: pick the country, confirm the year (it pre-fills from the photos' own dates), type just the name. HEIC uploads as-is, photos publish upright, and big photos shrink on the phone before uploading so a batch costs about a quarter of the data. There is also a one-time Shortcuts setup that puts "Upload to traveller.org" in the Photos app's share sheet. Setup steps for both — home-screen app and share sheet — are on the iPhone uploads page.

The tools are at the foot of the uploader (13 September 2026). Both uploader pages now end with the same row: Publish to the live site first, then Gallery cleanup, Cards & strips, Banknote pages, the Journal editor, All tools and the Manual. The phone page has had it since 27 August; the desktop page joins it, because a batch finishes and the next thing wanted is almost always Publish. Every one opens in a new tab on purpose — the uploader may be holding a chosen album and a prepared batch, and navigating away throws both out — and they all point at staging, which is where the master set of admin pages lives.
Which tab am I on? The upload page handles three different kinds of thing, and each tab now carries the icon of what it takes — 🖼 Photos, 🎬 Film, 💵 Notes. The same icon and the word lead the page heading and the browser tab, so the answer is on screen once the tabs have scrolled away.

For photographs that live in iCloud Photos on a machine that is not the one in front of you. Nothing downloads to your computer or your phone: you hand the site the link Photos makes, and the originals are copied from Apple straight into the album on the site’s side, then imported onto staging exactly like a dragged-in batch (Publish sends it live) — same 2048px size, same thumbnails, same duplicate check, same confirmation email.

  1. In Photos (iPhone, Mac, or iCloud.com): select the photographs, Share, Copy iCloud Link. It looks like https://share.icloud.com/photos/0abc…. An emailed link from Photos is the same thing — copy the address out of the email.
  2. On the desktop upload page: choose the Destination as you would for any batch (an existing album, or + New gallery with country, year and name; tick Unlisted if it should be), then open + Fetch from an iCloud link… below the album builder, paste the link, and press Fetch & import →. The status line repeats what the site said.
  3. On the phone page (/m): choose the album on the home screen, tap Or paste an iCloud link under the button, paste, and the button becomes Publish from iCloud. The Done screen says what started; an album created unlisted stays unlisted without being asked, as it does for a shared batch.

Then it is the usual few minutes: the run copies the originals, imports them and deploys staging; the confirmation email lists what arrived. Things worth knowing:

  • The link carries no country, year or album name. Apple’s share holds the photographs and their dates, nothing else — the Country / Year / Album lines you type under a link in an email are never read by anything. The album is whatever you chose on the page: the Destination on the desktop (an existing album, or + New gallery with country, year and name), the chosen album on the phone. Press the button before choosing and it says so, in red, and nothing starts.
  • You know it started when the receipt appears at the top of the page — the same card an upload gets, naming the album and linking to the run — and the panel’s status line repeats the site’s sentence. No card, nothing started.
  • The same photograph in two links (or one link pasted twice) arrives once: an original already in the album at its size is kept, not fetched again. A different photograph wearing a name the album already holds is numbered on (IMG_2427-2.JPG) — nothing is ever written over. And the import’s own duplicate detection — pixel fingerprints, checked across the whole site — then catches the same picture under two names, exactly as it does for a dragged-in batch.
  • A link lasts about a month. The run reads the link’s own expiry and says so if it has passed — make a new one in Photos and paste again.
  • Videos in a link are skipped and named in the run’s log; Film has its own intake.
  • Two photographs with the same filename in one link (Photos allows it) both arrive — the second is numbered, IMG_2428-2.JPG — nothing is overwritten.
  • Pasting the same link twice is harmless: originals already in the album are kept, not fetched again.
  • A country the site does not have yet has to be declared on the desktop page (region and display name), as for any first batch; the phone refuses it in a sentence rather than starting a run that would fail.
  • The iPhone Shortcut does not take links: it has nowhere to paste one, and the photographs it shares are already on the phone.
Why not just download them? You asked for exactly this on 13 September 2026: iCloud for Windows is installed on a different machine, so the photographs are not on the laptop or available when travelling, and the link’s own Download button is too many steps per batch. Before anything was built, a probe on a GitHub runner proved the originals were reachable behind a link — the story is under the feasibility probe in the pipeline manual.

Add banknote scans — the Currency tab

Renamed from “Notes” and the naming is now optional (25 August 2026): on the phone, the Currency screen takes plain photographs with no filename at all — Claude identifies each note in the pipeline and files it (see the phone page). The naming below is the desktop path, and still the only way to say a name explicitly or upload PSDs.

High-detail note images come in through the Notes tab on the upload page (beside Photos and Film). PSD source scans, JPEG, PNG, TIFF and iPhone HEIC all work — front and back are separate files.

  1. Name each file for the note it shows: <country>-<denomination>-f for a front, -b for a back, with a variant between denomination and side when there is one. india-10-brown-f.psd, australia-20-b.jpg, newzealand-5-f.heic. The country may be several words joined by hyphens (cayman-islands-1-f.jpg) — what separates it from the denomination is that the denomination is the first part beginning with a digit. Existing countries keep the slug the site already uses (newzealand, srilanka, hongkong) — or the country's name, which is often easier to remember: turkiye-10-f.jpg and turkey-10-f.jpg both land on Türkiye, and czech-republic-20-f.jpg works as well as czech-20-f.jpg. Accents and spacing are ignored, so the name can be written however is convenient. The plan shows which country each file resolved to before anything uploads.
  2. Drop the files. Before anything uploads, the page lists what each name maps to — "india 10-brown, front (replaces the current image)" or "(new note — record is created)" — and one wrong name stops the whole batch with the reason, so a typo costs a rename, never a mis-filed scan.
  3. Any country can go in the library, whether or not the site has a country page for it. The plan tells you which of three things each file is:
    • “replaces the current image” — a note already in the library.
    • “first banknote for Canada” (green) — the site already has that country page; it simply has never had notes. Nothing to do: its notes link straight to the page it already has.
    • “country is new to the whole site” (amber) — nothing here has heard of it. The plan then asks you for two things it cannot read off a filename: the country’s name as it should be printed (pre-filled from the file name, correct it if need be) and its region. Those two make it a country properly — its own country page, and counted in every “57 countries” the site quotes, on the home page and elsewhere. Its page says the photographs and journal have not been added yet, until they are. The bar will not upload until every new country is answered, which is also your spelling check: filling in a region for “Turkiyee” is the moment you notice. Fix the file name and drop again instead.
  4. Read that "replaces" / "new note" line — it is the whole game when re-shooting. The filename is the note's identity. Re-shooting a note the site already has, but naming the file with extra detail (brazil-1-a071-f.jpg for the note the site calls brazil-1), files it as a new note beside the old one, and the collection lists the same banknote twice. To replace a note, name the file with its existing id exactly; add a variant only for a note the site does not have yet. The run also warns when it creates a note whose denomination already exists un-re-shot — tell Claude in a session and the superseded record is removed.
  5. Nothing uploads until you press the bar. Once the plan is on screen, a bar pinned to the bottom states exactly what is about to happen — “Upload 12 note scans → 3 countries” — and waits. Read the plan first: it is the only moment a mistyped country can be caught before it becomes a record. ✕ dismisses without uploading; dropping a fresh batch replaces the offer.
  6. Process & publish → resizes each scan into the three sizes the site uses (3000px for the lightbox, a sharp display copy, a grid thumbnail), updates the note's record, and the pages go hi-detail a few minutes later. A note the site has never had is created automatically from the filename.
  • On the note's page, a hi-detail face says "click to enlarge" — the click opens the full 3000px scan in a lightbox (Escape or a click closes it). A note not yet re-scanned still shows its old 100 px picture and offers no zoom — that scan is only retired once a better one has taken its place, side by side, so nothing is ever left without a photograph.
  • Re-scanning a note just works: drop a better file under the same name and it replaces the old one everywhere a few minutes later.
  • A small source still helps, but earns no lightbox. If a file is under 1200 px wide the note still gets the better image — but no "click to enlarge", because there would be nothing behind the click. The run says so and gives each file's size. For reference, a banknote scanned at 300 dpi comes out around 1800 px wide; a few hundred pixels means the file was a web-sized copy, not the scan.
  • Phone photos — shoot on a dark background, fill the frame, one side per shot. The processor finds the note, crops the background away, and straightens a hand-held tilt (up to 8°) by itself; HEIC straight off the phone is fine. It works with true black or any dark cloth, and a deep-inked note is safe — detection reads colour, not brightness. Two things it will refuse, publishing the frame as shot and saying so in the log: two notes in one photograph (shoot them separately), and a note held in frame by hand rather than laid flat. It also leaves a note alone if it fills less than a tenth of the frame — move closer, or crop roughly before uploading.
  • Re-shooting the whole collection? Every crop and every refusal is printed per file in the run log, with measurements, so a batch can be checked at a glance rather than note by note. If one comes out wrong, re-shoot just that side and drop it under the same name — it replaces the old one everywhere within minutes.
  • Keep your PSD originals. After a successful publish the uploaded source is removed from storage — the site keeps the three derived sizes, and your archive is the master. A PSD over ~100 MB won't upload through the page: export a TIFF/JPEG, or use rclone to currency-in/.
  • The write-up drafts itself. Once the scans publish, the same run has Claude read both faces and draft the note page’s The artwork, In circulation and Details sections. The draft waits for you at Banknote pages — see “Editing a note’s page” just below. It is on the note page straight away; that page is where you change it.

When a scan is held: name it yourself (13 September 2026)

After a batch, the run’s report lists every photograph it could not place and why — not sure enough, the reader timed out, or two photographs of the same face arrived together and only the first could take the name. Those wait in the bucket; nothing is lost, and nothing happens to them on its own.

You usually know exactly what each one is. To tell the site, run the pipeline in currency mode and put this in files:

{"name": {"1789320813201-59.jpeg": "france-10-richelieu-f.jpg"}}

One line per photograph: the file as the report named it, then what it is — country-denomination-f.jpg for a front, -b.jpg for a back, adding the series after the denomination when the country has more than one note of that value (france-10-richelieu-f.jpg). Your answer is taken as final; the reader is still used to cut the note out of the photograph and stand it upright. A name typed wrongly is refused before anything is written, and a name already in use is refused rather than written over.

Editing a note’s page

The Banknote pages page lists every note in the library with the picture it shows — the way Journal photos lists every letter. Narrow it by country, search it by denomination or currency, or use the four state chips: All, Written by Claude, not yet read, No write-up yet, and Still on the old picture. Every row says which of those it is, so nothing is hidden behind a queue.

The write-ups are already live — they go onto the note page as soon as they are written, because a described note beats an undescribed one and waiting for approval left every page showing filler. This is the editor, not a gate.

The backlog is gone (25 August 2026). You asked for the 214 write-ups sitting in Written by Claude, not yet read to be marked approved, and they were. Nothing on the site changed — those write-ups were already published; what went was the queue, which is now empty. Each of those notes still says “written by Claude 2026-08-19, cleared unread” on its own card when you open it, so you can always tell whose words they are; reading one and saving it makes it yours in the usual way. New notes scanned from here on still arrive in the not yet read chip, so the queue works exactly as before — it just starts from empty.

  1. Pick a note and it opens: its faces beside four boxes — artwork front, artwork back, in-circulation, and the Details rows as Label: value lines — with a link to the live page beside the title.
  2. Read it against the scans. Claude reads what is printed on the note first and only then adds what it knows, and is told to leave out anything it is not sure of rather than guess — but it is your collection, and you are the editor.
  3. Edit anything, in place. What is in the boxes when you press Save this copy is exactly what the page shows — your text replaces Claude’s, and the row goes over to Your copy.
  4. Write it again asks Claude for a fresh attempt at that one note. Crop the scan again is for a note that published with black still around it — it re-crops the 3000 px copy in the bucket, so you do not need the original file (it is deleted after publishing). If the cropper finds an edge it publishes a new version and the pictures change in a few minutes; if it does not, the run says so and nothing is touched. Remove the write-up takes the words off entirely, leaving only what the record itself can say.
  5. Back to the list returns you to the collection, with the row you just changed already showing its new state.

Under the list, a button offers to write up every note in the list in front of you that has none — so filtering to one country and pressing it drafts that country. A note still on its 100 px picture can be written by hand but not drafted: nobody can read a note off an image that size. Re-scan one through the Notes tab and it becomes draftable. A Collected row never comes from a draft: the site derives where and when from your own galleries and letters.

If the page says drafting is not configured, the two GitHub settings it needs are in the pipeline page’s credentials table (ANTHROPIC_API_KEY secret, ANTHROPIC_MODEL variable).

The banknote page writes itself, and your write-up overrides it (2026-08-18): every note's detail page now renders the approved design's three sections automatically — The artwork, In circulation, and the Details facts table — created from what the site already knows: the issuing bank, the currency and its symbol, the spelled-out denomination, and the journeys your galleries and letters prove (a note whose printing postdates the last journey to that country says only that it is in the collection, never a journey it cannot have come from). The artwork section is not among them — artwork has to be looked at, so it appears only where a write-up exists, rather than as a sentence describing pictures nothing has seen. To replace any of this with a real write-up, edit the note's record in src/data/currency.json (on GitHub, or ask a session) and add any of: series, years, mm, art.front, art.back, circulation, and facts (label→value pairs — a label matching an automatic row, like Issuer or Collected, replaces it in place; a new one, like Watermark, adds a row). The India ₹100 is the fully written working example; the India ₹1 shows a single-fact override (its issuer is the Government of India, not the Reserve Bank).

How a letter is laid out (13 September 2026)

Two things you reported on the Edinburgh letter, both fixed for every entry and for every entry written from now on:

  • The big first letter belongs to the first sentence. It was landing on the second paragraph, because a letter written in the editor can save its opening sentences as loose text with no paragraph around them — and the site’s drop cap is a rule about the first paragraph. The opening is now made a paragraph in two places: when you save (so what is stored is right) and again when the site is built (so every letter written before today is right on the next deploy). You do not have to do anything to an existing letter.
  • The passport stamp no longer cuts the country name. It used to stop at twelve characters — “UNITED KINGD”. The name is never cut now; its size is worked out from its length so the whole of it fits inside the stamp’s border. Short names look exactly as they did.

Editing a journal entry

The Journal editor opens any of the letters on the page itself — the prose you edit is in the site's own typography, so what you see is what publishes. Pick the entry, then:

  • Fix the words, the title, or the date directly. The word count the site quotes recomputes on save.
  • Insert a photograph where the cursor sits — the picker offers every high-resolution gallery, not just the entry's country, so a letter from Burundi can carry the photograph taken across the border. Type its caption in the small-caps line beneath — and if you have nothing to say, leave it alone: the grey “Caption — type it here” is a prompt drawn on the empty line, not words. It is never saved and never published (13 September 2026; it used to be real text, so a photograph you left uncaptioned carried those words on the live page). A letter that still stores the old prompt loses it on the next build, and for good on the next save.
  • Drop the pull-quote anywhere: press Pull-quote with the cursor where it belongs and type into the block, or select a sentence first to lift it into one. It renders in place exactly as the published page shows it.
  • Move or remove what is already there. Hover a photograph or a pull-quote already in the letter and a small strip appears on it: and move that block one step earlier or later in the letter, and ✕ Remove takes it out. Those handles are the editor’s own — they are never part of the letter, and never saved.
  • The old letters’ photographs count too. An image that came over with the migration sits inline in a paragraph rather than in its own block, usually wrapped in a link back to the old site. It carries a ✕ Remove photo control of its own — always faintly visible rather than on hover, since there is no block to hover — and removing it takes the link with it. It has no ↑/↓: there is no block to move, only a spot in a sentence.
  • Which country page the letter appears on is the droplist beside the date. Changing it moves the letter’s panel to that country’s page on the next build.
  • Save draft keeps the letter without publishing it. Nothing is sent, nothing runs, and nothing reaches the site — the draft goes into Unpublished drafts at the top of the page, where it waits with an Edit button for the next time you open the editor. A draft may be half a letter: no title, no date, no country needed. Publishing it removes it from the list, so you never end up with an older copy of a letter you have already put up. Drafts live in the browser you wrote them in, on that device — deliberately, because the two durable places on this stack are both public: the image bucket answers on a pub-…r2.dev address, and anything the build produces goes onto the staging site. An unpublished letter should be neither. If you want drafts to follow you between devices, tell Claude — it needs a private second bucket, which is a five-minute change.
  • Start a new letter — the link under the entry droplist. It opens a blank page with the same tools. The address is made from the title (“A Night in Mandalay” → /journal/a-night-in-mandalay/), so a title already in use is refused before anything is sent; give it a different one. Title and date are required, and the excerpt the index shows is taken from the opening of the prose rather than typed.

The quickest way in is from the letter itself. Reading any letter on the site while this browser holds the passphrase, an ✎ Edit this letter control sits above the prose and opens the editor on that entry — no hunting through a droplist of 161. A visitor never sees it; it is the same passphrase-in-this-browser test the photo view uses for Rotate and Remove.

The confirmation appears in the toolbar beside Save, not under the prose — on a long letter the foot of the page is two screens away from the button that was pressed. Beside it, when you arrived by pressing ✎ Edit this letter on the letter itself, is ‹ Back to the letter (13 September 2026) — the way back to the page you were reading, there before and after the save. It appears only when the visit began at that letter and that letter is still the one open: pick a different one from the droplist and it goes, because there is no longer anywhere to go back to. Give staging its couple of minutes before expecting the change to show on the page you return to.

Save entry (or Publish new letter) sends it down the same path as every other tool — the pipeline sanitizes the markup to the journal's own vocabulary (a photograph that no longer exists is refused by name), commits, and staging updates in a couple of minutes. Photographs are stored by bucket key, never by URL, so the same entry is right on staging today and on www.traveller.org after cutover.

The photograph beside a journal entry

The picture belongs to the letter first (your rule, 13 September 2026). In order: the photograph you pinned on Journal photos; failing that, the letter’s own first picture — one you placed in the Journal editor, or one that came with the letter from the old site; failing that, a photograph of that country and that year; failing that, the country’s locator map (and for the two entries with no country, nothing). This is what the journal index and the country pages both show.

Two things changed that day. Six letters that carry a picture of their own were showing a stranger’s photograph from the same country — they now show their own. And the automatic choice is the same year only: it used to fall back to any gallery of that country, so a 1992 letter could be illustrated by a 2016 photograph. Where there is no photograph of that year the map is shown instead, which is the honest answer. Nothing needs doing for any of it — it follows your imports by itself, and an entry gains a real photograph the moment its country and year do.

  1. To pin a particular photograph, open Journal photos — its own page in the admin row above — and connect.
  2. Pick the country, or type into the search box to find an entry by title across every country. Each entry lists with the picture it is currently showing and where it came from: chosen, the letter’s own picture, automatic · same country, same year, or locator map.
  3. Choose… opens that country's high-resolution albums; click any photograph to pin it. Auto hands the entry back to the automatic choice.
  4. Save journal photos — live a few minutes later. Only the entries you touched are sent, so two people working on different countries cannot overwrite each other.

A pick shows everywhere that entry appears as a card — the journal index and the “From the journal” panels on its country page. (Until 2026-08-19 the country pages ignored the picks and showed the locator map or an old GIF instead; they no longer do.)

Only high-resolution albums are offered, deliberately: the legacy 800 px albums are being retired, and an entry pinned to one would lose its picture at the launch prune. If a pinned photograph is later deleted or rotated, the entry quietly falls back to the automatic choice rather than showing a gap.

Curate the home page

The hero carousel

The rotating photographs that open the home page are managed at the top of Cards & strips — no country needs to be selected, the carousel belongs to the whole site. Connect and the current slides appear in order, each with its photograph, caption and photo key.

  1. Reorder — drag a row by its ⋮⋮ grip. The order on screen is the order the home page rotates through, first slide first.
  2. Caption — type in the row's caption box; it shows under the carousel as each slide comes up (“Kerala backwaters, India · 2007” is the shape).
  3. Add+ Add slide from photo library opens the photo picker with every high-resolution gallery on the site; click a photograph and it appends as the last slide, ready to drag into place and caption. Albums read Country year — Album (photographs), so the two Sydneys twenty years apart are told apart at a glance; an album whose name is already its year is not doubled.
  4. Remove — takes a slide out. The carousel cannot be emptied: the home page opens on it, so Save insists on at least one slide (twelve is the most).
  5. “not there” on a slide — that photograph could not be loaded. Almost always the album has been re-uploaded at high resolution since the slide was pinned, which renames every file in it, so the slide points at a filename that no longer exists. Remove the slide and add one from the library. You have to: the processing run checks every slide against the site’s photographs and refuses the whole save if one is unknown, so a dead slide you never touched would block a change you had just made. Save now says so on the page rather than letting you find out from a red run.
  6. Save changes — live a few minutes later. The list saves whole, so it is best for one person to curate it at a time.

If every slide ends up removed or unloadable, the home page does not go blank: it opens on the largest high-resolution galleries’ first frames until you pin slides again.

Letters home — the journal panel

The journal entries the home page shows under Letters home are chosen on the same page, in the section under the carousel. Until 21 August 2026 there was no control for this anywhere — the list lived in a data file, and the only way to change it was to ask in a session. It is now yours.

  1. What you see — one row per featured entry, in the order the home page reads them, each showing the entry’s title with its place and year underneath. Not id numbers: the file stores numbers, but there is no reason for you to.
  2. Reorder — drag a row by its ⋮⋮ grip. Row one is the top-left panel on the home page, and it fills left to right.
  3. Change — swaps that one row for a different entry. + Add an entry appends to the end instead.
  4. Finding an entry — the picker lists every entry on the site, with a search box that matches on title, country or year. Type “Burma” or “2001” and the list narrows as you type. An entry already in the panel is shown greyed and cannot be picked twice.
  5. Remove — drops a row.
  6. Whole rows only. The panel lays out in rows of three, so it takes three, six or nine — and the line under the rows tells you where you are (“two rows of 3 on the home page”, or “2 full rows and a row of 1. Add 2 more or remove 1”). Save is refused while a row is short, on the page, rather than by a red run three minutes later.
  7. Save changes — the same button as the carousel and the cards; live a few minutes later. Like the carousel, the panel saves whole, because the order is the point.

If a row says “Entry 412 — no longer on the site”, that entry has been deleted since it was featured. Remove the row. The save is refused while it is there, for the carousel’s reason: the run checks every entry and refuses the whole save if one is unknown. Before this section existed the home page simply showed one panel fewer, which looked like a design choice rather than a missing entry.

The rest of the page

  • The figures under the hero — countries, regions, galleries, photographs and the year span — are not curated and cannot be edited: every one is counted from the gallery data on each build, the same block the Countries and Photographs pages carry. Import an album and all five move by themselves; retire a deprecated one and they move back. If a number there ever looks wrong, the data is wrong, not the page.
  • Country cards — each country's card photo is one flagged photo; counts and years fill themselves in.
  • Letters home — the featured journal entries, each with its city/year stamp inked in its region's color. Chosen on Cards & strips — see the journal panel above.

The DMARC emails (10 September 2026)

Every day, Google, Microsoft and others send a report to dmarc@traveller.org listing everything that sent mail claiming to be this domain. You do not have to read them. The traveller-dmarc Worker reads each one and writes to you only if something needs acting on — a clean report produces no email at all, and clean is what they have been.

If one does arrive, it names what happened in plain words and what it means: a service of yours whose settings need fixing, or somebody using the domain’s name. It also arrives if a report could not be read, because silence has to mean “checked” rather than “broken”. Forward it here and it can be dealt with.

Both switches were thrown on 10 September 2026 — the routing rule points at the Worker and its key is set, so this is running now. The two steps are kept below because they are what to redo if the rule is ever lost, and because the second explains where the reports went.

  1. Re-point the rule that already exists. dmarc@traveller.org is not a new address — you created it at cutover (step 15) forwarding to brarob@gmail.com, which is how these reports have been reaching you. So this is an edit, not an add: open Email Routing → routing rules (that link opens the right page inside the traveller.org zone — Email Routing lives per-domain, not at the account level, which is what makes it hard to find by clicking), find the dmarc row, and change its action from sending to your Gmail to Send to a Worker → traveller-dmarc. It is the same change theboys@ already uses.
  2. Give the Worker its key so it can write to you: Workers & Pages → traveller-dmarc → Settings → Variables → add RESEND_API_KEY (encrypted), from a fresh key at resend.com → API Keys.

A report forwarded to you with no note explaining it means the Worker read it and could not write to you — almost always the Resend key. The reason is in the Worker’s own log (traveller-dmarc), and the report itself is safe in your inbox meanwhile.

You will stop seeing the daily reports, which is the point — a routing rule has one action, so the Worker receives them instead of your inbox. Nothing is lost when it matters: if the Worker finds something wrong it forwards you the original report along with its explanation, so the evidence arrives with the alarm. The pipeline page has the detail of what it does and does not alert on.

Messages from the contact form

  • Nothing to check. A message arrives as ordinary email in your inbox, from contact@traveller.org, subject “traveller.org — message from <name>”. There is no queue, no dashboard, and nothing to log in to.
  • Just hit Reply. The sender's address is set as Reply-To, so your answer goes to them, not to the form. Their address is repeated at the bottom of the message too, in case your mail app ever hides Reply-To.
  • Robots are handled. Every message passes a Cloudflare Turnstile check before it is sent — usually invisible to the visitor, no traffic lights to click. A second, hidden field catches the simpler scripts: anything that fills it is dropped silently and told it succeeded, so the bot goes away instead of retrying.
  • If a message could not be sent, the visitor is told so on the page and keeps what they typed, so it is never lost silently. Nothing reaches you in that case — so a quiet week is a quiet week, not a broken form. To prove it end to end, send yourself one from the live page.
  • It goes live at cutover, when the two keys are set (step 18 of Launch & cutover). Until then the form on the test site is deliberately display-only and says so.

Fix flat, washed-out scans

  • Some older black-and-white scans publish grey and lifeless — never quite black, never quite white, with the paper's colour over everything. That is how they were scanned; the import deliberately does not touch tone.
  • Ask for a tone pass — "re-develop the Bagan black-and-whites". The re-developed copies are published as a separate album so you can open both and compare. The originals are never overwritten, and pointing the pass at its own album is refused.
  • Three strengths: soft, normal, strong. The email lists, per photograph, how much of black-to-white it now uses and how much colour cast was removed.
  • When you have decided, say which album to keep — the other is deleted like any other album.
  • What it cannot do: it corrects tone, not detail. Scratches, dust and softness in the original scan stay exactly as they are.
  • Bagan has already been through this, and you kept the originals. The 25 black-and-white frames in burma/2001/bagan were re-developed in August 2026, compared side by side, and the re-developed album was deleted. Nothing needs doing; it is noted here so the offer is not made to you a second time.

How visitors move between photos

  • On a desktop: the transparent ‹ › arrows on the left and right edges of the photograph, or the keyboard's arrow keys. Esc returns to the gallery grid.
  • On a phone: Previous / Next buttons under the photograph (the edge arrows are switched off there — they would cover a third of the picture), and swiping left or right on the photograph itself. Both were added in August 2026 after you found a phone had no way to change photo at all except the thumbnail strip.
  • Navigation wraps: Previous from the first photograph shows the last, so the buttons are never dead ends.
  • The small ‹ › beside the thumbnail strip do something different on every device: they slide the strip itself, without changing the photograph.

App guides at /guides (5 September 2026)

Several apps will hang off this domain, and each needs an end-user guide — steps to follow while doing something, a reference to look things up in. They all live on one shelf: www.traveller.org/guides/, one card per app, each card listing that app’s pages in order. This site’s own guide is the first on the shelf (getting around, signing in as a friend, sending photographs from a phone); the other apps are listed and join the shelf the moment they have a page.

The shelf is open — no login, for now. You chose on 5 September 2026 to put it live without a door: the pages are unlinked from the public site, marked noindex, kept out of the sitemap and disallowed in robots.txt, but anyone who has the address can read them. So write every guide as if it were public — no passwords, no addresses that should stay private. The door that is planned is a second Cloudflare Access application on www.traveller.org/guides* with its own allow-list (you first, then an app’s users as each app joins), kept separate from the admin’s so admitting a reader never admits them to the admin; it is an open item on the runbook for when you want it. A guide page carries no admin nav, no login widget — and, since 2026-09-06, no site nav either: the shelf is its own standalone area, free not to match the site’s design (your call). Its wayfinding is the back link and each app’s own sidebar; the App guides entry under Manual in the admin nav is just a link across.

Adding an app’s guide

  1. In that app’s own repository, write the guide as markdown under docs/guides/ — one file per page, images beside them in any sub-folder (docs/guides/img/…, referenced with a relative path). Each file starts with a short header:
    ---
    title: Sending photographs from your phone
    order: 3
    summary: One line for the app's contents page.
    ---
    Only title matters; without it the sync writes one from the first heading (or the file name). order sorts the pages; summary is the line under each title on the app’s landing.
  2. List the app once in src/data/guides.json in this repository: its slug (becomes the address, /guides/<slug>/), display name, repository and the folder above. The eight repositories being tracked are already listed, so for those this step is done.
  3. Let the sync copy it. The Sync app guides workflow runs every night, and can be run by hand from its Actions page. To have a guide land within a minute of being pushed, the app’s own repository can send a ping — three lines in one of its workflows —
    - run: gh api repos/brarob100/traveller.org/dispatches -f event_type=guides-updated
      env:
        GH_TOKEN: ${{ secrets.CENTRAL_DOCS_DISPATCH }}
    where the secret is a token allowed to dispatch on this repository — its own row (CENTRAL_DOCS_DISPATCH) in the credentials table on the pipeline page says how to mint one and where it goes.
  4. It goes live on its own. Since 2026-09-07 the sync publishes what it brought: the copy arrives as a commit, the test site rebuilds, and the live shelf follows within a few minutes — no Publish to press. Unless something else is waiting: if the trunk holds anything beyond the guides (a site change, another session's work), the sync leaves it all on staging and says so, because publishing moves everything at once. Then it is the ordinary Publish page as before. A guide is never fetched at build time and never read live from another repository — the site builds from the copy it holds, so a token that fails one night cannot ship a shelf with an app missing.

The same steps, written for the moment they have been forgotten, are the shelf’s own first guide — Centralized Documentation → Adding a new app to the shelf — which ends in a prompt to paste into a Claude Code session on the new app’s repository, so none of it needs a terminal.

The sync needs one credential, CENTRAL_DOCS_GIT_TOKEN — a fine-grained GitHub token that may read the app repositories and nothing else. Until it exists the nightly run ends green having done nothing, and says so; the credentials table on the pipeline page says where to create it. This site’s own guide needs no token: it is written straight into src/content/guides/traveller/ in this repository, and editing it is editing those markdown files.

Starting a session to write these guides? The prompt that starts one lives in the repository at docs/guides-workstream-prompt.md — open a new chat on the traveller.org repository and paste it. It carries everything a fresh session needs (the shelf, the convention, the eight apps, the standing rules), so the guides work does not have to share a session with the photographs and the journal.

Deleting a page upstream deletes it here on the next sync; deleting an app’s whole docs/guides folder takes it off the shelf. Nothing on the shelf is indexed: every page is noindex, none is in the sitemap, and the live robots.txt disallows /guides/ beside /admin/.

Change the design

  • All look-and-feel lives in src/styles/global.css (tokens at the top: paper, ink, accent, the five region colors) and the layouts in src/layouts/ and src/pages/.
  • The approved reference for every page type is design/site-daylight.html — change the reference first, then the site, so they never drift.
  • Content files never need touching for a design change, and vice versa.
Rule of thumb: if an update feels like it needs anything beyond editing a record or uploading files to the bucket or Drive folder, it's a process change — and any process change must update this manual in the same push.