[k-r-a-s-s]

Problem

raisely update / raisely init write each synced page to pages/<page.name>.json. Template pages have unique names (home, dashboard, profile, …), but every custom page-builder page has name: "legacy" — so on any campaign with more than one custom page, all of them are written to the same legacy.json, last write wins.

Observed on our campaign: the API returns 72 pages, 55 of which are custom (name: "legacy"). After a sync, only the ~20 uniquely-named template pages plus a single legacy.json exist locally — 54 custom pages never land on disk, and legacy.json holds whichever custom page the API happened to return last (which can change between syncs).

Beyond the missing files, this is a correctness hazard: raisely deploy PATCHes every local page JSON by its embedded uuid, so a stale legacy.json snapshot of a semi-random page can silently revert that page's body/status/path in the admin.

Fix

Extract the naming logic into pageFileNames(pages), which computes names for a campaign's page set as a whole:

• a page's name is used only when it's unique within the campaign (all existing template-page filenames are unchanged: home.json, dashboard.json, …);
• pages with a shared or missing name are named from their path (/cause-areas → cause-areas.json), matching the existing fallback already used for unnamed pages;
• residual collisions after character sanitization get a short uuid suffix so no two pages can ever share a file.

Deploy needs no changes — it already resolves the target page from the uuid inside each file, not the filename.

Notes

• On repos synced with the current behaviour, the first sync after this fix writes custom pages as new path-named files; the old legacy.json is left behind and can be deleted (it duplicates one of the new files' uuid).
• Added tests/sync.test.js covering unique names, the shared-legacy fallback, unnamed pages, sanitization, and suffix disambiguation. Full suite passes (111/111).

🤖 Generated with Claude Code

---

Note

Medium Risk
Sync output filenames change for campaigns with multiple custom pages, which can leave stale legacy.json locally but fixes silent data loss and deploy correctness risk from wrong page bodies keyed by uuid.

Overview
Fixes page sync so multiple custom (page-builder) pages no longer overwrite a single legacy.json when they all share name: "legacy".

pageFileNames(pages) replaces per-page pageFileName: it assigns filenames across the whole campaign—unique page.name values still map to stable template files (home.json, etc.), while shared or missing names use path-based names with sanitization, and uuid suffixes when paths collide after sanitization. A two-pass rule reserves unique name-based filenames so API order cannot steal e.g. profile.json from a template page.

syncPages writes each page using the computed filename; deploy behavior is unchanged because targets are resolved by embedded uuid, not filename. New tests/sync.test.js covers shared legacy, unnamed pages, sanitization, template reservation, and collision suffixes.

^{Reviewed by Cursor Bugbot for commit 5489e7d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 72243dd. Configure here.}

[k-r-a-s-s]

Good catch from Bugbot — fixed in 5489e7d. pageFileNames now assigns names in two passes: unique-name (template) filenames are reserved up front, then shared/unnamed pages get path-based names around them, so a custom page at e.g. /profile can never displace profile.json regardless of API order (it gets the uuid-suffixed name instead). Added a regression test for exactly that ordering; suite passes 112/112.

[benrfairless]

@xolott-ark @giovanny-keela Hi there! Are either of you able to approve this PR? It has been outstanding for a while and breaks basic functionality of the cli.

[KeinerM]

@k-r-a-s-s Thank you for tracking this down, and sorry this took a while to review. The write-up made the bug easy to reproduce, and the template-name reservation you added after the Bugbot comment works well.

We tested the branch on a staging campaign. Sync now writes every page, and the filenames stay the same between runs. We found one case that affects people who are upgrading.

Sync doesn't remove the file it wrote under the old name, so after the first sync two files share a uuid. In our test:

• legacy.json and renamed-home-page.json
• magicLink.json and magic-link-a0a04680.json

raisely local picked the old magicLink.json, and raisely deploy would send both files as updates for the same page, so the old content could win.

Could you have syncPages remove those old files after it writes the new ones? Only files whose uuid was part of this sync and whose filename differs from the new one. Files from pages that weren't in the sync, and files that aren't valid JSON, should stay. A test with an old legacy.json in the pages folder would cover it.

If you'd rather not, we're happy to push this change to your branch or follow up in a separate PR. Thanks again for the fix.

[KeinerM]

One small follow-up here: could we remove old page files whose UUID we just wrote under a new name, like legacy.json? Details in the review summary.