emDash 1.2 landed on October 7, five days after 1.1, and it is the most significant release since launch — by emDash's own count, 100 merged pull requests from 21 community contributors plus the core team. The work concentrates in the admin, and read strategically, 1.2 addresses the single most common reason a WordPress user gives for not moving: that the editing experience is not yet good enough to live in every day. Removing that objection lowers the real switching cost of adopting the platform, which is why this release matters more than its version number suggests.
The editor redesign: a switching-cost reduction, not a cosmetic one
The content editor has been rebuilt to behave like a document rather than a form. Title and body now flow together; hovering a block exposes insert and drag controls with a menu to transform, duplicate, move or delete it; the slash menu is grouped and surfaces each block's Markdown shortcut; and the formatting toolbar stays in view while you scroll, with a compact toolbar on text selection.
The feature description undersells the commercial point. For an organisation, the editing experience is a training cost and a daily-friction cost multiplied across every person who touches content and every post they produce. A WordPress team evaluating a move prices in the retraining and the productivity dip, and "the editor feels immature" is a rational reason to defer. By bringing the authoring experience up to the standard those teams expect, 1.2 reduces the adoption friction that was suppressing serious evaluation. It was built by a community contributor.
Native video: one fewer third-party dependency
Editors can now place video directly in rich text (/video, or drop and paste), rendered on the public site with the browser's native player. The operationally meaningful detail sits underneath: the media route now answers HTTP range requests with partial-content responses, so video plays correctly in Safari and on iOS — the failure mode that makes self-hosted video look broken. The default upload ceiling is 50 MiB. For sites that would otherwise reach for a third-party video host for simple clips, this removes a dependency and the cost and data-governance questions that come with it.
The domain-move flow: de-risking a specific, expensive event
1.2 adds a full domain-move workflow in Settings. Changing a domain propagates the new address through email and plugin links, sitemaps, robots.txt, hreflang, social-image URLs and canonical links, and verifies that the new domain actually serves the site before switching. Because passkeys are bound to the address where they were created, two helpers keep people signed in through the move: a single-use sign-in link that expires after five minutes, and an action that emails other users the new location.
This is narrow and valuable. A rebrand or domain migration is a discrete, high-consequence event where small oversights — a stale canonical, a broken email link, a locked-out administrator — turn into SEO loss and support cost. Converting that from a manual checklist into a verified, guided flow materially lowers the operational risk of an event that agencies in particular perform on behalf of clients.
upgrade-emdash: lowering the recurring cost of staying current
The release introduces npx upgrade-emdash@latest, a standalone command that resolves and updates every emDash dependency, preserves each package's version-pinning style, runs your package manager, and refreshes the project's agent skills, restoring the files it changed if any step fails. It then writes .emdash/UPGRADE.md — a work order containing the authored changelog entries between your installed and target versions and a comparison of database migrations, flagging where an upgrade requires a build, a recovery point and migration review before deployment. It does not edit application code, apply migrations, or deploy.
This is the most quietly strategic item in the release. On a platform shipping roughly monthly, the recurring cost and risk of staying current is a genuine line in the total cost of ownership. A machine-readable, per-site upgrade work order — explicitly designed to be handed to a developer or a coding agent — turns an open-ended upgrade task into a scoped, reviewable one. It is also a concrete expression of the agent-native thesis: the platform is producing structured instructions for the tools that increasingly do the work.
Also material
Numbered pagination across admin lists means collections open with 20 entries rather than fetching 100, which keeps the admin responsive on large sites. The admin's German, Catalan and Traditional Chinese translations are now complete, with European Portuguese added as a new locale — relevant to any multi-market operation. And a set of Cloudflare Workers fixes address real operational footguns: background writes now complete via waitUntil rather than being cut off when the response returns, every-minute cron no longer exceeds the free-tier CPU limit on cold starts, and bulk category and tag assignments no longer fail on D1.
The recommendation, by where you sit
- Running emDash.
upgrade-emdashis now the recommended path; run it against a staging copy and read the work order before deploying. This release introduces no schema migrations, which makes it a low-risk update to schedule. - Evaluating emDash. If your decision to wait rested on the authoring experience, 1.2 is the release that warrants a re-evaluation. The editor was the most defensible reason to defer, and it is the reason this release weakens most. How the platform now compares head-to-head with WordPress is the subject of a comparison we are preparing.
