‹ Back to the site

Uploading from your iPhone

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

“Unlocking…” now shows under the passphrase (18 October 2026)

While the phone uploader checks your passphrase, a teal panel reading UNLOCKING… appears directly under the passphrase field, with a spinning ring, a light running along its bottom edge and a gentle pulse. Under the word it says what is being checked: Checking the passphrase when you typed it and tapped Unlock, or With the passphrase remembered on this phone (Signed in with Cloudflare on the /admin/api/m address) when the page is unlocking by itself. The Unlock button greys out while it waits.

It used to be a dark grey band across the very top of the screen, where an iPhone’s clock and notch sit on top of it. When the check succeeds the panel goes and the blue UNLOCKED bar appears at the top of the next screen, as before. If the passphrase is refused, the panel goes and the reason shows under the field. On a phone set to Reduce Motion the panel stays still; the teal and the words still say it is working.

The share sheet cannot make an album — make them first (23 August 2026)

The list the shortcut shows is a list of albums that already exist. It has no “new album” row, on purpose: the branch that row needed inside the shortcut was where every failure this recipe has had actually lived.

So for a trip’s worth of new albums, open the upload page in Safari on the phone and press + Create albums for the phone…. Country, year — the trip’s year — and a name, add each to the list, then create them all in one go. They are in the share sheet’s list within seconds, empty and marked pending~, and you can share straight to them. Full walkthrough: Making albums for the phone.

Each album in that panel can be marked Unlisted as you add it, and the choice sticks to the album: the batch you share to it from the phone days later imports unlisted, with nothing to remember afterwards (24 August 2026). Since 22 September 2026 an unlisted album also carries Publish to www.traveller.org — off, it lives on albums.traveller.org alone — and every album picker (this page’s, the phone page’s, Album cleanup’s) shows one site’s albums at a time: www.traveller.org | albums.traveller.org, a switch at the head of the list. The phone page’s new-album screen presets both switches from that choice.

Film, on the phone (25 August 2026)

Choose the film’s album (25 October 2026). Under Year, an Album list puts the film on that album’s page as well as the country’s. If the country has only one album that year it is already chosen. See Films in an album.

Long films upload now (20 October 2026). A clip over 100 MB, which is about a minute of 4K, used to stop at The film did not upload. It now goes up in parts by itself. See Files over 100 MB.

The Film button at the top of the phone page now opens a film screen of its own. (Until today it led straight back to Photos — the link kept the page it was on. It is a button now, not a link, so there is nothing to go wrong.)

The same shape as photographs: country — a searchable list, like the album picker — year, the clip, then Title, Where and a Description. One dark button, Upload Film, does the whole job: it uploads the clip and its story, then starts the conversion by itself. There is no second button to forget.

  • The progress is real. A film is one long upload, and the ring counts the actual percentage sent — a 400 MB clip with no progress is indistinguishable from a page that has died.
  • One film per upload, as on the desktop. The clip becomes a web-playable MP4 a few minutes after it lands; your original is then removed from storage — keep your own copy (no zip record since 9 October 2026).
  • Afterwards the form clears itself — title, description, where, and the clip — keeping the country and year, since the next film is almost always the same trip. Upload Another Film goes straight back to it.
  • A file that is not a video is refused on the spot, before anything uploads.
  • A country the site has never had still belongs to the classic page: a film cannot invent one, any more than a batch of photographs can.

Banknotes are still the classic page — the Notes button opens it with the right form showing.

After an upload, the next upload is the button (25 August 2026)

On the receipt at the end of a batch — photographs, film or currency alike — the dark button is now “Upload More” (or “Upload Another Film”, “Upload More Notes”), and View is the quiet one beneath it. The site is there whenever; the phone is in your hand now.

One exception, on purpose: if publishing did not start — the upload landed but the pipeline could not be told — then Retry takes the dark slot instead, because that is genuinely the next thing. It goes back to Upload More the moment the retry works.

The rest of the admin, one tap away (27 August 2026)

At the foot of the phone’s home screen — below Upload settings and below the Upload Photos button, which keeps the position of honour because it is what the screen is for — there is now a Publish to the live site card. Tap it and the Publish page opens — the same page as on a desktop, with the list of what is waiting and the button that sends it. Beneath the card sit the rest: Album cleanup, Cards & strips, Banknote pages, All tools and this Manual.

Two things about it are deliberate rather than incidental.

  • They open in a new tab. The uploader screen may already be holding a chosen album and a batch the phone has spent a minute preparing; navigating away would throw both out. Close the tab and the uploader is exactly where you left it.
  • They go to the test site’s admin, not the live one. That is the master set — the same storage, the same pipeline, the newest controls — and it is where the manual has told you to work since 22 August. The live site’s copies sit behind Cloudflare Access, which answers a phone with an email-and-code login before it will show you anything.

Publishing itself is unaffected by which admin you press the button on: the Publish page dispatches the same workflow either way, and what goes out is what is on the trunk.

Currency, on the phone — no naming (25 August 2026)

The Currency button (the tab formerly called Notes, renamed on both pages) opens a screen of its own on the phone, and it drops the one rule a phone cannot follow: the filename. The camera roll says IMG_4979; nothing on a phone can type belgium-100-f.

So: photograph each face separately — one note per frame, on a dark ground, filling most of the frame — select them all, and press Upload N Photographs. They upload at full size (nothing is shrunk; the engraving is what gets read), and then the pipeline does the whole job in post: Claude reads each photograph, names the note (country, denomination, front or back — matched against the countries and notes the site already holds), crops it and stands it upright — Claude reports where the note sits in the frame and which way up it is, the pipeline cuts and turns by that, and the measuring cropper fine-trims the result (25 August 2026: measurement alone shipped the euro 10 back sideways and uncropped, because it rightly refuses a frame it cannot be sure of and a rectangle carries no reading direction) — builds the three display sizes, and files it on the site, write-up and all.

  • Nothing uncertain is ever guessed onto the site. A photograph Claude cannot identify with certainty — blurred, half-cropped, a currency it cannot place — waits in storage instead, and the run’s log names each one and why. Re-shoot it, or name it by hand on the classic page.
  • A wrong identification is corrected where write-ups are: Banknote pages in the admin edits, re-crops or deletes any note.
  • A country the site has never held still needs the classic page — a region and display name are the two things no photograph can supply.
  • Hand-named scans work exactly as before, from the classic page — that is still the way to say a name explicitly (and the only way to upload PSDs).

If the phone page ever comes up blank (25 August 2026)

It should not any more, and if something does go wrong it will now say so on the page instead of showing nothing. The passphrase screen is part of the page itself rather than something the page draws after loading, so even a phone that refuses to run the page’s script — a content blocker set on this address will do it — shows the screen and a line explaining why the form on it will not work.

One real cause is worth knowing: Settings → Safari → Advanced → Block All Cookies. With that on, Safari raises an error the moment any page touches its storage, which used to stop this page before it drew anything. It no longer does — the page works with storage blocked; it simply cannot remember the passphrase between visits, and it tells you that on the unlock screen. If a blank page ever does appear, the classic page at traveller-upload.brarob.workers.dev/?stay=1 is always there.

Three small things put right (25 August 2026)

  • Your iPhone now offers to save the passphrase. The unlock screen is a real login form, so the first successful unlock brings up iOS’s own Save Password prompt and the keychain autofills it from then on — on this phone, a new phone, or after Safari’s storage is cleared. The page’s own Remember on this phone switch still works exactly as before; the keychain is the layer that survives everything the switch cannot. And if the page ever falls back to the unlock screen because the Worker was briefly unreachable, the remembered passphrase is already in the box — one tap retries, nothing needs retyping.
  • View Films no longer lands on a 404. A country’s films page only exists once it has published films, and the button used to link it regardless — so the first film for a country led nowhere. It now links the films page when that page exists and the country’s own page otherwise, where the Films section appears once converting and the site rebuild finish. View Album got the same care: an album uploaded but never imported has no page yet, so its button aims at the country page until the first import lands.
  • “hashes” is not a country. The duplicate-detection bookkeeping lives in storage under hashes/ and near-dupes/, and the album pickers briefly listed those folders as if they were albums. They are housekeeping, now invisible to every picker — here, on the classic page, and in the Shortcut’s list.

