feat(docs): guided start pages and landing UX for Drupal workspaces

[jameswilson]

Fixes #156

Summary

Users landing on start.coder.ddev.com were often sent straight to the raw drupal-core Coder template in manual mode, where version/branch mismatches and opaque parameter choices caused confusion. This PR steers people through guided entry points on the start site, consolidates shared styling, and prefills workspace creation via mode=auto so the right template parameters are locked in before Coder opens.

Landing page (docs/index.html)

• Replaces the old single-call-to-action layout with a three-column tile grid: Drupal Issue (recommended), Drupal Core, and DDEV Freeform
• Adds footnote-linked callouts for stability expectations and GitHub OAuth access requirements
• Moves sign-in guidance below the primary tiles in a muted callout with GitHub icon
• Links “How it works” and resources to the new guided pages instead of raw template URLs
• Fixes the Drupal Core tile to point at /drupal-core (not /drupal-issue)
• Fixes malformed footnote markup (stray closing </a>)

New guided start pages

/drupal-core (docs/drupal-core.html)

• New page for vanilla Drupal core workspaces (no issue fork)
• Pick-card radios for Drupal version (10/11/12), install profile (Demo Umami / Minimal / Standard), and site visibility
• Editable workspace name with live URL slug preview
• Launches coder/drupal-core with mode=auto and disable_params so version, profile, and visibility are prefilled and not accidentally changed in Coder

/drupal-issue (docs/drupal-issue.html)

• Major refactor aligned with the drupal-core page layout and copy
• Accepts issue number, drupal.org issue/project URL, or contrib machine name
• Issue flow: fetches issue metadata from drupal.org, loads branches from git.drupalcode.org, auto-selects the most recently committed branch, and chooses drupal-core vs drupal-contrib template automatically
• Plain contrib flow: verify project on git.drupalcode.org, then launch HEAD development without an issue fork
• Manual fallback form when APIs fail (fork name, branch, version, profile, visibility)
• Pick-card fields replace <select> dropdowns for version, profile, and site visibility (matches drupal-core)
• Launches with mode=auto + disable_params on all three forms (result, plain, manual)
• Theme support: resolves param.project_type (module vs theme) from the Drupal.org project node API (project_theme / project_module) so contrib themes symlink into web/themes correctly
• Template badge shows project type for contrib issues

Shared infrastructure

docs/coder-ddev-start.css

• New shared design system for the start site (~1500 lines): dark hero, tile grid, pick-cards, callouts, form fields, status messages, footnotes, accessibility helpers
• Component classnames are prefixed with .cds- namespace.
• Replaces large inline <style> blocks previously duplicated across pages

docs/coder-workspace-name.js

• Shared workspace name sanitization and suggestion helpers
• 32-character Coder workspace name limit with inline field validation before launch
• Branch-based names fall back to issue NID when {version}-{profile}-{branch} would exceed the limit

docs/components.html

• Internal component gallery documenting pick-cards, tiles, callouts, and form patterns used on the start site

Layout consolidation

• docs/_layouts/default.html, docs/access-denied.html — drop inline CSS in favor of shared stylesheet
• New logo assets: docs/logo-coder-on-dark.svg, docs/logo-ddev-on-dark.svg

Documentation updates

docs/user/quickstart.md

• Replaces raw “Open in Coder” button with guided tile links to /drupal-issue and /drupal-core
• Adds guidance about confirming workspace creation in Coder vs editing locked parameters
• Links code layout sections to ddev-drupal-dev and ddev-drupal-contrib add-on documentation via announce callouts

README.md

• Replaces single manual template badge with recommended paths (issue picker, freeform, guided core, template browser) and an advanced manual link

Template tweak (requires separate template push)

drupal-core/template.tf

• Human-readable install profile option labels (Demo Umami, Minimal, Standard)
• Clearer install profile description explaining Demo Umami snapshot behavior on Drupal 12 vs full installs on other profiles/versions

Note: The template.tf label/description changes only take effect after the template is pushed to Coder; the start-site UX changes deploy with GitHub Pages.

Test plan

• Load start.coder.ddev.com/ — three tiles render; Core tile goes to /drupal-core; footnotes link and scroll correctly
• /drupal-core — pick version/profile/visibility, launch URL contains mode=auto and expected param.* values
• /drupal-issue — core issue (e.g. drupal.org core issue NID): loads branches, launches drupal-core template
• /drupal-issue — contrib module issue: launches drupal-contrib with param.project_type=module
• /drupal-issue — contrib theme (e.g. olivero or theme issue): launches with param.project_type=theme
• /drupal-issue — plain contrib machine name: plain-dev form, correct project type in URL
• Workspace name > 32 chars blocked with inline error; branch-based fallback uses NID
• Jekyll quickstart page renders tile HTML and announce callouts
• terraform fmt / validate on drupal-core if template push is included in this release

[jameswilson]

Screenshots:

Homepage

URL: /

Drupal Issue (empty)

URL: /drupal-issue

Drupal Issue (fork)

Drupal Issue (project)

Drupal Core

URL: /drupal-core

Quick start

URL: /user/quickstart

[rfay]

This is great. Would you mind just dropping the middle one for simplicity, assuming people don't actually need a drupal HEAD build?

[jameswilson]

@rfay thanks for the review. Do you mean removing only the homepage card that links to /drupal-core, or removing the /drupal-core endpoint entirely?

[jameswilson]

assuming people don't actually need a Drupal HEAD build

I can see a few valid cases where they might:

• Core contributors may not want a new workspace for every issue fork they start.
• Core reviewers may not want a new workspace for every issue they review.
• Core subsystem maintainers may not want a new workspace for every issue they merge.
• Sales/dev/support may just need a quick vanilla Drupal demo environment.

That last case is where /drupal-core is currently more useful than /drupal-issue, though it still is not quite right. Ideally, we would have a page that lets users select a stable Drupal release tag instead of defaulting to HEAD. The current workaround is /drupal-core → 11.x minimal → terminal → checkout the latest stable tag if HEAD is broken.

After spending several hours on this yesterday, I think the better long-term answer is a single consolidated /drupal start page that covers the full range of Drupal workflows. That pattern could also apply to similar start pages for other project types and scenarios (typo3, wordpress, private "project" github repo).

Slightly related: /drupal-issue currently treats drupal or https://www.drupal.org/project/drupal in the “load” field as a contrib project, which drops users into the contrib template workflow instead of core.

[rfay]

In all of those cases (I think) every single workspace can be used any way the owner wants to use it. It's just like your own computer. You git fetch drupal and/or add another remote, etc. If I were a core contributor, I wouldn't be spinning up a new workspace for every usage.

But you're closer to this than I am...

[rfay]

Also note that we're not taking anything away here. You can still just go to coder.ddev.com and create a new workspace, don't fill in the issue fork, and go on your way.

[rfay]

Tests aren't set up to be used on forks :(