# EmDash CMS evaluation

An editable acceptance sheet from WAYF. This is a test template, not evidence that EmDash or any other product has passed.

Project:
Evaluation date:
emdash package version:
Templates repository commit (if scaffolded):
Astro version and adapter:
Deployment mode (Node or Cloudflare), database and media storage:
Plugin mode (sandboxed, native or in-process):
Evaluator and editorial role:

## Use your own content

Pick one content type your editors publish every week, one page with an image and a shared element, and a second locale if you publish in more than one language. Agree who should be able to edit, approve and publish before testing. Keep credentials and private client material out of the evidence.

| Check | Expected result | Observed result / evidence | Pass / partial / not demonstrated | Configuration/custom work and owner |
| --- | --- | --- | --- | --- |
| Install and pin | Scaffold reproducible from a recorded package version and template commit | | | |
| Edit | An editor changes the page; the published version stays live until publication | | | |
| Preview | Draft visible through the preview link; signed-out access after expiry shows the published page | | | |
| SEO changes | An edited SEO field on a published page reaches visitors when the team expects: on save or on publication | | | |
| Review and approval | A role that should not publish cannot; the mechanism is named (built-in, plugin, manual) | | | |
| Permissions | Every editor maps to one of the five roles; rules the roles cannot express are listed | | | |
| Translation | One locale publishes while another stays in draft; fallback on the public route is acceptable | | | |
| Schema change | A field added on staging reaches production through a committed script or seed export | | | |
| Recovery | A revision restore, then a database and media restore into a fresh environment, both verified on the public route | | | |
| Plugins | Each required plugin installs in the target mode; requested capabilities are recorded and approved | | | |
| Sign-in and account recovery | The production sign-in method works; a lost passkey can be recovered | | | |
| WordPress import | Counts by type and status, media, image URLs, internal links, authors and terms match the source export, or each difference is listed | | | |
| Old URLs | Every old public URL reaches its content on the new site, directly or through a permanent redirect | | | |
| Exit | A site package exports and imports into an empty site; missing items are listed | | | |

## Record the implementation boundaries

- Preview link lifetime, who can open it, and indexing directives on preview responses:
- Where the content model lives, and how a change is reviewed before it reaches production:
- Built-in, configured, plugin and custom steps in the approval flow:
- Email provider for invitations, magic links and account recovery:
- Database backup, media backup and encryption-key storage, with the last restore drill date:
- Plugin capabilities approved, and the deployment mode that enforces them:
- Upgrade process: release notes read, breaking changes, forward-only migrations:
- `.gitignore` covers the database file and its `-wal` and `-shm` companions:
- WordPress media origin reachable from the EmDash server during the import (EmDash refuses `localhost` and private addresses):
- Redirect rules for old URLs, including both trailing-slash forms of any pattern rule:
- Hosting, email, support and implementation costs, with their sources:
- Open questions, owner and decision:

Never mark an untested feature as absent. Repeat the same exercise with each finalist using comparable roles, content and hosting assumptions.