A photograph you have already uploaded (25 August 2026)

Press Upload and, if any of the chosen photographs share a name with one already in that album, the phone asks first — “2 already in Madrid” — names them, and offers three answers (26 August 2026). Nothing is uploaded while the question is on screen.

  • Upload New Photos — the dark button, and usually the one you want. It sends only the photographs that are not already there, so the duplicates never cross the network. The sentence above it says how many that is and roughly how many megabytes skipping saves, which on a phone away from wi-fi is the whole point.
  • Upload all 43, replacing 2 — what the button used to do on its own. Replacing is a real thing to want: a better edit of the same frame keeps its name and takes the place of the old one.
  • Cancel — nothing is sent and the selection stays as it was.

If every photograph you picked is already in the album, skipping would upload nothing at all, so that button is not offered — the sheet says there is nothing else to send and leaves you with Replace or Cancel. The classic page offers the same three answers.

Two more things happen without being asked. A batch can no longer overwrite itself: iOS hands back repeated filenames for edited photographs, and two files under one name used to mean the second quietly replaced the first — they are now filed as image.jpg, image-2.jpg and so on. Since 13 September 2026 the same rule holds against the album, in storage: a same-name file that is a different photograph is filed as IMG_0001-2.JPG rather than over the one already there, unless you answered Replace on this sheet — and the share-sheet Shortcut, which cannot ask, can no longer overwrite anything at all. That is what a shared uploader needs when several cameras all count from IMG_0001. And the import still does what it always did: it compares the pictures, not the names, and removes a photograph that duplicates another in the same album whatever it is called. The finished-import email lists any it removed.

And now across albums as well (25 August 2026). Every photograph on the site has a fingerprint of its picture on file, so when someone uploads one that is already published somewhere else — a different album, a different country, a different trip altogether — the import email says so and names where: “IMG_4471.JPG is already published as mexico/2019/vallarta/IMG_0031.JPG”. Nothing is removed. The same picture in two albums can be exactly what you meant, and only you can tell that from a mistake; if it is a mistake, remove the copy you do not want on its album’s Album cleanup page.

Two things the upload page now tells you (24 August 2026)

  • “Preparing photographs…” — after you tick your selection in the photo library, iOS spends a while handing the files over: on a large batch of HEICs it is tens of seconds during which the page has nothing to show and the phone looks stuck. It now says so, with a spinner, from the moment you press the tick until the count of chosen photographs appears. Nothing has gone wrong; it is the phone reading the pictures.
  • The film form empties itself after a film is handed over — title, description, location and the clip — so the next one can be started straight away without clearing four boxes by hand. The country / year is kept on purpose, since the next film is almost always from the same trip.

The public site in the hand (10 November 2026)

The fourth batch of the review: what a visitor on an iPhone or iPad meets. Measured in a test browser at 393×852, before and after.

WhatBeforeNow
Pictures asked for when Photographs opens927about 80; the rest as you scroll
Large photographs fetched by the home page51, then one ahead
Copies of the font downloaded41
Height of the pinned region chips161px, three rows59px, one row that scrolls sideways
Muted grey against the page3.85 : 14.79 : 1 (the floor is 4.5)
Back from a photographleft the albumreturns to the album’s grid
Back from a film or a banknote scanleft the pagecloses it
“Gallery →” tap target17px talldrawn the same, answers over 40px

Also: a swipe turns the home page’s photographs; a sideways phone has a button back to the grid; the next and previous photograph are fetched ahead, and the old one dims while a new one loads; the trail on albums, banknotes and film pages is links; the footer lists every section and Films; a banknote links to its neighbours; a letter’s photographs enlarge when tapped; every strip link says which photograph it opens, and an album page has a main heading (both for VoiceOver).

Not done, and why. A 1200px photograph size (the phone view still fetches the 2048px file): it needs the pipeline to make and store a third size for every photograph, which is a storage decision for you. Moving the owner’s script off the album page and the admin’s styles out of the public stylesheet: both are rewrites of the site’s most-used page and were left for a session that does only that. Nothing here was tried on a physical phone.

Knowing when it is done: the status card (10 November 2026)

The third batch of the review. Every change you make in the admin is a job on GitHub and then a rebuild of the test site, and every page used to end with “reload in a few minutes”. Now a small dark status card follows the job and tells you.

  • What it says, in order. Sent. Waiting for it to start → Queued behind another change (only if something else for that album is running) → Working on it → Saved. Rebuilding the test site → Done. It is on the test site now. Three rotations pressed one after another are one card: Working on it: 1 of 3 finished.
  • On the phone it is a pill at the top of the screen, in the middle, small enough to leave the buttons either side alone. Tap it to see which job it is; tap again to put it away. It opens by itself when it has news.
  • When a reload is needed, it offers one. Pages that read their photographs when the site was built (Album cleanup after a rotation, a move or an import) show Reload to see it on the finished card. Others clear themselves after a few seconds.
  • If it fails, it says so and See what happened opens the job on GitHub. A job cancelled in the queue says Cancelled before it started. Send it again. The failure email still arrives as before.
  • It follows you between admin pages. Start a rotation in Album cleanup, open Cards & strips, and the card is still there. It is kept for the tab you are in, not for ever: close the tab and it is gone, though the job carries on.
  • Where it appears. Every admin page, both uploaders (the phone page /m and the desktop one), and the owner controls on an album page and a country’s films page. The iPhone Shortcut cannot show one; its confirmation email is unchanged.
  • Done means the test site. www changes when you Publish, and the Publish page now watches that too: after you press Publish its line reads Cloudflare is building the live site and changes to Live when www is serving what you sent.
  • If the card says “No word yet” the job was not seen within two minutes (or did not finish within fourteen). It may still be running; the Publish page lists what has arrived.

The admin in the hand (10 November 2026)

