emDash 1.4: fewer lost edits, caches that follow the content, and an AI Search plugin

emDash 1.4 arrived on October 29, two weeks after 1.3, with 75 changes from 22 contributors. Most of it refines existing features rather than adding new ones. The common theme is trust in day-to-day operation. Two people saving the same entry no longer quietly overwrite each other. Cached pages now update when content is deleted or unpublished. Several Cloudflare costs shrink. There are no database migrations, which keeps the upgrade itself low-risk.

Fewer lost edits: an operational-risk fix

Lost work is the complaint that erodes an editorial team's confidence in a CMS fastest, and 1.4 closes three routes to it.

• Autosave before you leave the editor. Changes to an existing entry are now sent before you navigate away. If that fails, the next page says "Autosave failed". If a change can't be sent at all, for example after a conflict, the editor asks before letting you go. Switching to another entry and back no longer brings back an older copy that overwrites recent edits.
• Simultaneous saves are refused, not silently lost. Previously, if two saves based on the same version arrived together, both reported success and the first was overwritten. On Cloudflare D1, Durable Objects and PostgreSQL, the second save now gets a conflict error.
• Menus save completely or not at all. On D1, translating, deleting, reordering or replacing menu items either succeeds in full or leaves the menu as it was. That ends the half-saved menus a large translation could leave behind.

The second fix matters more than it first appears. The simultaneous writers it protects against are usually not two editors in the admin. They are scripts and AI agents working through emDash's MCP server, alongside a person in the editor. As more teams hand routine edits to agents, the CMS has to say "someone else changed this first" rather than pick a winner silently. 1.4 does. A script or agent that writes content should now expect that conflict error and handle it.

Caches that follow the content

On Cloudflare, emDash sites typically cache whole pages at the edge and clear them when content changes. We described the trade-offs in caching emDash on Cloudflare. 1.4 fixes a gap in that model. When content was deleted or unpublished, Cloudflare could keep serving the old page. emDash stamped each page with the modification time of the entry it showed. That time didn't cover related lists, settings or removals, so Cloudflare could confirm an outdated copy as current.

emDash no longer sends that timestamp, and pages now follow deletions and unpublishes. There is one side effect a developer should check. Pages that relied on the timestamp also lose the "check with the server before reusing this page" instruction that browsers received with it. On this site, every public page arrived with no browser caching instruction at all after the upgrade, until we added one back. It is a one-line change. The upgrade notes describe it, but it is easy to miss.

Two smaller caching changes complete the picture:

• Menus now leave out links to unpublished or trashed entries, and child items of an omitted entry go with it, so a menu no longer leads readers to a dead page.
• Category and tag definitions now refresh in the background every 30 seconds.

Lower Cloudflare costs

Several changes reduce work on Cloudflare, and some of them show up directly on a bill or a free-plan limit:

• Fewer database queries per page. Pages that show author bylines save between two and six queries, one after another, when they read a few entries.
• Widget areas are cached. With an object cache configured, sidebars and other widget areas no longer query the database on each page view.
• No more storage write per admin click behind Cloudflare Access. Sites signed in through Cloudflare Access previously wrote to Workers KV on every admin request. That could exhaust the Free plan's daily KV write allowance on a busy day. The session is now written only when the signed-in user changes.
• Less image storage traffic. The image endpoint no longer reads from R2 when it answers "not modified", answers a HEAD request, or fails to transform an image.

For a small site these are quiet savings. For an agency running dozens of sites on one account, they compound.

Admin changes

• Content list rows have one actions menu, with Edit, View published, Duplicate and Move to trash in it.
• Destructive actions ask first. Deleting a menu item or a widget now asks for confirmation.
• Unknown admin addresses show a proper "not found" page.

Hiding admin sections. A new setting, admin.hiddenNavItems, hides built-in areas a site doesn't use, such as comments, redirects or the import tool. This is a tidiness control, not an access control. Hidden pages and their API routes stay reachable to anyone whose role allows them. Treat it as decluttering, and keep restricting access through roles.

Translations. Simplified Chinese, Brazilian Portuguese and Turkish are now complete. Japanese coverage expanded substantially. In right-to-left languages, addresses and slugs now display the right way round.

Forms 0.2.12

The first-party forms plugin, which we reviewed at 0.2.10, gets changes that matter for small teams.

• Editors can see submissions. Editors can now view forms and their submissions. Changing forms, deleting, exporting and the webhook address remain admin-only.
• Submitter details are admin-only. Submitters' IP addresses, browsers and referring pages are returned to administrators only.
• Replying reaches the visitor. Notification emails now set Reply-To to the visitor's address. On this site, replying to a contact notification now reaches the person who wrote in, not our own inbox. We confirmed it on a live submission. The email plugin delivering your mail has to pass Reply-To through for this to work. Ours does.
• Required dropdowns start empty, so visitors make a real choice instead of submitting whatever came first.

A new AI Search plugin

@emdash-cms/plugin-ai-search, contributed by a community developer, indexes published content and author profiles into Cloudflare AI Search and keeps the index up to date. Setup happens in an admin wizard. It runs on Cloudflare or, through Cloudflare's API, on other hosts including Node.js. We haven't tested it yet. emDash's built-in search remains the default, and this site still uses it. For publishers whose readers ask questions rather than type keywords, it is worth a trial on a preview.

Upgrading: what we did on this site

We upgraded emdashnow.com the day after release, following the procedure in operating emDash safely. We recorded a recovery point even though the release notes promised no migrations. Our deployment confirmed that before the new code went live: nothing pending, nothing unexpected.

Two findings are worth passing on:

• The caching instruction. It is described above. We restored it before deploying, and our automated checks now fail if the main page types lose it again.
• Widget changes take a few seconds to appear everywhere. emDash now caches widget areas across Cloudflare's network, and a change reaches other locations shortly after the save, not instantly. On our preview environment, added, reordered and removed widgets appeared within two to three and a half seconds. We've reported the timing to the emDash project. On a site with page caching, an unlucky visit in that window can keep the old sidebar until the page cache next expires. That is up to five minutes here. If an edit doesn't show, republishing the page fixes it.

The release notes list three repairs some sites will need after upgrading:

• Check Settings → Media usage tracking.
• Re-tick Search on any collection that reports a no such column error.
• Redo any menu translation that failed earlier.

What to do now, and what 1.4 says about emDash

• Running emDash. Upgrade. It has no migrations, and the lost-edit fixes alone justify it for any site with more than one person, or one agent, editing. Before you deploy, ask your developer three questions:
  • Do our pages still send a browser caching instruction?
  • Do any of our scripts write content and need to handle the new conflict error?
  • Does Media usage tracking show Ready?
• Evaluating emDash. The gap between releases has widened from four days to fourteen, and that is a healthy sign. By the project's own account, 1.4 is mostly refinement: fixes to saving, caching and permissions that only surface once real teams run real sites. Five releases in 31 days, counting 1.0, the latest with 22 contributors, show a project now listening to production users more than adding features. That is what a buyer should want to see at this stage.