Getting Started

Install the package with Composer, publish its config and migrations, then run migrations. Seed at least one site and the CMS languages you intend to support before touching Dynamic Content.
Look first at the package config and the Dynamic Content admin screens. The new draft automatic detail page configuration lives there: source, existing design, base path, and visible block field mappings.
First use case: pick a source record, create a draft automatic detail page against an existing design, map only the blocks you want visible, then preview the selected record in each CMS language. Saving this draft must not change currently published pages or URLs.

Implementation Patterns

Treat automatic detail pages as draft-first configuration. Create a draft from Dynamic Content, attach it to an existing design, set the base path, and map visible block fields. Keep published page records untouched until you deliberately activate routing.
Use the optional provider publication contract 1.0 when exposing public identities. Implement paginated identity listings, return explicit availability outcomes, and validate that the actual record exists in every CMS language before advertising it.
Preview through the native multilingual design rather than generating temporary pages. Select a source record, render it through the existing design, and verify that source artwork, localized alt text, and record identity are preserved in canonical and language links.
Scope design references by site. When resolving designs in code, always include the site context so a design from one site cannot be attached to another.
Protect saves with stale-edit handling. Re-read the draft configuration before saving, compare the version or updated timestamp, and surface a conflict instead of overwriting another editor’s changes.
Keep the workflow explicit: configure draft detail page → save → preview in each language → validate provider availability if applicable → defer public routing activation until the package enables it.

This release is draft configuration only. Automatic public routing and page migration are not activated, so do not expect new public URLs or moved pages just because a draft detail page exists.
Saving and previewing are designed to preserve current published pages and URLs. If you see URL changes during preview, you are likely testing against published records instead of the draft configuration.
Preview does not copy pages or alter stored translations. It renders the selected source record through the multilingual design, so translation edits made during preview should not be expected to persist.
The provider publication contract is optional and versioned at 1.0. If you implement it, handle pagination and explicit availability outcomes; do not assume every identity is available in every language.
Record validation happens in every CMS language. A record that exists in one language but is missing in another should be treated as unavailable according to the contract’s outcome, not silently published.
Stale-edit protection is enforced, but you still need to handle the conflict in your UI. Re-fetch the draft before retrying a save.
Site-scoped design references are enforced. Cross-site design reuse will fail; duplicate or create a site-local design instead.
The contract is an extension point, not a requirement. Use it only when you need to expose public identities; otherwise keep the draft configuration path simple.