The second batch of the same review: nothing here was broken, it was awkward on an iPhone or an iPad. Each item was measured before and after.

  • The Journal editor leaves you room to write. The bar pinned to the top of the phone held the title, the date, the country, five buttons and the save status: 248px of the screen, which with the keyboard up left a strip. Now the title, date and country scroll away with the page and only one row stays pinned — Photo, Quote, Memo, Draft and Publish (or Save) — with the save status under it: 61px. At a desk the bar is as it was.
  • Films: Save follows you. India’s 17 films ran to 4,600px with Save films at the very end. The button now stays pinned at the foot of the screen from your first change, and each film’s card is shorter.
  • Questions are asked in a sheet. On a phone or an iPad, the browser’s grey OK/Cancel box is gone from: publishing, importing an album or all of them, moving an album’s address, deleting a waiting folder, deleting a banknote, discarding a draft, removing a photograph in the photo view, and (on an iPad) moving and removing photographs in Album cleanup. Each is a sheet from the foot of the screen whose button says what it will do — Publish to live site, Import album, Delete the files — with Cancel under it. At a desk the browser’s own box remains. Deleting an album still asks you to type its path.
    The rule, written down (11 November 2026): anything that cannot be undone asks first and names the thing in the question. Three deletions go further and make you type: an album (its path), a film (its title) and a journal letter (its title). Two gaps were closed that day: removing a note’s write-up went ahead with no question at all, and removing a photograph asked “Remove this photo?” without saying which. The write-up now asks Remove the write-up for …?, and the photograph’s question carries its file name.
  • Photographs open faster on a phone (11 November 2026). The photo view used to fetch the full 2048px file for every photograph: nearly three times the pixels of a 1200px one, and more than a phone’s screen shows. It now fetches a 1200px copy, and the next and previous photograph at that size too. Pinch to zoom and the full file is fetched for the photograph you are looking at. A photograph that has no copy yet simply shows the full file, as before. The machinery.
  • Four things the phone could not do, and now can (11 November 2026), all in Album cleanup except the last: captions — tap a photograph in Browse; its caption is under it with Edit caption / Add a caption, and captioned photographs wear a ✎ on the grid (how); old 800px albums — in the list now, marked Old · 800px, opening to their name, year and Delete; photographs held back as near-duplicates — a row on the album’s screen with Bring them back (what that is); and banknote photographs the reader could not name — a Waiting to be named card on Banknote pages (how).
  • The Friends button says which way it will go (11 November 2026). In Album cleanup’s phone bar it read Friends whatever was selected. It now reads Friends-only, and Public again when every photograph you have selected is already friends-only — the same two words the desktop page and the photo view use.
  • The photo view, for a run of photographs. The owner’s sheet (Caption, Rotate, Friends-only, Remove) now stays open as you move from photo to photo; Done closes it. Rotate turns the picture on screen at once — the saved file still follows a minute or two later. And with the sheet closed, what happened is said in a dark message across the foot of the screen, where before it was written inside the closed sheet.
  • Album cleanup.
    • Waiting to be imported is one gold row at the top of the album list (2 albums are waiting to be imported ›) that opens the same card in a sheet. It used to sit above the phone’s own screen as a desktop card.
    • Tap a photograph and it opens on the page, full screen; tap again to close. It used to open in a new tab.
    • Opening an album shows the album’s screen at once, saying Opening…, and Albums returns you to where you were in the list.
    • On an iPad the pinned toolbar is one row (the count, Select all, Clear) until you select something; it was four rows, 258px. Once something is selected the actions appear, with a line saying what To front, Friends-only and 180° do, since a finger has no tooltip.
  • The back swipe steps back one screen instead of leaving the page: from an album to the list in Album cleanup, from a door to the hub on Cards & strips, and from Film, Currency or New Album to Photos on the phone uploader.
  • Cards & strips warns before you leave with picks unsaved, and on an iPad its rows can be reordered by holding the ⋮⋮ grip and dragging. Its pickers reopen on the album you last used.
  • The phone uploader remembers. New Album opens on the country you are working in; the Film screen starts on the country of the album you chose on Photos; the album list refreshes when you come back to the page, so counts and Not imported marks are current.
  • Bigger targets. The site’s main button is 44px tall on a touch screen (it was 32); the admin home’s rows are tappable anywhere, not only on their title; droplists, the Letters/Photos switch and the small Cancel and Done links are all a thumb’s size.
  • Sheets hold still. The page behind a sheet no longer scrolls under it, and pulling a sheet’s handle down puts it away.
  • The admin login can be saved to your passwords on the test site (iOS only offers when the login is a real form; it now is). On www you sign in with Cloudflare and never see it.

Not changed, and why: choosing an album is still a searchable sheet on the phone uploader, a full-page list in Album cleanup and a grouped droplist elsewhere. The droplists were reorganised by country and year on 30 October at your request, and iOS shows those headings natively; replacing them all with one custom sheet is recorded in the review file as a possible later step, not done.

Faults put right on the phone (10 November 2026)

A full review of the admin, the public site and the pipeline on 10 November found things that were quietly failing rather than merely awkward. These are the ones you would have met on the phone; the whole list, with what is still to do, is docs/2026-11-10-review.md.

  • Album cleanup now tells you what happened. “Rotating…”, “Moved”, “Order saved”, every error, and the refusal to remove every photograph in an album were all being written into a box the phone hides. They now appear as a message across the bottom of the screen, just above the action bar. Good news clears itself after a few seconds; a refusal or an error stays until you tap it.
  • Rotations no longer go missing. Each press of Rotate starts its own run, and GitHub keeps only one run waiting per queue: the third press threw the second away, after the page had said “Rotating…” for it. About half of all rotations were lost this way (108 of 212). Each photograph now has its own queue, so you can turn photograph after photograph without waiting. Pressing Rotate twice on the same photograph still makes a half-turn. The same applies to Friends-only.
  • The phone uploader’s Retry does one thing. After a film failed to upload, Retry sent the clip twice and could also publish whichever album was chosen on Photos. After “Converting did not start”, Retry re-sent the whole clip instead of just asking again. For banknotes it re-sent the entire batch, including the photographs that had already landed. Each Retry now repeats only the step that failed.
  • Cancel works on films and banknotes. It used to do nothing: the ring kept turning, the upload finished and the conversion started. It now stops the upload and takes you back to the form. Banknote photographs that had already landed stay in storage and are identified with your next batch.
  • The receipt reads correctly again after a film: a photo upload that followed one said “Upload Another Film” and its button went to the Film screen.
  • Copy, on the Delete-album sheet. The button beside the path was there all along and never drawn, so the path had to be typed by hand. Tap Copy, then paste.
  • No more zooming in. iOS enlarges the whole page when you tap a field whose text is under 16px, and leaves it enlarged. Every field on the phone uploader, the Journal editor’s country list, the banknote editor’s boxes and the public contact form were under that. All are 16px now.
  • The photo view will not remove an album’s last photograph. It tells you to delete the album itself instead (Delete this album, on Album cleanup), which takes the album and the photograph together. Album cleanup always refused this; the photo view did not, and left an empty album on the site.

The admin on an iPhone and an iPad (13 October 2026)

Every admin page was checked at iPhone and iPad sizes, signed in with Cloudflare as you are. What changed:

  • The uploader entries in the admin menu (Photo uploader, Phone uploader) now open the signed-in addresses on www, /admin/api/ and /admin/api/m. Before this they opened the passphrase versions, so on the phone they showed the unlock screen.
  • Edges: the admin home, Cards & strips, the Journal editor and Banknote pages now keep a margin at the screen’s edges like the other pages, instead of running edge to edge.
  • No more zooming in: tapping a search box, a caption or a list no longer zooms the whole page in. iOS does that for any field with text under 16px, and several were 12–13px.
  • Buttons: Cards & strips’ Remove / Change / Add buttons and the Journal editor’s “start a new letter” now look like the rest of the site, not grey browser buttons. Switches, filter chips, the site toggle and the Friends’ door / Sign out buttons are bigger to tap on a touch screen.
  • Journal editor: the controls on a letter’s photographs and quote now stay in view on a touch screen. They used to wait for a mouse to hover over them.
  • On an iPad, the bulk uploader’s destination list is a proper box that fits its card, instead of a thin strip running off the right edge.

Then, on your word (“do 1, 2, 3, 4 and 6”, the same day):

  • The gold band is the account control on the phone. “Connected” is no longer repeated in a block on every page. Tap the band for Open the friends’ door and Sign out, then Done. When you are not signed in, the login form shows as before.
  • A slimmer header on admin pages on the phone: the wordmark stays and the site’s five section links are gone. ‹ The site is the way back.
  • An iPad uses the side menu, upright as well as sideways. The account block always sits at the foot of that menu, and the tool starts near the top of the screen.
  • One uploader entry on the phone: the menu shows the Phone uploader only, since the bulk one sends a phone there anyway.

Drag to reorder on Cards & strips and Album cleanup: you confirmed it works on the iPhone.

The phone page behind the Cloudflare sign-in (8 October 2026)

