---
title: "Four limits in this blog’s EmDash publishing path"
description: "A writing agent can revise this blog, but only an independent publisher can promote its work. Four boundaries keep permissions, metadata, revisions and plugin isolation separate."
canonical: https://arnekellmann.de/blog/four-limits-a-live-emdash-deployment-hit
published: 2026-09-28
modified: 2026-10-13
lang: en
---

# Four limits in this blog’s EmDash publishing path

This blog uses EmDash for content and a separate website build for the pages readers see. A writer can prepare an English/German pair and revise an existing post. The important boundary is who can turn that revision into a public page. For a team deciding whether to automate publication, a CMS approval is only one checkpoint: the accepted revision must also reach the website and match what a reader receives.

The native records store 28 September 2026 as the first-publication date. Separately, the archived owner text described human publication. These records do not reconstruct when a visitor first received that page. On 11 October, this deployment configured an independent automatic reviewer and a separate publisher identity. The public URLs and the native Markdown content stayed in place. The deployment checks below are dated owner-reported observations, not a certification of other EmDash installations.

That change required more than a recurring writing task. Four limits decide whether automatic publication is a controlled process or just another way to write into production.

## 1. A writing role does not define the product boundary

EmDash's [content lifecycle](https://docs.emdashcms.com/reference/content-lifecycle/) gives Authors permissions over their own entries and Editors permissions over other entries. Editing and publishing are separate operations, but the standard Author role can do both on its own content. Calling an API token a “writer” does not remove the publishing permission its account holds.

Owner-reported source inspection on 11 October found a boundary that checks the credential and requested operation before the native CMS write. It maps this writer to staged posts in the `posts` collection. Registration readback also confirmed a separate publisher allowlist in the native publication plugin. The live probes below tested specific refusals; they are not an exhaustive permission theorem.

Consider a correction to a source link. The writer needs permission to save that correction. It does not need permission to make the correction public. Keeping those actions separate means a mistaken link can remain a draft until review resolves it.

The live check on 11 October 2026 returned HTTP 200 for an authenticated own-post read. Publish, schedule and unpublish requests returned 403. Separate rejected requests attempted approval, publication-date and SEO-overlay changes. Readback showed that these probes changed no content.

The boundary also covers the permitted MCP tools. A `content_list` request for `posts` succeeded. A `content_publish` call and a cross-collection list request returned 403. These checks concern this deployment's credential boundary. They do not claim that every EmDash installation blocks those tools.

## 2. Metadata must travel with the reviewed text

Inspection of the installed EmDash 1.0.1 handlers found a separate entry-level SEO store and update path. That is a version-specific source observation. A live SEO-overlay edit remains untested. The live permission probe established the narrower fact: this writer rejects an overlay-shaped request with HTTP 403.

The writer stages title and excerpt in the content fields. Owner-reported source inspection on 11 October traced those fields through the synchronizer into the website's title, description and BlogPosting metadata. This inspection concerns the installed publication path; it does not demonstrate the effect of a native overlay edit.

Dates need the same care. The current [lifecycle documentation](https://docs.emdashcms.com/reference/content-lifecycle/), in its Publish row, preserves the first timestamp on later publications unless an authorized caller overrides it. Owner-reported inspection on 11 October found that this reader validates the live revision's entry, collection and creation time. It derives the exposed modification time from that accepted revision and the native first-publication time. A pending correction must not make an unchanged public page look newly reviewed.

Owner-reported source inspection on 11 October found that the native checklist and website synchronizer both select `data.markdown`. The synchronizer writes that string into generated Markdown files, which Astro builds. It has no Portable Text fallback. The older `content` field retains the September copy but is not an input to this path.

An authenticated reader check during the pending revision still returned the previous Markdown and the 28 September publication and accepted-revision dates. It exposed no staged revision pointer. This is an observed pending-edit result, not proof of a later promotion. A writer-supplied date would not establish that a review or release happened.

## 3. Approval belongs to one revision

A review result can become stale between “approved” and “publish.” Suppose a reviewer accepts a draft, then an editor changes its source link. Publishing whichever text happens to be current would apply the old approval to new content.

The current [REST documentation](https://docs.emdashcms.com/reference/rest-api/) describes an opaque `_rev` token. An authenticated read from this installed 1.0.1 deployment returned it during the owner-reported 11 October check. Sending the current token protects against overwriting a concurrent change. On 11 October, this site's REST update and MCP `content_update` probes without `_rev` both returned 403. The entry's revision remained unchanged.

Owner-reported source inspection on 11 October found two separate checks in the deployed publisher. It compares the payload, slug and stored references with its captured review input. It also sends the current `_rev` with the promotion request to fence a concurrent edit. During the permission tests, its first automatic promotion of this article was still pending. Later on 11 October, the native publisher accepted the English and German revisions. A fresh read on 13 October confirmed both live revision identities and the matching public Markdown; the acceptance checks below explain what that establishes. A later edit requires another review. The word `approved` in a content field is insufficient if the body, slug or references have changed underneath it.

This also changes how a failed request is handled. If a connection ends before a save response arrives, the writer reads the existing entry before retrying. Otherwise a successful but unseen create could become two posts. The current lifecycle documentation gives this read-before-retry instruction under Conflicts and retries.

## 4. Editorial review does not isolate plugin code

Owner-reported inspection on 11 October found directly registered custom plugin functions in this CMS build and a compiled sandbox configuration set to false. This is a source-and-build observation, not a runtime isolation test. Publication checks and plugin isolation remain separate decisions.

The archived September text said: “That product is still in closed beta, and this account is not enrolled.” That status claim was not supported. Cloudflare's [24 March 2026 announcement](https://developers.cloudflare.com/changelog/post/2026-03-24-dynamic-workers-open-beta/) describes Dynamic Workers as an open beta for paid Workers users. The older Worker Loader documentation URL now leads to the official [Dynamic Workers documentation](https://developers.cloudflare.com/dynamic-workers/). That documentation describes binding and network controls. It does not establish this account's configuration. The inspected publication change retained that sandbox configuration.

A sandbox transition would therefore need its own implementation and verification. It is not a reason to treat an in-process plugin as isolated, or to confuse a content review with a code security review.

## From a reviewed revision to a reader

A CMS can publish successfully while a separate website continues to serve an older build. In this architecture, inspect each boundary before calling a correction live:

| Checkpoint | Evidence | Still to verify |
| --- | --- | --- |
| Accepted in the CMS | Live revision and reviewed body match. | Website delivery. |
| Synchronized and released | Generated body matches; normal release succeeds. | Reader response. |
| Read on the public site | Page, Markdown and metadata match. | Indexing, citations and useful traffic. |

Before this update, the 13 October check found the English accepted revision dated 11 October at 20:33:56 UTC and the German revision at 20:32:47 UTC. The public Markdown matched both bodies. Each page's BlogPosting metadata retained 28 September as its publication day and used 11 October as its modification day. These are observed stored and delivered fields; they do not reconstruct the first historical visit. The earlier Content Sync and Worker Release also had a successful completion record.

Those comparisons localize a failed handoff. If the CMS reader still returns the old body, inspect review and promotion. If the CMS returns the correction but the website does not, inspect sync, release and the delivered version before submitting again. A second draft cannot repair a missed website release.

The next check is discovery: follow the visible Blog menu to the index and article, verify the published language link, and find one canonical entry in the advertised sitemap. This tests a reader path and retrieval surfaces. It does not establish that a search engine indexed the correction. The publishing decision ends with the reviewed revision on the actual page, with discovery and growth recorded separately.