fix(admin): sync TermFormDialog state on term change; add back button to Security & AllowedDomains settings#259
Conversation
Agent-Logs-Url: https://github.com/pangerlkr/emdash/sessions/0b446ce9-176a-438b-84b2-b1d5d147f717 Co-authored-by: pangerlkr <73515951+pangerlkr@users.noreply.github.com>
…ton to SecuritySettings/AllowedDomainsSettings Fixes emdash-cms#220: TermFormDialog used useState with initial props but never synced when the `term` prop changed (switching between different terms). Added a useEffect to reset all form fields whenever the term prop changes. Fixes emdash-cms#256: SecuritySettings and AllowedDomainsSettings pages were missing the back arrow button in their page headers, unlike all other settings pages. Added a back-to-settings link with ArrowLeft icon to the main return JSX header of both components, consistent with how other settings pages handle it.
|
|
I have read the CLA Document and I hereby sign the CLA 1 out of 2 committers have signed the CLA. |
There was a problem hiding this comment.
Pull request overview
Fixes two admin-panel UX/state bugs and adds a new PRD document to the repo.
Changes:
- Sync
TermFormDialoglocal form state when thetermprop changes to avoid stale values when editing multiple terms. - Add an in-header “back to settings” button on the Security and Self‑Signup Domains settings pages.
- Add
PRD.mddescribing EmDash product requirements and architecture.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| PRD.md | Adds a comprehensive Product Requirements Document (new documentation artifact). |
| packages/admin/src/components/TaxonomyManager.tsx | Resets term-edit form state via useEffect when switching the edited term. |
| packages/admin/src/components/settings/SecuritySettings.tsx | Adds a header back-navigation button to /settings. |
| packages/admin/src/components/settings/AllowedDomainsSettings.tsx | Adds a header back-navigation button to /settings. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <div className="flex items-center gap-3"> | ||
| <Link to="/settings"> | ||
| <Button variant="ghost" shape="square" size="sm" aria-label="Back to Settings"> | ||
| <ArrowLeft className="h-4 w-4" /> | ||
| </Button> | ||
| </Link> | ||
| <h1 className="text-2xl font-bold">Security Settings</h1> | ||
| </div> |
There was a problem hiding this comment.
The new back button is only rendered in the main (non-loading / non-error) return path. In the loading and error early-returns, the header is still just an
with no back navigation, which reintroduces the same usability issue in those states. Consider extracting a shared header component/JSX and using it in all return branches (loading, external-auth info, error, and success) so navigation stays consistent.
| <div className="flex items-center gap-3"> | ||
| <Link to="/settings"> | ||
| <Button variant="ghost" shape="square" size="sm" aria-label="Back to Settings"> | ||
| <ArrowLeft className="h-4 w-4" /> | ||
| </Button> | ||
| </Link> | ||
| <h1 className="text-2xl font-bold">Self-Signup Domains</h1> | ||
| </div> |
There was a problem hiding this comment.
The back button is only present in the final render branch. The loading and error early-returns still render only an
(no back navigation), so users can still get stuck without an in-page way to return to /settings in those states. Consider reusing the same header JSX across all branches (loading, external-auth info, error, success).
PRD.md
Outdated
| # EmDash — Product Requirements Document | ||
|
|
||
| ## 1. Executive Summary | ||
|
|
||
| EmDash is a full-stack TypeScript CMS built on Astro and designed to run on Cloudflare or Node.js. It provides the familiar content-management capabilities of WordPress—posts, pages, media, taxonomies, menus, plugins, users—reimplemented with a modern, type-safe, serverless-first architecture. The product stores its schema in the database rather than in code, runs plugins in isolated Worker sandboxes, and ships with a built-in MCP server so AI agents can interact with site content natively. | ||
|
|
||
| --- | ||
|
|
There was a problem hiding this comment.
This PR adds a large new PRD document, but the PR title/description describe only two small admin UI bug fixes. Either update the PR description to include the PRD addition and rationale, or split the PRD.md change into a separate PR to keep review scope focused.
|
Note: Fix 1 ( |
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/blocks
@emdash-cms/cloudflare
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
Overlapping PRsThis PR modifies files that are also changed by other open PRs:
This may cause merge conflicts or duplicated work. A maintainer will coordinate. |
|
Could not push formatting changes to this fork. The contributor may have "Allow edits by maintainers" disabled. Please run the formatter locally: |
|
I have read the CLA Document and I hereby sign the CLA |
|
I noticed there are related issues and PRs in this repository that overlap with the fixes in this PR. This PR addresses stale state in |
|
Could not push formatting changes to this fork. The contributor may have "Allow edits by maintainers" disabled. Please run the formatter locally: |
|
recheck |
Workflow Status & CLA Fix Notes✅ Resolved
|
|
recheck |
Summary
This PR contains two independent bug fixes for the admin panel.
Fix 1:
TermFormDialogstale state when editing different termsProblem:
TermFormDialoginitialized all form fields withuseState(term?.label || "")etc. — but React'suseStateonly runs once on mount. When thetermprop changed (e.g., clicking Edit on a second taxonomy term), the dialog would show the stale data from the first term.Fix: Added a
useEffectthat watches thetermprop and resets all form fields (label,slug,parentId,description,autoSlug,error) whenever it changes.Fix 2: Missing back button on Security Settings & Self-Signup Domains settings pages
Problem:
SecuritySettingsandAllowedDomainsSettingshad no back navigation in their page header, unlike other settings sub-pages (e.g.GeneralSettings). Users had to use the browser back button or sidebar to return to the main settings list.Fix: Added an
ArrowLefticon button linking to/settingsin the page<h1>header row of both components, consistent with the pattern used across the rest of the settings pages.Files Changed
packages/admin/src/components/TaxonomyManager.tsx— adduseEffectto sync form statepackages/admin/src/components/settings/SecuritySettings.tsx— add back button to page headerpackages/admin/src/components/settings/AllowedDomainsSettings.tsx— add back button to page header