Migrating Blade docs into the database

Phase 3 #196 ships the docs:migrate-blade artisan command that bulk-imports every shipped Blade documentation partial into the doc_pages table created by the documentation editor. After running it, the DB row supersedes the shipped Blade copy on a per-slug basis — admin edits in the documentation editor then take effect without touching code.

Running the migration

# Dry run (recommended first pass) — prints what would be done.
php artisan docs:migrate-blade --dry-run

# Import everything as DRAFT (default).
php artisan docs:migrate-blade

# Import + publish in one go. Public renders the DB row immediately.
php artisan docs:migrate-blade --publish

# Overwrite already-imported rows (use after editing the original
# Blade partials and wanting to re-sync).
php artisan docs:migrate-blade --force --publish

What gets imported

For every slug registered in App\\Support\\DocumentationNav::flat():

• The Blade partial at resources/views/documentation/pages/{slug}.blade.php is rendered to HTML in isolation.
• The HTML is stored verbatim in doc_pages.body_html so the public page renders byte-identical to the shipped Blade copy.
• A placeholder Markdown stub is stored in doc_pages.body_markdown so editing the row in the admin overrides the legacy HTML — the renderer prefers body_html when both are present, but the admin edit experience operates on the markdown.
• The row carries source = blade_migration so the admin can tell at a glance which pages were imported vs. authored from scratch.
• Title + section come from the DocumentationNav::tree() entry.

Idempotency

Re-running docs:migrate-blade without --force SKIPS rows whose slug already exists. This matters because an operator may have customised a page after the initial migration — a naive re-run would clobber their edit. The table report at the end of every run reports how many rows were created, updated, or skipped.

Fresh installs

database/seeders/DocPageSeeder calls the command with --publish so a freshly-installed Pitchbar / Blengi has the full documentation site visible to visitors from the very first request. The seeder is wired into DatabaseSeeder after PlanAddonSeeder.

After migration

• The shipped Blade files in resources/views/documentation/pages/ are still loaded as a fallback for slugs that lack a published DocPage row. You can delete them in a separate commit once you trust the DB version.
• DocumentationNav.php still controls the sidebar tree ordering for legacy slugs. New DocPages added in the admin auto-merge into the public sidebar via the merged-tree logic in DocumentationController.

See also: Documentation editor (DB-backed) for the admin editor itself.