Since the admin’s Cloudflare sign-in was switched on on 9 October (the runbook record), the phone page has a new address: www.traveller.org/admin/api/m/. It opens straight on the albums — no passphrase screen — and its gold bar says signed in with Cloudflare. Its links to Publish and the other tools go to the admin on www, behind the same sign-in. Add it to the home screen in place of the old icon; the icon keeps its own sign-in, so the first time it opens it may ask for your email and the code Cloudflare sends. Everything on the page works as below. The old address keeps asking for the passphrase until stage two; the iPhone Shortcut keeps its passphrase for good, by your choice.

The icon on your home screen (22 August 2026)

Adding the site to an iPhone home screen now puts a Buddha’s head against a sunset sky there, labelled Traveller’s Tales. Before this it put a screenshot of whatever page you happened to be on — iOS does not fall back to the little browser-tab icon, and the site had no home-screen icon of its own since the 2004 favicon is 16 pixels square, far too small.

The mark is your own photograph, the square crop you supplied, resized into the three files a phone looks for: apple-touch-icon.png (iOS, 180px) and icon-192.png / icon-512.png (Android). Nothing was cropped or recoloured — the file is used as given.

To change it later, put a new square image in the shared Drive folder (traveller-uploads) and say so. A session reads it from there, writes the three sizes and publishes. That folder is the way to hand over any small file — images attached to a chat message can be looked at but not read as files, which is what made this icon take four attempts (22 August 2026).

The browser-tab favicon is still the original 2004 Bagan stupa — it was left alone deliberately, since it is part of the site’s own history. If you would rather the two matched, the same photograph can be cut down to 16 and 32 pixels; say so.

Two ways in, same pipeline

Everything below lands in the same storage and runs the same import as the desktop page — galleries, guardrails, duplicate checks and all. Photos are stood upright from the phone's own orientation data, and HEIC needs no conversion on your side.

1 — The phone app at /m (24 August 2026)

Opening the upload page on a phone now lands on a page built for the phone, at traveller-upload.brarob.workers.dev/m. Same passphrase, same storage, same pipeline — only the shape changed. The desktop form is untouched, and the phone is sent to /m automatically, so nothing about how you open the page changes: your home-screen icon and bookmarks keep working.

The whole flow is three decisions and one action:

  1. Album — tap the Album card and a list slides up. Type in the search box to find any album by its name, its country or its year ("vall" finds every Vallarta album at once), or scroll the list, which leads with your recent albums and then groups by country. Unlisted albums are marked ⊘ unlisted and never-imported folders ◌ not imported, exactly as everywhere else. (The share sheet’s own list spells the same two marks unlisted~ and pending~ — see why below.)
  2. Photos — tap the Photos card to open your photo library and multi-select. While the phone reads a big batch the card says "Preparing photographs…" with a spinner — tens of seconds on a large batch of HEICs, and nothing is wrong.
  3. Upload N Photos — the one dark button. It uploads, and when every photo has landed it starts the import by itself — there is no separate "Start import" any more on the phone. The receipt shows both steps and a View Album link. If any photo fails, nothing publishes on its own: the page names the failures, each with its size and what happened, and Retry re-uploads only those, then publishes everything together. If a photo keeps failing, Skip N, publish the rest (since 28 September 2026) publishes the ones that landed without it, and the receipt reads 118 of 120 uploaded and names what was skipped. Banknote batches offer Retry only — a note is a front and a back, and half a note cannot be identified.

Making a new album lives in the album list now — the + New album row at the top (or at the bottom of a search that found nothing). Country, year — the trip’s year, starting at this year — a name, and an Unlisted switch whose choice is remembered with the album. The Name field has a small round × at its right end whenever it holds text: tap it to empty the field in one go rather than deleting letter by letter (11 October 2026). Create & Select drops you back with it chosen; Create Another makes the next one. Every album made here also appears in the share sheet’s list within seconds, so this replaces the old “+ Create albums for the phone” panel for phone use.

Unlisted, and “Publish to www too”, for an album that already exists (11 November 2026). These two switches were on New Album alone, so changing either on an album already made meant a desk. Choose the album, open Upload settings, and they are there under This album: its name, set to what the album is now. Flick one and the album’s card on the home screen wears the new badge at once (⊘ Unlisted, ⊘ Albums only, or none); the change itself travels with your next upload to that album and takes effect when that import finishes. Left alone, they send nothing and the album stays exactly as it is. They are in the sheet and not on the home screen because that screen is fitted to the phone with no room to spare. Nothing is sent without photographs: to change an album you are not adding to, use Album cleanup.

Rarely-touched settings (shrink big photos — on by default — and parallel uploads) are behind Upload settings. Film and Notes at the top open the classic page with the right form already showing. Two things deliberately stay on the classic page: creating a country the site has never had (it needs a region, which only that page asks for), and uploading whole folders with place subfolders. The classic page is always reachable at ?stay=1.

2 — "Share → Upload to traveller.org" from the Photos app

Apple does not let websites appear in the share sheet, so this one-time setup uses the built-in Shortcuts app (about five minutes). Afterwards: select photos in Photos → Share → Upload to traveller.org → pick the gallery → done.

