{"id":"6a0b1eaf3534181e53490b5d","title":"2026 05 18 Issue 217","path":"how-to/committee/release-notes/2026-05-18-issue-217","contentMarkdown":"# 18-May-2026 — safer environment settings and more reliable contributor bundles [ref #217](https://github.com/nbarrett/ngx-ramblers/issues/217)\n\n## [build 648](https://github.com/nbarrett/ngx-ramblers/actions/runs/26038096516) — [commit 1cd138a](https://github.com/nbarrett/ngx-ramblers/commit/1cd138a5beec9df7ce4d3d3efec8832fc2cc22dd)\n\n_____\n\nThis release fixes two problems in the platform administration tools.\n\nThe first problem was that saving the environment settings page could accidentally lose hidden configuration values. The form showed the main settings correctly, but when it saved them back it rebuilt the configuration too narrowly. Some fields that were not visible on the form could be dropped. One of those fields is used by the deployment pipeline, so losing it could break the next build.\n\nThat has now been fixed. Saving environment settings now preserves the whole existing configuration and only changes the fields the form is meant to edit.\n\n## Contributor environment generation\n\nThe second fix is for the **Contributor Environment** tool.\n\nThis tool lets a site admin create a downloadable development bundle for a group. The bundle gives a contributor, developer, or coding assistant a realistic local environment to work in, with live reload and group-specific data, without giving them access to the central staging configuration.\n\nThat matters because it lowers the barrier to making useful changes to NGX. Someone can ask for help building or testing a feature in a real group context without first understanding every part of the NGX stack.\n\n## What changed\n\n- The **Generate** button now works when the contributor will use the current database.\n- A separate database name is still required when cloning the database, because the tool needs to know where to create the copy.\n- The generator can now work from ordinary group environments, not only from the central admin environment.\n- If something goes wrong, the page now shows the real reason instead of a generic failure message.\n- If a requested cloned database already exists, the page warns before trying to create it.\n\n## Why this matters\n\nBefore this fix, the contributor bundle flow could get stuck before it started, or fail with a message that did not explain what to do next. That made the feature feel unreliable just when someone was trying to set up help.\n\nAfter this fix, a site admin can generate a contributor bundle more confidently, and the person receiving it can get to the useful part faster: making changes in a live-reloadable NGX environment that behaves like the group site they are working on.","contentHtml":"<h1>18-May-2026 — safer environment settings and more reliable contributor bundles <a href=\"https://github.com/nbarrett/ngx-ramblers/issues/217\">ref #217</a></h1>\n<h2><a href=\"https://github.com/nbarrett/ngx-ramblers/actions/runs/26038096516\">build 648</a> — <a href=\"https://github.com/nbarrett/ngx-ramblers/commit/1cd138a5beec9df7ce4d3d3efec8832fc2cc22dd\">commit 1cd138a</a></h2>\n<hr>\n<p>This release fixes two problems in the platform administration tools.</p>\n<p>The first problem was that saving the environment settings page could accidentally lose hidden configuration values. The form showed the main settings correctly, but when it saved them back it rebuilt the configuration too narrowly. Some fields that were not visible on the form could be dropped. One of those fields is used by the deployment pipeline, so losing it could break the next build.</p>\n<p>That has now been fixed. Saving environment settings now preserves the whole existing configuration and only changes the fields the form is meant to edit.</p>\n<h2>Contributor environment generation</h2>\n<p>The second fix is for the <strong>Contributor Environment</strong> tool.</p>\n<p>This tool lets a site admin create a downloadable development bundle for a group. The bundle gives a contributor, developer, or coding assistant a realistic local environment to work in, with live reload and group-specific data, without giving them access to the central staging configuration.</p>\n<p>That matters because it lowers the barrier to making useful changes to NGX. Someone can ask for help building or testing a feature in a real group context without first understanding every part of the NGX stack.</p>\n<h2>What changed</h2>\n<ul>\n<li>The <strong>Generate</strong> button now works when the contributor will use the current database.</li>\n<li>A separate database name is still required when cloning the database, because the tool needs to know where to create the copy.</li>\n<li>The generator can now work from ordinary group environments, not only from the central admin environment.</li>\n<li>If something goes wrong, the page now shows the real reason instead of a generic failure message.</li>\n<li>If a requested cloned database already exists, the page warns before trying to create it.</li>\n</ul>\n<h2>Why this matters</h2>\n<p>Before this fix, the contributor bundle flow could get stuck before it started, or fail with a message that did not explain what to do next. That made the feature feel unreliable just when someone was trying to set up help.</p>\n<p>After this fix, a site admin can generate a contributor bundle more confidently, and the person receiving it can get to the useful part faster: making changes in a live-reloadable NGX environment that behaves like the group site they are working on.</p>\n"}