Reorderable content settings sections in the editor

[logelog]

Problem

The content editor's right panel has a growing set of contextual sections such as Publish, Ownership, Bylines, Translations, Taxonomies, SEO, Outline, and Revisions. Their order is currently fixed, although different editorial workflows depend on different sections.

While working with contextual plugin UI, I needed this area to behave more like a dynamic workspace. If plugins later contribute or replace contextual panels, the information an editor uses most should remain easy to reach instead of being locked below unrelated core sections.

Proposal

Allow editors to reorder the built-in content settings sections with a dedicated drag handle.

• Support pointer and keyboard sorting.
• Constrain movement to the vertical axis and the width of the settings panel.
• Keep the disclosure control separate from the drag handle.
• Temporarily collapse section bodies while sorting so long panels are easier to move.
• Persist the preference in browser storage per user and collection.
• Reuse the saved order across entries in that collection. An editor can arrange the panel once and get the same layout on the next post or page they open.
• Preserve EmDash's default order for users without a saved preference.
• Reconcile saved layouts safely when sections are added or removed in a later version.
• Keep the mobile settings sheet usable, including keyboard cancellation.
• Keep destructive footer actions outside the sortable section list and visually out of the way during an active sort.

This is a personal interface preference only. It does not change content, schema, or the order seen by other users.

Plugin direction

This proposal does not add a plugin panel API. It only makes the host-owned settings area reorderable.

The motivation is partly to prepare the editor for a more dynamic plugin ecosystem. If EmDash later allows trusted plugins to contribute contextual panels, those panels could participate in the same host-managed ordering system. Editors would then be able to place plugin-provided data alongside the core information they need most, without each plugin owning layout or persistence.

Scope

This is intentionally narrower than #2105:

• no content-list extension contract;
• no named replacement slots;
• no plugin rendering API;
• no server-side preference storage.

A future proposal can decide how contributed plugin panels join the layout. The current slice is independently useful for the built-in editor sections.

Prototype and validation

I have a working prototype on current EmDash 0.30 behavior. It has been exercised with:

• pointer and keyboard reordering;
• saved-order restoration across entries;
• malformed and stale browser preferences;
• desktop and mobile settings layouts;
• light and dark themes;
• full admin browser tests, type checking, linting, formatting, and production build.

Questions

1. Does a per-user, per-collection browser preference feel like the right initial persistence scope?
2. Should future plugin-contributed panels automatically participate in this order, or should plugins opt in?
3. Would a reset-to-default action be useful in the first version, or can it follow later?