Written for iOS 26, and the two web addresses the recipe calls are verified against the Worker's own code. One thing only a real phone can show — what iOS names a photograph handed over by the share sheet — has a one-photo test built in at the end, with the fix beside it. If your phone disagrees with any step, say what it showed instead and this page will say that.

  1. Open Shortcuts → + (top right) to make a new shortcut. Tap its name at the top ("New Shortcut", with a ⌄ beside it) → Rename → Upload to traveller.org.
  2. Turn on the share sheet first — doing this adds the "Receive" bar at the top of the shortcut for you, which the rest of the recipe then feeds from.
    Tap ⓘ at the bottom of the editor, next to the action-search field, and switch on Show in Share Sheet. Close the panel: a bar now sits at the top of the shortcut reading "Receive Any input from Share Sheet".
  3. Limit it to photographs, in the bar itself (there is no setting for this in the ⓘ panel — the blue word Any in the bar is the control): tap Any, and in the checklist that opens untick everything except Images (Deselect All first if it's offered, then tick Images). The bar must read "Receive Images input from Share Sheet" — done right, the shortcut stops offering itself when you share a link or a PDF. Leave "If there's no input" on Continue.
  4. Now add these actions in order (find each by name in the search field at the bottom of the editor):
    1. Text — paste the upload passphrase into it. (It stays in your Shortcuts — synced only through your own iCloud, same standing as the browser's "remember".)
    2. Ask for Input — Text, prompt "Destination (country/year/name)". For an existing gallery, its path as the upload page shows it (vietnam/2009/halong-bay); for a new one, a fresh path — the import creates the gallery and titles it from the last part, so vietnam/2026/halong-bay publishes as Halong Bay. (The title is editable afterwards on Album cleanup if the capitals come out wrong.) This is the one typed step, and dictation works.

      Or don't type it at all. Three actions in place of this one turn the prompt into a list of every album on the site, tap to choose — the upgrade is further down this page, and section 3 is the same shortcut built from scratch. Build this one through to the end first if you are mid-way: the swap is an upgrade to a working shortcut, not a different recipe.

      Let iOS capitalise it if it wants to. The keyboard capitalises the first letter of anything typed or dictated into a prompt, so mexico/2026/vallarta becomes Mexico/2026/vallarta and there is no way to stop it short of deleting the letter every time. The address is folded to lower case on the way in, so both spellings reach the same place (owner hit this, 2026-08-19). Only the destination is folded — each photograph's own filename keeps its capitals exactly.
      A trailing slash is fine too, and a stray space either side. Type spain/2026/vallarta or Spain/2026/vallarta/ and both land in the same album. What the upload will not do is guess a missing gallery name: spain/2026 makes an album called “2026”, so give it the last part.
    3. Repeat with Each over Shortcut Input — check this one. Shortcuts pre-fills a new Repeat action with the previous action's output, so it arrives reading "Repeat with each item in Ask for Input", which loops over the destination you typed instead of over the photographs. Tap that blue token and choose Shortcut Input (it's under the variable picker's Shortcut heading). It must read "Repeat with each item in Shortcut Input".
      End Repeat appears by itself the moment you add this action — it is not one of the six you add, and there is no action by that name to search for. It marks the bottom of the loop, and everything from here is placed relative to it: the next action goes between the two, the ones after that go below End Repeat.
    4. Get Contents of URL — the action that sends one photograph. It is the fiddliest of the six, so it is broken into single steps below.
      Before anything else, check where it landed. This action must sit inside the loop — indented, between Repeat with each and End Repeat. Shortcuts adds new actions at the bottom of the shortcut, so it will usually arrive underneath End Repeat. Drag it up by the handle on its right-hand edge until it sits indented under the Repeat. Outside the loop it runs once with nothing to send, and the rest of this step is wasted.
      Then work down the action in this order:
      1. Tap the URL field and type this, and only this:
        https://traveller-upload.brarob.workers.dev/put?key=
        Stop at the =. Do not type the passphrase here. key in this address means the storage path the photograph is filed under — vietnam/2009/halong-bay/IMG_1234.jpg — and the next three steps build it out of variables. It is not the upload key, despite the name; the passphrase goes in the x-upload-key header at step h and nowhere else.
        Typed here it would become part of every photograph's address in storage, and those addresses are served publicly — the passphrase would be readable by anyone who opened a picture. The Worker now refuses such an upload outright and says so (owner did exactly this, 2026-08-19), so nothing is lost if it happens; but if it has already been typed, rotate the passphrase rather than only correcting the field.
      2. Leave the cursor at the end of what you typed. Tap Ask for Input in the variable strip above the keyboard — that is the destination you typed at action 2.
        Pick Ask for Input, not Shortcut Input — they sit in the same strip, one above the other, and only one is right. Ask for Input is the destination path; Shortcut Input is the pile of photographs from the share sheet, which would land where the folder name belongs.
        Once placed, the token may read Provided Input instead — that is Shortcuts' older name for the same thing, and it is correct. This page used to call it that throughout, which sent the owner hunting the strip for a word that is not in it (2026-08-19).
      3. Type one forward slash: /
      4. Tap Repeat Item in the same variable strip.
      5. Tap the Repeat Item token you just placed. A panel slides up from the bottom of the screen. In it:
        1. Under the three buttons (Clear Variable · Reveal Action · Return) is a grey row reading Type, with App on its right and a small › after that. That row is a button — tap it. Nothing about it says so except the ›.
        2. Choose File from the list of content types that opens. (Image works too if it is offered; a photograph is both, and both carry a Name.)
        3. You come back to the same panel, now reading Type: File — and the properties underneath have changed to File Extension, File Size, Creation Date. That change is the confirmation you set the right thing.
        4. Tick Name, then tap Return.
        That is what puts each photograph's own filename on the end of the address.
        Check the Type row before you tick anything. Shortcuts cannot know what a Repeat Item holds until the shortcut runs, so it guesses — and it guesses App. An App has a Name too, so the tick looks right while meaning the wrong thing. The giveaway is the rest of the list: if the properties beneath are Is Running, Is Hidden, Is Frontmost, you are looking at an app. A File offers File Extension, File Size, Creation Date instead.
        Left on App, Name resolves to nothing at run time and each photograph is stored under the destination alone — so the whole batch overwrites itself down to one file, with no error. The Worker now refuses a path with an empty segment rather than storing that, so the failure at least announces itself (owner, 2026-08-19).
        The token keeps reading just Repeat Item either way — it does not display the property. Tapping it and seeing the tick is the only confirmation there is. This page used to claim the token would read Repeat Item · Name; it does not.
        If the Type row will not open, or the list has no File: stop fighting it and use the fallback at the foot of this page — add Get Details of Images inside the loop above the upload action, set it to get Name of Repeat Item, and swap the address's last token for that action's result. One extra action, same outcome.
        The URL field now reads:
        https://traveller-upload.brarob.workers.dev/put?key=[Ask for Input]/[Repeat Item], the second token set to File → Name
        Two variable tokens, one typed slash between them. If yours has more or fewer tokens than that, fix it here before going on.
      6. Tap the › at the right-hand end of the action to unfold it. Method, Headers and Request Body do not exist on screen until you do this — if you are hunting for them, this is the step you missed.
      7. Set Method to PUT.
      8. Under Headers, tap Add new header. Type the key x-upload-key. Then tap the value field and insert the Text variable from the strip. Do not retype the passphrase — insert the variable, so rotating it later means editing one action instead of hunting for copies.
      9. Set Request Body to File, then set the file to Repeat Item. Plain Repeat Item here — not Repeat Item · Name. The address needs the photograph's name; the body needs the photograph. This is the one place the two are easy to confuse.
    5. Get Contents of URL, the second one — this starts the import once every photograph is up, so it goes after End Repeat, outside the loop. If it lands inside, drag it down.
      1. URL: https://traveller-upload.brarob.workers.dev/dispatch — typed plainly, no variables in it at all.
      2. Unfold it with the ›, the same as before.
      3. Set Method to POST.
      4. Under Headers, add x-upload-key with the Text variable as its value — same as the last action.
      5. Set Request Body to JSON, and add two fields:
        • kind → import-path — typed as text
        • path → Ask for Input — inserted as a variable, the same one as the address above, and again not Shortcut Input
    6. Show Notification — and the text is not typed. It is the answer the site sends back, so the notification says what actually happened instead of always saying it went well.
      1. Tap the notification's text field. If it already holds words — "Uploaded — import started." from an earlier version of this recipe — delete them all.
      2. With the field empty, tap Get Contents of URL in the variable strip above the keyboard.
      3. Check you got the right one, because there are two actions by that name. Tap the token you just placed and choose Reveal Action: the editor scrolls to the action the token refers to. It must be the /dispatch action below End Repeat. If it lands on the upload action inside the loop, tap the token again, Clear Variable, and pick the other Get Contents of URL from the strip.
      What it will say now. The site counts what actually arrived in this batch before it starts anything:
      • "12 new photograph(s) at spain/2026/vallarta — import started."
      • "12 new photograph(s) at spain/2026/vallarta (57 there now) — import started." — adding to an album that already held 45.
      • "Nothing at spain/2026/vallarta — no photograph arrived, so no import was started. Check the destination and share them again."
      • "The site refused this phone's uploads: 5 refused as “wrong passphrase”. The PUT action's Headers must carry x-upload-key with the Text variable… Nothing new arrived at spain/2026/vallarta — the 26 photograph(s) there are from before, so no import was started."
      The first half of that last one is new (14 September 2026), and it is the part that matters — which is why it comes first. An iOS banner shows a line or two of a notification; for one evening the refusal sat at the end of the sentence and the phone showed only “nothing new arrived”, the half you could already guess. Long-press the notification to read all of it. The shortcut throws away the answer to every upload, so when the site refused a batch nothing anywhere recorded why — and the notification went on to blame the album token, which was the August fault and not the September one. The site now remembers what it refused from your phone for half an hour and the dispatch, the one request whose answer the shortcut does show, reports it: how many, refused as what, and which setting in the PUT action produces that refusal. “No upload from this phone reached the site” means exactly that: nothing was stored and nothing was refused, so the request was never made or went somewhere else. The message says what to check, in order: that Repeat with Each is over Shortcut Input (over anything else it runs zero times, and only the dispatch is ever sent — which fits a batch of one failing exactly like a batch of a hundred); then the PUT action's URL, Method and Request Body. A request that reaches the upload address with the wrong Method — GET is the action's default — is remembered as “wrong method” since 15 September, so the memory has no blind spot left on that path.
      The count says NEW for a reason too. It used to report the folder's total, which answered "did my photographs land?" perfectly for a new album — where the total is the batch — and not at all for an existing one. Two photographs shared to an album already holding 26 were refused, and the phone said "26 file(s) … import started" (owner, 2026-08-21). A batch that never landed reported as a success, which is the one thing this sentence exists to prevent.
      And “new” no longer means “recently timestamped” (14 September 2026). The check read each file's upload time, and renaming an album resets it — a rename copies every photograph to the new folder, so for half an hour afterwards the album's existing photographs all look as though they had just landed. 114 photographs shared to an album renamed ten minutes earlier got “import started” on the phone and an email reporting the 4 that were already there; twice, because nothing said what had happened the first time. The count now compares storage against what the site already records for that album, which no copy can fake. A folder never imported has no record to compare, and there the timestamps are right: with no record, the total is the batch.
      The second one is the whole reason for this step. It used to be indistinguishable from the first (owner lost a Spain batch to it, 2026-08-19): every upload was refused, the import found an empty folder, and the phone said it worked. Nothing is started when nothing arrived — a run certain to fail costs build minutes and tells you less than that sentence does.
    Read it back before the first run. Top to bottom, with the indentation shown, the finished shortcut is exactly this:
    1  Text                  the passphrase
    2  Ask for Input         "Destination (country/year/name)"
    3  Repeat with each item in Shortcut Input
    4      Get Contents of URL   PUT   /put?key=[Ask for Input]/[Repeat Item→File→Name]
    5  End Repeat
    6  Get Contents of URL   POST  /dispatch
    7  Show Notification     [Get Contents of URL]  ← the /dispatch one, line 6
    Line 2 is the one with a better version — an album list you tap instead of a path you type. Two ways there: swap this one action for three, or rebuild the whole shortcut fresh with the list built in — a complete recipe, nothing carried over.
    The two that fail quietly, and so are worth looking at twice: line 3 must say Shortcut Input and not Ask for Input, and line 4 must be indented under the Repeat rather than sitting below End Repeat. Neither shows an error; they simply upload nothing, or upload the destination you typed instead of your photographs.
    The two variables, and which goes where: the Repeat takes Shortcut Input — the photographs off the share sheet. Both URLs take Ask for Input — the destination you typed. They live side by side in the same variable strip, so the one check worth making twice is that neither has the other's.
  5. First run — one photograph, on purpose: open Photos, select a single photo, tap Share, and scroll the sheet down past the app row — Upload to traveller.org is in the list of actions below (if it isn't, scroll to the sheet's foot → Edit Actions… → add it). Send it to an existing gallery. iOS will ask permissions on this first run — to read the photos, and "Allow … to connect to traveller-upload.brarob.workers.dev?": answer Always Allow, or a forty-photo batch will ask forty times.
    Done when: the photo appears under its own name (IMG_…) for that gallery on Album cleanup, and the import email arrives. If it shows up nameless or the import finds nothing, use the fix in the box below — that is the one behaviour a page cannot promise for a phone it has never met.
  6. Before the first BIG batch — one switch (23 August 2026). iOS limits how many items the share sheet will hand to a shortcut at once, as a privacy guard against a shortcut quietly hoovering up your library. Cross it and you get a banner — “This action is trying to share 52 Photos… You can allow this in Settings” — and the batch never reaches the shortcut at all. Nothing is uploaded twice and nothing is lost; it simply does not arrive.
    Turn it on once: Settings → Apps → Shortcuts → Advanced → Allow Sharing Large Amounts of Data. (On older iOS the Shortcuts settings sit at the top level: Settings → Shortcuts → Advanced. Searching Settings for “large amounts” finds it either way.)
    Then check the count. The banner said 52 where the picker said 51 selected — after allowing it, confirm the number that lands on Album cleanup is the number you sent.
    This is a third prompt, separate from the two above — photo access, and the connection prompt that wants Always Allow. All three are one-time.
If the one-photo test lands nameless or oddly named (or the import says it found none): the address each file is stored under ends in Repeat Item · Name, and photographs handed over by the share sheet do not always carry a filename. The fix stays inside the loop: add Get Details of Images before the upload action, set it to get Name of Repeat Item, and swap the URL's final token to that action's result.

A name that arrives without its extension is no longer a problem — the photograph stored as IMG_1234 with no .heic/.jpg. That happened for real on 27 August, to four photographs of Madrid: they reached storage, the import counted them as stray files, and none was published while the run reported success. The site now names such a file from the photograph's own contents — as it is stored, and again at import for anything already sitting in the bucket — and the review email lists each one. Nothing in the Shortcut changes. See the pipeline page.

The Shortcut sends full-size originals. The on-device shrink is a feature of the upload page, not of Shortcuts — a share-sheet batch is roughly four times the data of the same batch sent from the app, and lands at identical published pixels either way. On cellular, or for a batch of more than a few dozen, the app is the cheaper route.

Two things the phone cannot do, and one it now does for you. It cannot create a country: that needs a display name and a region, and a share sheet has nowhere to ask — so a destination naming a country the site has never had is refused immediately, on the phone, before anything uploads. A country’s first batch goes through the upload page; after that the Shortcut can send to it like any other. It cannot mark an album unlisted either, nor choose which site it is on — those switches are on the upload page, or on Album cleanup afterwards; an album created for the albums site alone keeps that choice on its folder until its first batch imports. What it does do for you is spelling: type united-states/2026/sonoma-house and the country is folded onto the site’s own spelling (unitedstates) at both ends of the upload, so the photographs land where the import will look for them. Either shape of address works: country/year or country/year/name.

“1 new photograph(s)” when you sent thirty-five. The count in that message is read from storage, not from what the phone believed it sent, so it is telling the truth: that many files arrived. The notification now names them when only one, two or three do — “1 new photograph(s) at australia/2019/sydney — IMG_4936.jpeg — import started” — so you can see which photograph that was without opening anything. A real batch is counted and not listed; forty names is not a notification.
If the name is the single photograph you used to create the album, the batch itself never left the phone. The usual cause is the share-sheet limit above: iOS refuses a large share whole and silently, and what is left in the album is the one you seeded it with. Turn on Allow Sharing Large Amounts of Data and send again.
If the name is a photograph you did not choose at all, and the same one keeps arriving at different albums, that is a different fault: the upload action in the shortcut is bound to a fixed file rather than to the repeat’s own item. Open the shortcut, find the Get Contents of URL that uploads, and make sure the file attached to it is Repeat Item — not [Ask Each Time], Shortcut Input, or a token left over from an earlier recipe. iOS draws them all as the same blue pill.

The /dispatch call accepts either a full path, or country + year + name parts — it assembles and slugifies the address server-side, so the Shortcut never has to manipulate text. If the passphrase is ever rotated, edit the one Text action.

Already built the typed version? Swap in the album list

This section is the upgrade path for a shortcut built from section 2: it swaps the typed destination box for a list of every album you tap. If you would rather not edit in place — or you have never built the shortcut at all — section 3 below is the complete recipe from scratch, and it is the simpler document.

Delete action 2 (Ask for Input) and put these three in its place, in order:

  1. Get Contents of URL — URL https://traveller-upload.brarob.workers.dev/albums.txt, typed plainly. Unfold the ›, leave Method GET, add one header: key x-upload-key, value the Text variable from action 1 (insert it from the strip — do not retype the passphrase).
  2. Split Text — Separator New Lines. (It pre-fills from the previous action, which is right.)
  3. Choose from List — from Split Text. This is the screen you see on every upload: every album on the site, one per line, a search field at the top.

Two marks in that list

The list is nothing but paths, so until 22 August 2026 a hidden album looked exactly like a published one. A line now begins with a mark when it is not on the public site.

What you see when you tap Upload

peru/2010/inca-trail
morocco/2021/fez
pending~morocco/2026/tangier
unlisted~peru/2004/reunion
peru/2010/cuzco
Why a word and a tilde, not the ⊘ and ◌ the rest of the admin uses (15 September 2026). The line you tap goes straight into the upload address, and for three weeks the marks were a glyph and a space — characters a web address cannot carry. The phone made no request at all for any marked album, said nothing, and ran the dispatch as if it had: 74 photographs, then 115, 114, 5, 1 and 1, every one to an unlisted album, every one lost. A share to a public album — no mark — worked first time, which is what found it. unlisted~ and pending~ are made only of characters every address accepts as they are, and a tilde never appears in a real album path, so the site strips it exactly. Nothing in your shortcut changes.
⊘
Unlisted album A real album — imported, with a page of its own — that you deliberately took off the site’s lists. Reachable by its address and listed nowhere. Not private: anyone with the link can open it.
◌
Uploaded, never imported Photographs that reached storage and were never processed. No page, no thumbnails, no record yet. Sending more to it is fine — they join the rest and import together.
none
An ordinary published album On the site, in the counts, in the sitemap.

The list stays in alphabetical order: it is sorted on the path and marked afterwards, so a marked album keeps its place rather than bunching with the others that share its glyph.

Nothing in the Shortcut changes. Tap a marked line exactly as before. The upload address and the dispatch both remove the mark at the Worker — which is why it sits at the front of the line and not the end: a photograph’s filename can contain spaces, and a place subfolder travels in the same address, so a mark at the end could not be told apart from a real name.

Then re-point the two fields that still hold the deleted token. The upload URL and the dispatch body both carried Ask for Input, and a deleted action's token does not go away by itself:
• the PUT action inside the Repeat — its address becomes …/put?key=[Selected Item]/[Repeat Item]
• the POST action's JSON path field — also Selected Item
(Your phone may label the variable Chosen Item — same thing, the output of Choose from List.)
Deleting the old action does not clear its token — iOS quietly replaces it with [Ask Each Time], which is a different variable that looks like any other blue token. Both addresses must be checked by eye and re-pointed by hand; the owner's dispatch was correct while the upload address held [Ask Each Time], and nothing on screen said so (2026-08-21).
What missing one looks like (owner, 2026-08-21, twice): the album list appears, you pick an album — and either every photograph is refused with “the storage path needs a folder and a filename”, or the phone says “Nothing new arrived … the N photograph(s) there are from before”. The uploads went nowhere; the stale token resolved to nothing.

The list is live — read from the site each time, so an album imported yesterday is in today's list, unlisted albums and not-yet-imported folders included; albums marked legacy are left out, since their photographs live on the old server. There is no “new album” row any more: the typed fallback it fed was the source of every failure this recipe has had, and the owner retired it (2026-08-21). A new album starts on the upload page (way 1), which can ask the questions a new album needs; from then on it is a line in this list. An older shortcut that still carries the If block keeps working — with no list row containing “New album” its If simply never fires, and the album you tapped passes straight through.

3 — Build the Shortcut from scratch, step by step

The complete recipe, written for someone who has never opened the Shortcuts app. Nothing is typed on upload day: you share photos, tap an album from a list, done. There is no typed destination and no If in this version — the site keeps the album list, the shortcut only shows it. About ten minutes to build.

Two ground rules before you start. Build this as a new shortcut beside any existing one — the old one keeps working until the new one passes its test, and only then do you delete it. And a brand-new album starts on the upload page (way 1, the home-screen app), because a new album needs questions answered that a list cannot ask; once imported it appears in this shortcut's list like every other album.

Part one — create it and turn on sharing

  1. Open the Shortcuts app. Tap + (top right).
  2. Tap the name at the top (“New Shortcut”, with a small ⌄ beside it) → Rename → type Upload to traveller.org 2. (The 2 is temporary — it keeps this build apart from any old one while you test.)
  3. Tap the ⓘ button at the bottom of the screen and switch on Show in Share Sheet. Close that panel. A bar appears at the top of the shortcut reading “Receive Any input from Share Sheet”.
  4. In that bar, tap the blue word Any. Untick everything except Images (tap Deselect All first if it is offered). The bar must end up reading “Receive Images input from Share Sheet”. Leave “If there's no input” on Continue.

    What the top of your shortcut now shows

    Receive Images from Share Sheet
    If there's no input: Continue

Part two — add the seven actions

Find each action by typing its name into the Search Actions field at the bottom of the editor, then tap it to add it. Each new action lands at the bottom of the shortcut, which is where it belongs — except the upload action at step 6, which gets dragged one place up.

  1. Text — tap the empty box and paste the upload passphrase into it. This is the only place the passphrase is ever typed; every later step inserts this Text variable instead of typing it again. (It stays in your own Shortcuts, synced only through your own iCloud.)
  2. Get Contents of URL — this fetches the album list.
    1. Tap the blue URL box and type, exactly: https://traveller-upload.brarob.workers.dev/albums.txt
    2. Tap the › at the end of the action to unfold it — Method and Headers are hidden until you do.
    3. Leave Method on GET.
    4. Under Headers, tap Add new header. In the key box type x-upload-key. Then tap the value box — a strip of blue variable buttons appears above the keyboard — and tap Text in that strip. Do not type the passphrase here; the Text token stands for it.

    The finished action

    Get contents of https://traveller-upload.brarob.workers.dev/albums.txt
    Method GET  ·  Header x-upload-key = Text
  3. Split Text — it arrives already reading “Split Contents of URL by New Lines”, which is exactly right. Touch nothing.
  4. Choose from List — arrives reading “Choose from Split Text”, also right. This is the album list you will see on every upload, with a search field at the top.
  5. Repeat with each — tap the empty token and choose Shortcut Input from the variable list (the photographs off the share sheet). It must read “Repeat with each item in Shortcut Input” — not Selected Item, which would loop over the album name instead of your photographs. Shortcuts adds the End Repeat row by itself.
  6. Get Contents of URL (a second one) — the upload itself. It lands below End Repeat; press and hold it and drag it up one place, so it sits indented between Repeat and End Repeat. Then, in order:
    1. Tap the URL box and type https://traveller-upload.brarob.workers.dev/put?key= — and stop at the =. Never the passphrase here: key means the storage path, not the upload key, and this address is public. (The full story is at section 2, step d-a.)
    2. With the cursor at the end, tap Selected Item in the variable strip. (Your phone may label it Chosen Item — same thing, the output of Choose from List; it carries the same blue list icon.) Not Ask Each Time, which sits near it in the same strip and is a different variable altogether — it makes the address ask you at run time instead of using the album you tapped.
    3. Type one forward slash: /
    4. Tap Repeat Item in the strip.
    5. Now tap the Repeat Item token you just placed. In the panel that opens, the grey row reading Type with App beside it is a button — tap it, choose File, tick Name, tap Return. If the panel offers File Extension, File Size, Creation Date, you set the right thing; if it offers Is Running, Is Frontmost, the Type is still App — go back and change it. (Why, at section 2 step d-e.)
    6. Unfold with ›. Set Method to PUT.
    7. Under Headers: x-upload-key with the Text variable, same as before.
    8. Set Request Body to File, and the file to plain Repeat Item — the address carries the photograph's name; the body carries the photograph itself.

    The finished upload action, indented inside the repeat

    Repeat with each item in Shortcut Input
    Get contents of https://traveller-upload.brarob.workers.dev/put?key=Selected Item/Repeat Item
    Method PUT  ·  Header x-upload-key = Text  ·  Body File → Repeat Item
    End Repeat
  7. Get Contents of URL (a third one) — tells the site the batch is complete so the import starts. It belongs where it lands: below End Repeat.
    1. URL: https://traveller-upload.brarob.workers.dev/dispatch — typed plainly, no variables.
    2. Unfold. Method: POST.
    3. Headers: x-upload-key → the Text variable.
    4. Request Body: JSON. Add two fields: kind → type the word import-path; path → insert the Selected Item variable (not typed — the same token as in the upload address).
  8. Show Notification — leave its text box empty of typed words and insert the Get Contents of URL variable, so the phone shows the site's real answer instead of always claiming success. There are three actions by that name now: tap the token you inserted → Reveal Action, and confirm it jumps to the /dispatch action from step 7. If it jumps anywhere else, tap the token, Clear Variable, and pick another until it lands right.

    The last two actions

    Get contents of https://traveller-upload.brarob.workers.dev/dispatch
    Method POST  ·  JSON: kind = import-path, path = Selected Item
    Show notification Contents of URL
Read it back before the first run. Top to bottom, indentation included, the finished shortcut is exactly this:
1  Text                  the passphrase
2  Get Contents of URL   GET   /albums.txt   (header x-upload-key = [Text])
3  Split Text            by New Lines
4  Choose from List      from Split Text
5  Repeat with each item in Shortcut Input
6      Get Contents of URL   PUT   /put?key=[Selected Item]/[Repeat Item→File→Name]
7  End Repeat
8  Get Contents of URL   POST  /dispatch   path = [Selected Item]
9  Show Notification     [Get Contents of URL]  ← the /dispatch one, line 8
The three variables, and where each one goes — this is the whole machine:
• Text (the passphrase) → the three x-upload-key headers, nowhere else
• Shortcut Input (the photographs) → the Repeat on line 5, nowhere else
• Selected Item (the album you tapped) → the two URLs, lines 6 and 8

Part three — prove it, then retire the old one

  1. One-photo test: open Photos, select a single photograph, tap Share, and choose Upload to traveller.org 2 from the sheet (scroll down; if it is missing, the sheet's foot has Edit Actions…). The album list appears — pick a small existing album. Answer Always Allow to the connection prompt, or a forty-photo batch will ask forty times.
  2. Done when the notification reads “1 new photograph(s) at … — import started” and the photo appears under its own name on Album cleanup. If it says “Nothing new arrived” instead, a token in the two URLs is wrong — the check below finds which.
  3. Then: long-press the old Upload to traveller.org in Shortcuts → Delete, and rename the new one to drop the 2. One name in the share sheet, and it is the one that works.

Check it against these three things before the first run

Reading a finished shortcut back on screen, three of its settings are invisible — the tokens look identical whether they are right or wrong. Each one fails silently, so each is worth one tap to confirm.

  1. The album token in the two URLs. The PUT address and the POST path must both read Selected Item (or Chosen Item — two labels, one variable). The classic miss is a leftover token from the typed recipe. It wears one of two disguises: [Ask for Input] if that action still exists, or [Ask Each Time] if you deleted it — iOS substitutes that automatically, and it renders as an ordinary blue token with nothing to mark it as wrong. Tap the token in the PUT action's address and check the word; do the same in the POST action's path field (unfold it with ›).
    Symptom: every photograph refused with "the storage path needs a folder and a filename", or the notification reads "Nothing new arrived … the N photograph(s) there are from before". This token is the one the POST shares, so when it is wrong the dispatch fails too — if the phone shows a sentence naming your album, the POST's copy of this token is right. The PUT action has its own copy, and since 14 September the notification says whether that one resolved (refused as “no album in the storage path” means it did not).
  2. The Repeat Item's property in the PUT address. The token reads Repeat Item whether or not its Type is File and Name is ticked — it never displays the property. Tap it and look. The panel, and the App/File trap.
    This one no longer loses the photographs (14 September 2026). When that property resolves to nothing the address ends with a slash and no filename, and the site used to refuse every such upload — which reached nobody, because the shortcut never reads the answer to an upload. Four batches went that way in three weeks: 74 photographs, 115, 114, and a single one, every one handed over, refused, and reported by the phone as a success.
    The site now names them itself: they arrive as unnamed-20260914-183012-a7f3.jpeg — the date and time they landed, plus enough randomness that two photographs in the same second cannot collide. So a batch sent with this setting wrong arrives in full rather than vanishing.
    You will see those names in the album, and that is deliberate: it is the signal that the shortcut is still mis-set. Fix the property and the next batch keeps its real filenames. The ones already named this way can be left — nothing downstream cares — or the album re-uploaded once the setting is right.

    Symptom: a whole batch arrives as a single photograph, or the import finds nothing.
  3. The passphrase header on all three Get Contents of URL actions. Unfold each and confirm x-upload-key is present with the Text variable — not retyped, and not missing.
    Symptom: "wrong passphrase", or the album list never appears.
Then the one-photo test, which is the only check that proves all three at once: share a single photograph to an existing album and confirm it lands under its own name on Album cleanup. Pick an existing album deliberately — the typed-new-album branch is the one that keeps working when the destination token is wrong, so testing that half first proves the least.

Giving the Shortcut to someone else

Never share it with the passphrase still in it. Action 1 is a Text action holding the upload passphrase as plain, readable text, and it travels inside the shared link — anyone who opens that link, or anyone it is forwarded to, can tap that action and read it. The passphrase is the only lock on the upload Worker: it grants writing photographs into the bucket and starting imports that commit to the site. Treat handing it over as handing over the ability to publish.

So share a copy with the field emptied, and send the passphrase by a different route. Five steps:

  1. Duplicate your own Shortcut — in the Shortcuts app, press and hold it and choose Duplicate. Yours stays working; the copy is the one that travels.
  2. Open the copy, tap the Text action at the top, and delete the passphrase, leaving the field empty. Rename the copy something like Upload to traveller.org (setup) so the two are never confused on your own phone.
  3. Open the copy's › (or the share button) → Share → Copy iCloud Link. That makes a public, unlisted icloud.com/shortcuts/… address.
  4. Send the link. The person opens it, Shortcuts shows what the shortcut can reach, and they tap Add Shortcut.
  5. Send the passphrase separately — a different message, ideally a different app from the one carrying the link. They tap the empty Text action once and type it in. Nothing else needs setting up.

Two things worth knowing afterwards. The iCloud link stays live until you open the copy and choose Stop Sharing — it is not tied to who you sent it to, so revoke it once everyone has added the shortcut. And rotating the passphrase means everyone retypes their one Text action; that is the price of a single shared secret, and it is the reason for the note below.

One passphrase, shared by everyone. The Worker checks a single UPLOAD_KEY, so every phone carries the same secret: you cannot cut off one person without cutting off all of them, and nothing in the pipeline records which phone sent which batch. That is fine for a couple of people you would trust with the repository itself. If the Shortcut is going to more phones than that, ask in a session for per-person keys — the Worker can hold a list instead of one value, so a key can be revoked on its own and the import email can say whose upload it was.

If a recipient is told the shortcut cannot be added: older iOS had a Settings → Shortcuts → Allow Untrusted Shortcuts switch that had to be on before a shared shortcut would install. Current iOS scans the shortcut and shows what it can reach instead, so this rarely comes up — but that setting is the thing to look for.

Shooting and sending tips

  • Share sheet and photo picker both deliver the photo's real file (HEIC or JPEG) — either is fine, and orientation is handled.
  • iCloud "Optimize iPhone Storage" means some photos download from iCloud before they upload — a long pause before the first progress is that, not a hang.
  • Currency notes have their own flow — see Updating the site → banknote scans: name the file for the note and drop it on the upload page's Notes tab (that tab's picker also opens the photo library on a phone).