emDash 1.1 shipped on October 2, four days after 1.0. The headline additions — a publishing calendar, isolated custom-code blocks, Microsoft sign-in — matter, but the more informative signal for anyone evaluating the platform is the release itself. A substantial, editor-focused update four days into the production era tells you something no feature can: this is a maintained platform with momentum, which is precisely the attribute that is hardest to verify and most expensive to get wrong.
The publishing calendar: a throughput and coordination gain
The new publishing calendar consolidates published entries, scheduled entries, and scheduled updates into one view across every collection and locale, with month and agenda layouts, filtering by collection, locale and state, and shareable URLs that encode a particular view. From the calendar you can reschedule, unschedule, or immediately publish an overdue entry.
The feature is unremarkable to describe and consequential to operate. For any team publishing on a cadence, editorial coordination is a real cost — it is the status meetings, the spreadsheet that drifts out of date, the scheduled post nobody remembers approving. Bringing the full pipeline into one governed, shareable view reduces that coordination overhead and the errors it produces. For a solo operator it removes mental bookkeeping; for a team it removes a recurring source of miscommunication. Worth noting for anyone weighing the health of the project: this was contributed by a community member, not the core team.
Isolated custom-code blocks: extensibility without the exposure
1.1 lets editors add raw HTML, CSS and JavaScript in dedicated blocks. The design decision that matters is the default: new blocks render inside an isolated frame with an opaque origin, unable to read the site's cookies, storage or other pages, and sealed off from the site's own styles. An editor can opt a block back to inline rendering when sanitised HTML genuinely needs to be part of the page.
This is the plugin-isolation philosophy applied one level down, and the business logic is the same. It lets non-engineers extend a page — a signup form, a third-party widget — without handing them the ability to compromise the whole site, and without routing every small change through a developer. That is a reduction in both operational risk and dependency cost. One qualification for teams running a strict content-security policy: isolated and iframe blocks need deliberate configuration to coexist with it, which is a conversation to have with whoever owns your build before you enable both.
A companion iframe block (type /iframe, paste a URL or embed) renders third-party pages as responsive, lazy-loaded, sandboxed frames, with YouTube and Vimeo converted to players automatically.
Identity, agents, and the enterprise checklist
Two additions speak to larger buyers. Microsoft Entra ID sign-in lets teams authenticate with existing work accounts — a line item on most enterprise procurement checklists, and one fewer identity silo to govern. Separately, an experimental capability lets in-browser AI agents, in browsers that support WebMCP, search a site's published content through a read-only interface, an early, cautious step into the agent-facing surface area emDash has prioritised.
The part that does not demo: reliability at scale
The majority of 1.1 is reliability engineering, and it is the least glamorous and most decision-relevant work in the release. Among the fixes: lists sorted by a field that can be empty no longer skip entries between pages; redirect matching reads its rules in one query and checks a single small row for changes; image responses no longer wait on full runtime startup on cold instances; and returning visitors no longer receive a stale cached page in a specific edge case.
| Fix | What it prevents |
|---|---|
| Sorting by a field that can be empty | Entries silently skipped between pages of a list |
| Redirect rules read in one query | Extra database work on every request that checks redirects |
| Images served before full startup | Slow images on cold instances |
| Cached-page edge case closed | Returning visitors receiving a stale page |
None of this is marketable. All of it is the distance between "works on my blog" and "works under production load." For a buyer, a release weighted toward this kind of work so soon after launch is a credibility signal — it indicates the team is prioritising the unglamorous correctness that production sites depend on over feature theatre.
The recommendation, by where you sit
- Running emDash. Upgrade on your normal change-management cadence, with a backup first. The calendar is an immediate operational gain for any scheduled publishing, and the reliability fixes carry no behaviour change to manage. Note the Turnstile secret-handling change in the upgrade notes if you run on Node.js.
- Evaluating emDash. Treat the cadence as data. The feature set is secondary to what the release velocity tells you about whether this platform will still be actively maintained in three years — the risk that sinks most platform bets. One data point is not a trend, so hold the question open; we are tracking it release over release, and the running view is in our standing production-readiness verdict.
