emdash-cms/emdash emdash@0.16.0

on GitHub

Minor Changes

• #1195 47a8350 Thanks @ascorbic! - The per-collection sitemap (/sitemap-{collection}.xml) is now i18n-aware. When Astro i18n is enabled, each translation row is emitted as its own <url> with the correct locale prefix (resolved via Astro's own getRelativeLocaleUrl, so prefixDefaultLocale and custom path mappings are honoured). Every entry also lists its sibling translations as <xhtml:link rel="alternate" hreflang="..."> (plus x-default for the default-locale variant), grouped by translation_group. Sites with a single locale or no i18n configured are unaffected -- their sitemap XML is unchanged.

• #1238 60c0b2e Thanks @ascorbic! - Registry plugins can now declare environment requirements. A plugin's manifest may set a release-level requires block (e.g. { "env:emdash": ">=1.0.0", "env:astro": ">=4.16" }), which is published into the release record. When browsing a registry plugin, the admin compares those constraints against the running EmDash and Astro versions: if the host doesn't satisfy them, it shows a compatibility warning and disables the Install button. The server enforces the same check on install and update, refusing an incompatible release with ENV_INCOMPATIBLE so the gate can't be bypassed.

• #1239 1a4918f Thanks @ascorbic! - Plugins published to the experimental registry can now ship icon, screenshot, and banner images. Declare them in emdash-plugin.jsonc under release.artifacts as file refs; emdash-plugin publish --artifact-base-url <url> measures each image's dimensions, uploads it, and records it in the release. The admin plugin detail page renders the icon, banner, and a screenshot gallery, fetched through a server-side image proxy. The proxy resolves each artifact's URL server-side from the validated release record (the client sends only the artifact's coordinates, never a URL), then applies SSRF defences and an image content-type allowlist before serving the bytes. Supported image types are PNG, JPEG, WebP, GIF, and AVIF; SVG is rejected at both publish and proxy because it is active content.

• #1064 33f76b8 Thanks @Glacier-Luo! - Adds field-level and range filtering to getEmDashCollection's where option. Previously, only taxonomy-based keys were processed via JOIN; non-taxonomy field names were silently discarded. Now the where clause supports exact match (string), multi-value match (string[]), and range comparisons ({ gt?, gte?, lt?, lte? }) on any content table column, all executed at the SQL layer with parameterized queries.

Patch Changes

• #1159 e312528 Thanks @jp-knj! - Fix scheduled posts missing from snapshot export on SQLite/D1 until UTC midnight.

• #1166 668c5e1 Thanks @OrangeManLi! - Fixes portableTextToProsemirror flattening nested lists whose subtree mixes listItem types. The outer run-grouping broke on the first nested type switch (e.g. an orderedList child under a bulletList parent), so an input like [bullet L1, number L2, bullet L1] was emitted as three separate top-level lists instead of one bullet list with a numbered sub-list under the first item. Internal convertList/convertListItem recursion was already correct — only the outer grouping needed to be widened to include level > 1 blocks regardless of listItem type.

• #1160 f62c004 Thanks @CacheMeOwside! - Fixes Postgres server bundles importing better-sqlite3, which crashed production starts (pnpm preview, pnpm start) with ERR_MODULE_NOT_FOUND because the SQLite driver is not installed in Postgres-only deployments. Moved EmDashDatabaseError into a new SQLite driver-free database/errors.ts and re-exported it from there, so the better-sqlite3 import doesn't leak into the Postgres build.

• #985 5456514 Thanks @ppppangu! - Fixes public form embeds during SSR by allowing frontend plugin components to call public plugin routes without self-fetching.

• #1157 7554bd3 Thanks @jp-knj! - Fix scheduled posts not appearing on SQLite/D1 until UTC midnight.

• #1196 e9877e1 Thanks @Rimander! - Fix WordPress import leaving featured_image (and other image/file fields) pointing at the original WordPress URL after media download. The rewrite step passed the whole stored MediaValue JSON to the URL matcher instead of its inner src, so the field was never rewritten to the local R2 URL even though the file existed in the media table. Inline content images were unaffected.

• Updated dependencies [62619c2, 3d540da, b89e988, 4612749, 60c0b2e, 1a4918f, d2f2679]:

  • @emdash-cms/admin@0.16.0
  • @emdash-cms/registry-client@0.3.0
  • @emdash-cms/auth@0.16.0
  • @emdash-cms/gutenberg-to-portable-text@0.16.0