emDash 1.3 arrived on October 15, eight days after 1.2, carrying 87 changes from 16 community contributors and the core team. Where 1.2 addressed authoring experience, 1.3 addresses the concerns that surface once a platform is actually in production use by more than one person: accountability over who changed what, control over how your content is used, and the page-speed economics that govern search and conversion. These are governance and value questions, and they are the ones that distinguish a tool from a platform an organisation can standardise on.
Readable revision history: an auditability gain
emDash has always retained version history with one-click restore. The limitation was presentational — the revisions panel rendered changes as raw JSON and did not attribute them, which made it a developer's recovery tool rather than an editorial one. 1.3 reworks it: selecting a version opens it read-only in the editor with added text highlighted and removed text struck through, colour-coded per contributor, and the panel names who saved each version and summarises the change in plain language. Restoration is a single action, and unsaved work is preserved while you review.
The business value is governance, not nostalgia. "Who changed this page, when, and what exactly did they change" is a question that arises in every multi-contributor environment and a requirement in regulated or brand-sensitive ones. Making revision history legible to editors — and exposing each revision's author through the API and MCP tools, including to editors without user-management access — converts an opaque data structure into an accountability record an organisation can actually rely on. For teams, that is a real reduction in the cost of coordination disputes and content errors.
Content-rights control: a strategic decision, not a toggle
Settings now carries a "Disallow AI training" switch. Enabled, it adds the major AI-training crawlers — among them GPTBot, ClaudeBot, Google-Extended, CCBot, Bytespider and Applebot-Extended — to robots.txt, together with a Content-Signal: search=yes, ai-train=no directive. Search-engine indexing is unaffected, so the setting lets a publisher preserve search visibility while asking AI systems not to train on their content.
Two honest qualifications belong on this: it is off by default, so nothing changes until you choose, and, like all robots.txt directives, it is a request rather than an enforcement mechanism — compliant crawlers honour it, others may not. With those caveats stated, the feature reframes a question most owners have not formally decided: whether their content is a strategic asset they wish to withhold from model training. emDash turns that from a config-file edit into a governed, one-switch stance. For any business whose content is its differentiation, it is worth treating as a deliberate decision rather than a default.
Page speed, and the mechanism behind it
1.3 delivers a performance gain for logged-out visitors on Cloudflare D1. The mechanism is worth understanding because it explains who benefits: a D1 session executes a request's queries one at a time, so on sites that use D1 sessions without query coalescing, emDash's practice of preloading settings, menus and taxonomy terms up front was serialised ahead of the page's own first query. Those sites now skip the preload and run those queries only when a page uses them. Sites that enable coalescing keep the preload, because there reads issued together share a single round trip, and new sites created from the Cloudflare templates now turn on both sessions and coalescing by default. Existing sites opt in through their configuration.
A tested note from our own site, which runs on Cloudflare D1: on emDash 1.2 we measured sessions with coalescing against the default configuration and saw no reliable difference in render time, and a preview test surfaced a write-then-read visibility problem, so we have kept sessions off for now. Measure on your own site before you switch them on.
The outcome is the one that matters commercially: faster pages for anonymous visitors, which is to say for most of your search traffic. Page speed is a ranking input and a conversion input, so a latency reduction on logged-out requests is a direct contribution to both acquisition and revenue, not merely a developer nicety. Supporting cache changes compound it — creating a draft no longer purges cached pages unnecessarily, and a new or changed redirect now takes effect even for pages already held in the Workers cache.
Migration tooling, quietly closing the gap
A cluster of WordPress-import improvements continues to erode the "the migration tooling isn't there yet" objection that has reasonably held back serious switchers. Links to the old domain now convert to clean root-relative paths that preserve the original permalink structure — directly protecting SEO equity, the thing most at risk in any migration. Advanced Custom Fields values now carry across, and when Cloudflare's bot challenge blocks the importer, it now says so and explains how to let it through instead of failing silently. For agencies that price migrations, each of these reduces the manual remediation that makes migration quotes expensive and unpredictable.
Also in the release: contributors can finally edit their own drafts — previously blocked by a permissions defect — and the admin added Croatian and completed Polish, French and German.
| Release | Shipped | Days after the previous | Focus |
|---|---|---|---|
| 1.0 | September 28 | — | First production release; a semantic-versioning commitment |
| 1.1 | October 2 | 4 | Publishing calendar, isolated code blocks, reliability |
| 1.2 | October 7 | 5 | Editor redesign, native video, domain moves (21 community contributors) |
| 1.3 | October 15 | 8 | Revision history, AI-training control, faster pages (16 community contributors) |
The recommendation, by where you sit
- Running emDash. Another low-risk, no-migration update. The revision-history rework alone justifies it for any site with more than one editor, and the AI-training switch warrants a brief, deliberate decision rather than a default.
- Evaluating emDash. Step back from the individual features. Three substantial releases in the seventeen days following 1.0, each crediting a substantial group of community contributors alongside the core team (21 on 1.2, 16 on 1.3), is the datum that should carry the most weight. It speaks to two things a buyer cannot easily assess from a feature list: sustained momentum, and a contributor base broad enough that the platform's health is not wholly dependent on a single vendor's continued attention. That distributed resilience is itself a risk reduction, and it is the lens we will keep applying as the releases continue.
