WordPress-style permalink structure tags for url_pattern ({year}/{month}/{day}/{slug})

[swissky]

Problem

Teams migrating from WordPress want to preserve their existing permalink structure so old URLs keep working and SEO/equity is retained. WordPress lets you compose permalinks from structure tags — e.g. /%year%/%monthnum%/%day%/%postname%/ or the classic /%year%/%monthnum%/%day%/%postname%.html.

EmDash collections already have a url_pattern, but it only supports {slug} (and {id} in menus). There is no way to express a date-based permalink, so WP migrants cannot reproduce /2018/05/28/my-post.

Proposal

Add date/id structure tags to url_pattern, resolved from the entry's published date (so permalinks stay stable across edits — updated_at would change the URL on every edit):

• {year} → 2018
• {month} → 05 (zero-padded)
• {day} → 28
• {hour} {minute} {second} → zero-padded
• plus the existing {slug} and {id}

Literal suffixes like .html already work (they are literal text in the pattern). Example pattern: /{year}/{month}/{day}/{slug}.html.

I propose keeping EmDash's {token} syntax (consistent with the existing {slug}/{id}) rather than WP's %token%.

Scope (forward / presentational)

url_pattern in EmDash is presentational — core does not serve content routes (no [...slug] route in packages/core); templates own routing. So this proposal covers the canonical-URL / forward side, which is exactly where it matters:

• Sitemap canonical <loc> + hreflang (interpolateUrlPattern)
• Admin “View published” link (contentUrl)
• The value the frontend/templates read to build links

Reverse-matching an incoming /2018/05/28/slug request back to an entry remains the template's job (a dated route), unchanged by this proposal.

Implementation sketch

1. Extend the single core resolver interpolateUrlPattern (packages/core/src/i18n/resolve.ts) to accept an optional published date and substitute the date tokens (global replace; tokens left untouched when no valid date).
2. Thread the published date into the sitemap data query (handleSitemapData selects published_at) and the admin contentUrl (the content item already carries its date).
3. Add help text under the URL-pattern field (ContentTypeEditor) listing the available tokens.
4. Unit tests for the date-token substitution; changeset (emdash + @emdash-cms/admin, minor). No messages.po (extracted on merge).

Open questions for maintainers

1. Token syntax: keep {year} (EmDash style) or also accept WP %year%?
2. Date source: published date (my preference, stable) vs created — and fallback when unpublished?
3. Should the duplicate menu resolver (packages/core/src/menus/index.ts) adopt the same tokens for consistency?
4. Worth shipping a small redirect helper/recipe for old WP URLs, or leave that to templates?

Happy to open the PR as sketched once a direction is agreed. I already shipped the smaller, self-contained admin feature directly (#1524); this one is core + has the design choices above, so raising it here first per the contribution policy.

[ascorbic]

How would this be used in a template?

[swissky]

Good question — and it points at a real gap.

Today EmDash templates own their routes and build links by hand (the blog template hardcodes /posts/${id}, /pages/${slug}); they don't read url_pattern at all. interpolateUrlPattern is internal (sitemap + core) and contentUrl lives in the admin. So with this PR alone, date tokens flow to the two places EmDash itself builds URLs:

1. Sitemap <loc> / hreflang — the SEO-critical part of a WP migration (Google sees /2018/05/28/post).
2. The admin “View published” link.

For a template to actually serve + link those URLs, two pieces are needed:

• Route — add e.g. src/pages/[year]/[month]/[day]/[...slug].astro (or a catch-all) that looks the entry up by slug and renders it. The date segments are just captured; the slug stays the key.
• Links — and this is the gap your question targets: there is no public helper for a template to turn an entry into its url_pattern URL, so it would duplicate the date logic.

I think the feature is only worth shipping if we close that second piece — i.e. export a small getEntryUrl(entry, { pattern }) (or expose interpolateUrlPattern) from emdash so a template does:

---
import { getEntryUrl } from "emdash";
const url = getEntryUrl(post); // "/2018/05/08/hello.html" — same resolver the sitemap uses
---
<a href={url}>{post.data.title}</a>

Then url_pattern becomes the single source of truth for sitemap, admin, and template links, and WP-style permalinks “just work” once the matching route exists.

Happy to add that exported helper + a short routing example (and update the starter templates to use it) to the PR if you’re on board with the direction. The open {token} vs %token% syntax question still stands too.

[ascorbic]

If I wanted to talk to Claude I'd've asked Claude! 😁