Skip to content

fix(editor): make page slug editable via a new Page settings dialog#220

Open
gxvr wants to merge 4 commits into
CoreBunch:mainfrom
gxvr:fix/page-slug-settings-ui
Open

fix(editor): make page slug editable via a new Page settings dialog#220
gxvr wants to merge 4 commits into
CoreBunch:mainfrom
gxvr:fix/page-slug-settings-ui

Conversation

@gxvr

@gxvr gxvr commented Jul 14, 2026

Copy link
Copy Markdown

A page's slug could only be set at creation time — the site explorer's inline rename only ever updates the title (renamePage(id, title) with no third arg leaves the slug untouched), and there was no other slug editor for a regular (non-template) page. The Data tab correctly locks slug as an editor-managed built-in field, but the editor had nowhere to actually manage it.

Add a "Page settings" context-menu item (regular pages only - template pages already get title+slug through the existing Template settings dialog) that opens a small Title + Slug form, reusing the same slug validation helpers as TemplateSettingsDialog. The homepage's slug field is disabled since "index" is a reserved sentinel, not a freely editable value.

Extracted the Template/Page settings dialog state and handlers into a usePageSettingsDialogs hook — adding the new dialog inline pushed SiteExplorerPanel.tsx over the 700-line module-size-budgets ceiling.

Summary

Describe the change and why it is needed.

Verification

  • bun run build
  • bun test
  • bun run lint
  • Docker/deployment check, if relevant

Checklist

  • Tests cover behavior changes.
  • Docs were updated when behavior, config, deployment, or public surfaces changed.
  • No compatibility shim was added for old pre-release behavior.
  • No secrets, local databases, uploads, or generated artifacts are included.

gxvr and others added 4 commits July 14, 2026 14:54
A page's slug could only be set at creation time — the site explorer's
inline rename only ever updates the title (renamePage(id, title) with
no third arg leaves the slug untouched), and there was no other slug
editor for a regular (non-template) page. The Data tab correctly locks
slug as an editor-managed built-in field, but the editor had nowhere
to actually manage it.

Add a "Page settings" context-menu item (regular pages only — template
pages already get title+slug through the existing Template settings
dialog) that opens a small Title + Slug form, reusing the same slug
validation helpers as TemplateSettingsDialog. The homepage's slug
field is disabled since "index" is a reserved sentinel, not a freely
editable value.

Extracted the Template/Page settings dialog state and handlers into a
usePageSettingsDialogs hook — adding the new dialog inline pushed
SiteExplorerPanel.tsx over the 700-line module-size-budgets ceiling.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…elds

Pages, Components, and Layouts start out with every field marked
built-in and value-locked (isBuiltInValueLocked), so a generic
"Add row" or "Duplicate row" through the Data tab has nothing it can
actually fill in — buildEmptyCells and buildDuplicateRowCells always
include the locked field keys, and the server's lockedBuiltInCellKey
guard rejects the request every time. The UI offered both actions
unconditionally, so clicking them silently did nothing beyond a
console.error, making the whole table look broken/read-only.

Add tableHasEditableFields(table) to systemTableGuard.ts (true when at
least one field isn't value-locked) and use it in DataCanvas to hide
both affordances for tables where every field is locked. As defense
in depth, also surface handleAddRow / handleDuplicateRow failures via
the toast bus instead of console.error-only, matching this project's
error-handling convention for user-triggered operations.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix(data): hide Add row / Duplicate row on tables with no editable fi…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant