19-Sep-2026 — site registration for groups and areas builds a finished-looking site with photos by year #20

<h1>19-Sep-2026 — site registration for groups and areas builds a finished-looking site with photos by year <a href="https://github.com/nbarrett/ngx-ramblers/issues/20">#20</a></h1>
<h2><a href="https://github.com/nbarrett/ngx-ramblers/actions/runs/35668027577">build 959</a> — <a href="https://github.com/nbarrett/ngx-ramblers/commit/83d2fd63a46681140fafc78907cd59c393f3e7a0">commit 83d2fd6</a></h2>
<hr>
<h2>What&#39;s new</h2>
<p>A Ramblers group or area can now ask for its own NGX site through a public registration form, and a reviewer can follow, steer and approve the build before the group is invited. A Full registration reads the group&#39;s current website, lets the group choose which pages come across, and builds a review site that already looks like NGX: the group&#39;s Ramblers logo and banner, its pages under a standard navbar, a home page with one carousel and buttons to the main areas, walk galleries filed under Photos by year and linked to the matching Walks Manager walks so they appear on a map, and its documents and committee members. A Lite registration gives the committee email and membership tools with a small public site. The group&#39;s current website is never changed. A new group never inherits a live Brevo sending key or the platform&#39;s database user, and public registration cannot be switched on until the credentials a new site needs are in place. Email Configurations that had no template can now be fixed on screen.</p>
<h2>At a glance</h2>
<ul>
<li>A public Register your group or area form takes a group or area from choosing Lite or Full to a review site being built</li>
<li>Find pages reads the current website into a tree of new pages that the group ticks, unticks and reorders</li>
<li>The import brings across words, photos, documents and committee members, tidied and laid out the NGX way</li>
<li>Reviewers follow every build in one log, can stop or retry it, and approve the site before the group is invited</li>
<li>Home is an introduction with one carousel, then buttons to Walks, Photos and the other main areas</li>
<li>Photos are filed under a page per year, each listing its albums on a map and as buttons</li>
<li>Albums are linked to the matching Walks Manager walk when the date and place leave only one candidate</li>
<li>Every new site gets its group&#39;s Ramblers logo, a banner made from it, and email settings that use that banner</li>
<li>Each new site gets its own database user and starts with no Brevo key</li>
<li>Email Configurations with no template can be given a template or their own wording</li>
<li>Sites still being prepared are left out of estate-wide deploys until they are approved</li>
</ul>
<h2>Where to find it</h2>
<ul>
<li>Register your group or area, at /register, is the public form a group or area secretary uses</li>
<li>Admin → Platform → Environment management → Site registrations turns public registration on and lists every request with its progress and build log</li>
<li>Admin → Content → Content Templates holds the self-service migration templates the build uses, including the photos year and photos index layouts</li>
<li>Migration Settings on a review site shows and amends the import settings chosen at registration</li>
<li>The how-to pages at /how-to/group-registration, /how-to/group-registration/full, /how-to/group-registration/lite and /how-to/group-registration/after-submission explain each step to groups</li>
</ul>
<h2>Registering a group</h2>
<p>The heading and introduction at the top of the registration form are ordinary page content at register#registration-intro, so it can be edited in place and given any row types, such as images or a carousel.</p>
<ol>
<li>Choose Lite or Full. Lite is email and membership tools with a small public site and does not read an existing website. Full is a complete website built from the pages the group chooses.</li>
<li>Choose the Ramblers area, then the group. Leave the group empty to register the area itself; an area site is built exactly like a group site. Group short names read as words, such as &quot;New Forest&quot;.</li>
<li>Enter a committee email address and follow the confirmation link. A private return link restores the saved answers. A plan can be chosen again on a verified draft.</li>
<li>For Full, enter the current website and click Find pages, then choose the pages (see below).</li>
<li>Check the summary and click Confirm and build site. The group can leave the page while the review site is built.</li>
</ol>
<h2>Choosing pages for a Full site</h2>
<ul>
<li>Find pages reads the current website into a tree with at most eight navbar sections, using the names common on NGX sites, with other top-level pages under Information</li>
<li>Pages found only on another page of the old site stay under that page, and a photo gallery page becomes Photos with its galleries under it</li>
<li>Tick, untick and reorder before Review, which lists only the ticked pages; clearing a section clears the pages under it, and a collapsed section stays collapsed while you work</li>
<li>An upcoming walks page is left to the Walks Manager walks page, and walks programme pages are not imported</li>
<li>Real pages with child pages keep their own content</li>
<li>A page moved under Walks or About Us takes its own sub-pages with it, so a registration cannot be refused for pages whose parent seems to be missing</li>
<li>While Find pages runs, the form shows the page it is reading and how many pages it has read and found so far, so a long search never looks stuck</li>
</ul>
<h2>What the import brings across</h2>
<ul>
<li>The words on each ticked page, keeping their meaning and tidied for spelling, grammar and old-site clutter; tidying long pages no longer cuts them short</li>
<li>Every imported page has a main heading, including the home page, which takes the group&#39;s name, with opening photos directly under it</li>
<li>Each page&#39;s photos become an album directly under its main heading; runs of photos become a gallery album, a linked Flickr group becomes an album on the page that linked to it, and two or more home page photos become a carousel</li>
<li>Gallery addresses are kept exactly as the old site wrote them, so each walk gallery imports its own photos</li>
<li>Documents and committee members found on the old site, with source committee chairs matched to the existing Chairman role</li>
<li>Full migrations keep every discovered page at its intended address and drop unused sample pages</li>
<li>Linked document pages are named after their link, and document links with brackets in their address are imported</li>
<li>The note saying which page of the old website a page came from is its own Migration note row, showing the label, a link to the old page and when it was imported; it is not page text, so index cards, search and the home page never pick it up</li>
<li>Migration Settings → Activity shows how many pages carry a migration note and removes them all in one go, for when the site goes live</li>
</ul>
<h2>The home page</h2>
<ul>
<li>One carousel of the old home page&#39;s photos, then the group name as the main heading and the introduction</li>
<li>A row of buttons to the main areas of the site, each with a title, a short description and a photo, built only from pages the import actually found, with the description taken from that page or its first sub-page</li>
<li>Buttons sit in balanced columns: four as two by two, five or six as three per row</li>
<li>The carousel is a fixed 400px high and does not show its album title</li>
<li>The migration note and any other photo albums are left off the home page</li>
</ul>
<h2>Photos by year and linked walks</h2>
<ul>
<li>Walk galleries sit at Photos → year → gallery, and the Photos page lists only the year pages, newest first, without a swiper</li>
<li>Each year page lists its albums on a map and as buttons, newest first</li>
<li>Year pages and the Photos index are built from the Self-service photos year and Self-service photos index migration templates in Content Templates, so their wording, map and layout are changed there; the build fills in the year, the page&#39;s own path and a map centred on the group or area, and stops straight away with a clear message if a template is missing</li>
<li>A gallery&#39;s date comes from its link where that carries a day, or from its title, where short month names such as Aug and Sept count</li>
<li>An album is linked to a Walks Manager walk on the same day, or in the same month when it shares a place name with the walk&#39;s title or meeting place and no other walk does as well; linked albums take the walk&#39;s location on the map</li>
<li>Galleries that cannot be linked are listed in the build log with the reason, such as no walks that month or two equally good matches</li>
<li>Every gallery&#39;s album is subtitled with what it is, such as &quot;Photos from our Olney walk on Sunday 23 August 2026&quot;, so its button on the year page has a real description; the page heading is not repeated with it</li>
<li>Galleries with only one or two photos become albums and are filed by year like the rest</li>
<li>Walks Manager history is loaded before the import, so the links are made on a first build</li>
<li>The old site&#39;s list of gallery links is not imported, and photos already collected into a page&#39;s album are not collected a second time</li>
</ul>
<h2>What is left out</h2>
<ul>
<li>Colours, fonts, the old layout, old menus and old addresses</li>
<li>Header, navigation and footer text repeated across pages, header images repeated on every page, and images too small to be photos</li>
<li>WordPress shortcodes, embedded frames, and links to domains that no longer exist</li>
<li>Links and images pointing back at the old site unless they were imported; lone links to the old home page and the old search label are removed</li>
<li>Dead links and missing images are kept or left out and logged rather than failing the build</li>
</ul>
<h2>Being gentle on the group&#39;s website</h2>
<ul>
<li>At most two requests at a time, slower when the site responds slowly, backing off and retrying when it struggles, and stopping with a clear message if it stops responding</li>
<li>Images and styles deliberately not fetched are not logged, and pages the old site no longer has are reported in plain words</li>
</ul>
<h2>Following a build</h2>
<ul>
<li>Each request in Site registrations shows a small stepper (email confirmed, submitted, site created, walks loaded, pages imported, ready for review, group invited) with a tick for done steps, a spinner on the running step, a cross on a failed one and the current step named underneath; each step names itself in a tooltip above it, and clicking the stepper changes nothing, so a retry shows at a glance which part is being redone</li>
<li>A request that has not been submitted yet can be sent a fresh confirmation and return link from Site registrations, so a group that has lost its link can carry on</li>
<li>A member administrator on the registration form gets an Open Site registrations button, and Site registrations has an Open the registration form button, so either page is one click from the other</li>
<li>A second import waits its turn on the integration worker, alongside uploads and exports, rather than being turned away; it can be stopped while it waits</li>
<li>Progress and Site registrations share one build log that collapses repeated lines and marks only genuine failures</li>
<li>Each registration keeps a history of every step with when it happened and who did it: the group&#39;s committee email, the administrator&#39;s name, or NGX for build steps; it sits under a collapsed History line below the build log with the time each step took, and a Build time column shows how long the latest build took or has taken so far</li>
<li>Hide build log closes a running build&#39;s log too</li>
<li>An error on any registration step is shown next to that step&#39;s buttons rather than at the top of the page</li>
<li>A page whose section is missing from the list is named in the error, with what to do: click Find pages again or move it under another section</li>
<li>Site registrations says it is loading rather than showing an empty list while the requests are fetched</li>
<li>Progress messages, the current step and the page tree stay steady while a build is followed; only the newest progress line spins</li>
<li>A reviewer can stop a queued or running build; the running job notices at its next stage and the worker cancels the import at its next step</li>
<li>A failed import can be retried, and retries use the current import rules rather than those saved at submission</li>
<li>A rebuild replaces the pages and albums an earlier import made</li>
<li>A build that stops because its process restarted is released within five minutes, and a failure names the stage</li>
<li>A group secretary sees a short plain message if a build fails; full detail stays with the reviewer</li>
<li>Destroying a review site, including one with skipped steps, removes the leftover request so the group can start again</li>
<li>Destroying an environment asks for its name to be typed before the Destroy Environment button works, and also deletes the site&#39;s own MongoDB Atlas database user; a shared user is kept</li>
<li>System Logins in Platform Configuration Values has the same Show secret values switch as the inventory, showing every password on the tab at once</li>
<li>The build log ends each stage with a line saying it is finished, such as &quot;Pages imported: this stage is finished&quot;</li>
<li>Retry starts with a clean build log, and What went wrong only shows for a failed or broken request</li>
<li>The group sees the same stepper at the top of the Progress step of the registration form; the build log detail and history stay with the reviewer</li>
<li>The stepper names each step by what is happening: Waiting to create the site, Creating the site, Importing pages, Waiting for approval, and so on; a failure reads Failed while importing pages</li>
<li>Buttons on kept pages that pointed at sample pages the build removed, such as Walks Information on the Walks page, are taken away with them</li>
</ul>
<h2>Reviewing and approving</h2>
<ul>
<li><p>Run import again on a request still in review rebuilds its content without recreating the environment</p>
</li>
<li><p>The reviewer is emailed when the review site is ready, and registration emails show the site banner from the public address</p>
</li>
<li><p>Approving sends the committee email an invitation with a link to the new site and a link to set a password</p>
</li>
<li><p>Sites still being prepared are skipped by deploy-all until the registration is approved, then included like any other site</p>
</li>
</ul>
<h2>Approved committee emails</h2>
<ul>
<li>Approved addresses are chosen by area and group, and each person&#39;s name is kept with their address</li>
<li>The list shows the area and group on one line each and the approved people as a comma-separated list of names; addresses appear only when editing</li>
<li>Leaving the group empty approves people for the area&#39;s own site, shown as Whole area</li>
<li>Save approval adds a new group or area and Save changes updates one being edited, each saved straight away, with Cancel to clear the form; removing an approval saves straight away too</li>
<li>An address that is not a valid email is reported against its group</li>
</ul>
<h2>New-group safety</h2>
<ul>
<li><p>Each new site&#39;s database user is created through MongoDB Atlas; the API key goes in Environment management → Global settings → MongoDB Atlas and is listed under Shared MongoDB Atlas in Platform Configuration Values, and System logins → MongoDB Atlas gains an API keys button that opens the project&#39;s API access page</p>
</li>
<li><p>A build failure never shows a generated password</p>
</li>
<li><p>Public registration stays off until Walks Manager, MongoDB and Fly credentials are filled in</p>
</li>
<li><p>Each registration gets its own MongoDB user that can only read and write that group&#39;s database</p>
</li>
<li><p>A new site starts with no Brevo key of its own rather than the platform&#39;s, so nothing is sent or registered on the platform&#39;s Brevo account</p>
</li>
<li><p>A new site starts on the standard 512mb machine with one instance</p>
</li>
<li><p>A new site&#39;s member sync policy starts with Head office member records always applied</p>
</li>
</ul>
<h2>Email Configurations</h2>
<ul>
<li>A configuration with no template used to show an error that could not be fixed; Email content now offers a template, Written here, or Written in the Email Composer</li>
<li>Fully Automated Text Body and Member Sync Notification are not offered as wording to start from, because they are built-in processes</li>
<li>The Email Configuration selector grows to use the space beside Compose email, which always stays on the same line</li>
</ul>
<h2>Migration Settings</h2>
<ul>
<li>Content sections, Import rules and Activity are tabs, with the old website named above them</li>
<li>Content sections are a tree with a one-line summary each, divided from the section being edited by a draggable splitter whose width is remembered</li>
<li>Filtering a long list opens the branches that match, and choosing a section opens it in the list as well as beside it</li>
<li>Content sections come from the pages chosen at registration, so they cannot be added by hand; deleting one updates the list straight away</li>
<li>A migration note&#39;s date format is chosen from examples rather than typed</li>
<li>Migrations are run by a registration build, so Migration Settings only shows and amends the settings; the activity log is sortable</li>
</ul>
<h2>Logo and banner</h2>
<ul>
<li>A new environment takes its group&#39;s Ramblers logo while it is being set up</li>
<li>It gets a banner made from that logo in the same style and size as existing groups&#39; banners: 2232 by 558, the logo centred on white inside a 20px dark border</li>
<li>Every email configuration is created pointing at that banner</li>
</ul>
<h2>Maps keys</h2>
<ul>
<li>A registration build generates the site&#39;s OS Maps key through the integration worker, which signs in to the OS Data Hub with the login held in platform System Logins; it reuses a project and key that already exist, and the build log says whether the key was found or generated</li>
<li>A group&#39;s own settings never receive the platform&#39;s OS Data Hub sign-in details</li>
</ul>
<h2>Also in this change</h2>
<ul>
<li>Site registrations and every sortable table read well on a phone</li>
<li>Switches look like switches, a task running every minute says so, and registration buttons stay disabled while an action is running</li>
<li>Anonymous visitors to Walks Manager sites no longer trigger a leader contacts request that needs a login</li>
<li>A dropped database connection while loading Walks Manager is retried</li>
<li>A review subdomain whose DNS still points at an earlier app is corrected, so its certificate can issue</li>
<li>Long words no longer widen a sliding index card</li>
<li>A saved clean-up step whose nested row had no column no longer stops the Migration Settings screen redrawing</li>
<li>The in-progress banner is a success alert, and action buttons sit on a gap row so a single button is not inset</li>
<li>Content Templates loads only the fragments it lists, so it opens quickly on a large site, says so if loading fails, clears the search from the address when the filter is cleared, and uses shared-fragment, user-template and migration-template as its view values</li>
<li>Scheduled Tasks filters by Walks and events, Inbox, Brevo, Platform and All, with every task in a group; Site registrations and backups sit under Platform</li>
<li>Admin alert emails use the standard recipient field, so each alert recipient can have a name</li>
<li>System Settings tabs use their full names and flow across two even rows</li>
<li>Editing a recipient&#39;s name keeps exactly what was typed, capitals included, and the cursor stays put</li>
<li>Registration action buttons sit in an even grid, and tooltips across the site now attach to the page body by default, so hovering a button can no longer reshuffle the buttons around it</li>
</ul>
<h2>How to try it out</h2>
<p>Turn public registration on in Site registrations, open /register in a private window, and register a test group as Full. Follow the build from Site registrations, open the review site when it is ready, check its logo, banner, home page and photos by year, and the build log for which galleries were linked to walks, then approve or destroy it.</p>