Docs CMS Plan — Repurposing the old site for Documentation (Dec 19, 2025)

Goal

Repurpose the legacy site components into a lightweight CMS for documentation that complements the MkDocs site. Provide an editing workflow, cross-links, and migrate high-value docs into MkDocs where appropriate.

Proposed Options

  1. Lightweight admin + MkDocs publishing (recommended)
  2. Use the legacy site as a WYSIWYG editor and content staging area.
  3. Add an admin-only editor that saves markdown to a documented folder (docs/), followed by an automated mkdocs build and site preview.

  4. Benefits: keeps MkDocs as the canonical site, but gives non-technical editors an easy editing surface.

  5. Full CMS (Wagtail/Django/Wagtail admin)

  6. Install Wagtail or similar on the legacy site and migrate key pages into its CMS.

  7. Integrate search and versioning. Use a scheduled job to export markdown to docs/ for MkDocs consistency.

  8. Headless Git-based CMS (Netlify CMS / Forem)

  9. Add NetlifyCMS to the legacy site to commit markdown updates directly to the repo (PR-based workflow).
  10. Benefit: lower infrastructure and integrates with GitHub workflows for review and CI.

Minimum Viable Steps (MVP)

  • Add one admin page to the legacy site with Markdown editor and preview.
  • Save edits as files to a docs/dam_pro/edited/ folder (commit as draft branch) and notify reviewers.
  • Add a simple endpoint to build MkDocs and publish to the /site folder for preview.
  • Add a cross-link from the app header to the legacy CMS admin page and to the MkDocs site.

Migration Plan

  1. Inventory existing docs on legacy site and in docs/ (we already have a large set of md files).
  2. Prioritize pages to migrate (start with Quick Start, Production, and Recent Work pages).
  3. Use the CMS admin to migrate content, review, and merge into main with tags like docs/migrated.
  4. Continuously build MkDocs and run basic smoke tests.

Security & Permissions

  • Limit CMS editor to authenticated admin users.
  • Use branch/PR workflow for reviews and audit trails.
  • Keep the canonical docs in docs/ so MkDocs builds deterministically.

Next Actions (if you give the green light)

  1. Build a simple Markdown editor page in the legacy site (quick prototype).
  2. Add an admin-only route and UI; test saving to docs/dam_pro/edited/.
  3. Add Git commit automation (or manual PR generation) for published content.
  4. Expand to include image/file uploads (thumbnails, attachments) and search indexing.

If you'd like, I can prototype the MVP editor page as a first step and link it into the new app's header. Which option do you prefer?