Manual (drag) ordering for content entries: six things reorder in the admin, entries are not one of them

[marks-zyz]

Description

Six things in the admin can be reordered by dragging. Content entries are not one of them, and there is no API for it either.

Present today:

Reorder endpoint	What it orders
POST /api/menus/:name/reorder	menu items
POST /api/widget-areas/:name/reorder	widgets
POST /api/taxonomies/:name/reorder	terms
POST /api/admin/byline-fields/reorder	byline fields
POST /api/schema/collections/reorder	collections in the sidebar
POST /api/schema/collections/:slug/fields/reorder	fields in a form

Absent: any equivalent for the rows of a collection. ContentList.tsx has no DndContext (the admin uses dnd-kit in eight other components, including ContentTypeList), and the list can only be sorted by a closed set of columns — ORDER_FIELD_COLUMNS in packages/core/src/database/repositories/content.ts is createdAt, updatedAt, publishedAt, scheduledAt, deletedAt, title, name, slug, status, locale, plus the collection's title_field and date_field. None of those is a position.

So a Content Types screen can be dragged into the order the editor wants, and the entries inside those types cannot.

Why this matters outside of blogs

For a date-ordered blog, publishedAt is the right order and nothing is missing. The gap shows up in curated collections, where the order is content: practice areas on a homepage, "how it works" steps, service tiers, featured items, team members, FAQ entries. Those are collections in the CMS sense — same editor, same revisions, same taxonomy — but their sequence is an editorial decision, not a timestamp.

The workaround today is to add a numeric field (sort_order) to every such collection and have the editor type numbers. In practice this costs:

• a field per collection, duplicated by hand in each site's schema;
• renumbering: inserting one item in the middle means editing every item after it;
• invisibility: the number is inside each entry, so the list does not show the running order unless you sort by that field and know that is what it means;
• no feedback: you cannot see the result until you leave the entry and reload the list.

A client who has used WordPress with any page-ordering plugin expects to drag. Explaining "type 30 here, and now edit the other four" is where the CMS stops feeling finished.

Proposal

Follow the shape that already exists for terms, so this is mostly assembly rather than invention.

1. Opt-in per collection. A collection declares manual ordering (manualOrder: true, or defaultOrder: "manual" alongside the existing sortOrder that positions collections in the sidebar). Collections that do not declare it behave exactly as today — no column, no handle, no cost.

2. Storage. One nullable column on the ec_* table for the position. A float (or a lexorank-style string) rather than a dense integer, so inserting between two neighbours writes one row instead of renumbering the tail. Null means "never positioned", which sorts last.

3. API, mirroring reorderTermsBody. POST /api/content/:collection/reorder with { ids: string[] }, where the listed ids are permuted within the positions they already occupy and everything else keeps its place, and an id outside the set is rejected with REORDER_MISMATCH. That subset semantics is exactly what makes the taxonomy endpoint safe under pagination, and it is the same problem here.

4. UI. DndContext in ContentList, with the handle rendered only when the collection is manually ordered and the list is currently sorted by position with no active search or filter. Dragging row 3 while the list is filtered by status and sorted by title has no defensible meaning; the honest move is to hide the handle and say why, the way the drag handle disappears in other filtered lists.

5. Locale. Terms deliberately hold one position across locales. Content is different — a translation is its own row — so position is probably per locale. Worth deciding explicitly rather than inheriting the taxonomy answer by accident.

6. Public read path. orderBy: "position" accepted in the content API and in the plugin/MCP reads, so a site template can ask for the editor's order without knowing the storage detail.

Alternatives considered

• Keep telling people to add a sort_order field. Works, and is what everyone does now, but it is a per-site reinvention of a core concern, and the renumbering cost is real for a non-technical editor.
• Sort by updatedAt and let people re-save to reorder. Destroys real metadata to encode order. Mentioned only to reject it.

Prior art

WordPress ships menu_order on every post type and the whole plugin ecosystem for page ordering exists on top of it. Sanity, Contentful and Strapi all offer manual ordering per collection with drag in the list view. The expectation is well established; the EmDash admin already has every ingredient (dnd-kit, a reorder request shape, a per-collection settings surface) — what is missing is the column, one endpoint and the handle.

Happy to open a Discussion first if this needs a design decision before code, and happy to implement it.

[emdashbot[bot]]

Completed

Manual (drag) ordering for content entries: six things reorder in the admin, entries are not one of them

• Review the issue and relevant repository context

Outcome: Confirmed: the repository already has six drag-to-reorder admin flows (menus, widget-areas, taxonomies, byline-fields, sidebar collections, field rows), but there is no equivalent for content entries. `packages/admin/src/components/ContentList.tsx` currently has no `DndContext`, and the content repository's orderable columns are limited to system fields plus the configured title/date field, with no position support.

This is a substantial cross-stack feature, not a localized fix. Implementing it would need, at minimum:

• a new collection-level opt-in setting (`manualOrder` or `defaultOrder: "manual"`);
• a database migration that adds a position column to every `ec_*` content table and updates `SchemaRegistry` for new tables;
• query support in the content repository for ordering by that column;
• a new `POST /api/content/:collection/reorder` endpoint plus handler and RBAC permission;
• `DndContext`/sortable integration in `ContentList`, gated so handles only appear when the list is sorted by position with no active search or filter;
• public read support (`orderBy: "position"` in content API and plugin helpers);
• localization, tests, documentation, and a changeset.

Several design decisions need maintainer input before coding: the exact opt-in API, storage type (float vs lexorank), whether ordering is per-locale or per-translation-group, how to backfill/initialize positions safely, and the interaction with pagination, locale switching, and filtered views.

This should go through a design Discussion or maintainer approval before implementation; it is not appropriate for bounded auto-work.

Mode: triage

View live dashboard · Run: 671a8055-498f-4481-ac10-4f28744b694f

[rob-j-oliver]

Whilst a separate PR/feature, are Hierarchical pages/CPT on the horizon for EmDash? Not having (opt-in) hierarchical structures for content types is a blocker for me migrating WP sites over, as well as administering. WP has this option when configuring a CPT, and shows a 'Parent page' UI for the backend when enabled for CPT entries. I'm specifically mentioning this here as 'drag and drop' for hierarchical CPTs in WP is something I use a lot and I would imagine so do a lot of administrators/editors.

[MA2153]

I have converted this to a discussion as it is a feature request.